Leo vs Tropy: Which Tool Fits Where in a Manuscript Research Workflow

This is a practical comparison of Tropy and Leo for anyone building a manuscript research workflow. Tropy organizes and describes photographs of primary sources; Leo reads the text inside them. Understanding where one ends and the other begins is the difference between a workflow that moves and one that stalls at the point where the reading has to happen.

Tropy and Leo solve different problems, and the honest answer to "which should I use" is often "both, at different stages." Tropy is a free, open-source desktop application for organizing and describing photographs of primary sources — it structures your archive photos and stores metadata, but it does not read the text inside them. Leo is a transcription platform: it turns images of manuscript and printed pages into searchable text, and wraps that in a workspace for organizing, searching, and exporting. If your bottleneck is ordering thousands of archive photos, Tropy is purpose-built for it. If your bottleneck is reading them, Tropy has no engine for that, and Leo does.

That distinction is the whole comparison. It is worth working through carefully, because the two tools are easy to conflate. Tropy has a pane historically labelled "Transcription," which leads people to assume it transcribes. It does not. Knowing exactly where the seam falls between the two tools is the difference between a workflow that flows and one that stalls at the point where the reading has to happen.

What Tropy actually does

Tropy is built and maintained by the Roy Rosenzweig Center for History and New Media at George Mason University, jointly with the Luxembourg Centre for Contemporary and Digital History since its 1.13 release in April 2023. It is free, open-source under AGPL-3.0, and runs on Windows, macOS, and Linux. Its purpose is narrow and well-executed: bring order to large volumes of research photographs.

The data model is worth knowing, because it is what you are actually buying into. A Tropy project holds items — a single archival document, say, a will or a bundle of letters. Each item contains photos, one per image file. Each photo can hold selections: rectangular regions you draw on the image to isolate a paragraph, a seal, or a marginal note. Metadata templates, built on Dublin Core and extensible with any RDF property, can be applied at any level. A legal historian working notarial records might add fields like "Hearing date" or "Judge" to a template and describe hundreds of documents consistently.

Tropy links to your photos where they live on disk; it does not absorb them into a database. The project file holds metadata and notes, the image bytes stay in the filesystem, and backing up means backing up both. It can pull images from IIIF manifests, so you can draw directly from digital libraries that expose IIIF endpoints. It exports metadata and notes to JSON-LD, to Omeka S, and to CSV. This is a mature, actively maintained tool that does one job well.

The seam: Tropy does not read your documents

Here is the point that trips up most people evaluating Tropy for a transcription-heavy project. The Notes pane — the field formerly labelled "Transcription" — is a free-text box. Whatever you type or paste is stored and made searchable. Tropy does not generate that text from the image. The pixels remain inert until someone, or some other tool, produces text to fill the field.

This has a direct consequence for searchability. Organizing your photos in Tropy makes your metadata and your notes searchable — nothing more. The words written on the page stay unsearchable until they exist as text in a field. For a historian with thousands of images, that is the entire problem in miniature: Tropy tells you which box holds the 1623 inventory, but it cannot tell you which of your documents mentions a particular name, sum, or place, because it has never read a word of them.

Tropy's developers are candid about this. Text recognition has been described in the OCR forum thread as a long-term goal, to be delivered through a plugin hooked into an external OCR service rather than a built-in engine. A handwriting-OCR plugin hook that would accept ALTO XML from a third-party engine was confirmed as in progress in January 2025. As of mid-2025, no first-party or widely adopted third-party plugin ships that integration out of the box. In practice, researchers who want recognized text inside Tropy run a separate engine — Transkribus, Google Cloud Vision, an ABBYY command-line job — and paste the result into the Notes pane by hand.

That copy-paste step is the seam. It is where a Tropy-only workflow becomes a Tropy-plus-something workflow, and it is where most of the actual labor of a manuscript project lives.

Why the recognition step is the hard part

If pasting text into Tropy were trivial, the seam would not matter. But producing accurate text from historical documents is precisely the difficult, time-consuming work — the bottleneck before analysis can begin. It is worth being clear about why the obvious free options fail here, because that failure is what defines the gap Tropy leaves open.

General-purpose OCR is built for clean, modern, high-contrast type. Tesseract reads over 100 languages of printed text well and does not transcribe handwriting at all. DEVONthink's built-in OCR, derived from ABBYY, operates on printed text only; handwriting is explicitly unsupported. Feeding a photographed will or parish register to a generic OCR engine returns unusable output, because the tool was never engineered for manuscript hands — the whole reason OCR and HTR are distinct problems.

Handwriting needs specialist handwritten text recognition. But even here the numbers are sobering. According to Transkribus's own CER explainer, well-trained models on legible scripts can reach below 2% character error rate — "publication-ready" — while challenging historical documents run around 5%, and out-of-the-box engines on unconstrained handwriting routinely exceed 20%. A peer-reviewed 2025 assessment of advanced HTR engines puts realistic performance on pre-modern vernacular hands in the 5–15% band, and getting to the low end typically demands per-corpus or per-hand model training with substantial ground-truthed data. In other words: the specialist tools work, but many of them ask you to become, in effect, a model trainer before you can read your own documents.

There is also a subtler danger, one that matters most for anyone tempted to paste output from a general chatbot into their Notes pane. General LLMs downsample the high-resolution images that manuscript reading depends on, and they fail on historical handwriting in a particular way: they produce fluent, plausible readings that are wrong. A specialist engine that stumbles tends to err on individual characters or words — visible, recoverable errors you can catch against the image. A fluent fabrication is far harder to catch precisely because it reads well. For work whose defensibility depends on the text being faithful to the page, that is the error you least want.

Where Leo fits — and how it relates to Tropy

Leo occupies the stage Tropy deliberately leaves to other tools: it reads the page. Its core engine, ATR-1, is a specialist transcription model that reads Latin-script material — handwritten and printed — across the languages that alphabet records: English, French, German, Dutch, Spanish, Italian, Latin, and the rest. It is zero-shot: there is no per-corpus model to train before you start, which removes the training burden that specialist HTR tools typically impose. It reads secretary hand, cursive, and court hands, and it reads historical print — early-modern founts, blackletter and Fraktur, the long s, ligatures, typographic abbreviation — as well as clean modern type.

The design principle that matters most for the paste-into-Tropy problem is source integrity. ATR-1 transcribes what is on the page rather than smoothing it into modern, plausible prose: strikethroughs, marginal additions, expansions, archaic orthography, and abbreviation marks are preserved rather than silently normalized. That is the opposite of the fluent-fabrication failure mode, and it is the property you want when the transcription has to stand up in published work.

On accuracy, the one cleared measurement is worth stating precisely. On a randomized 97-image sample of early-modern English manuscripts from the Folger Shakespeare Library, at ATR-1's release, Leo scored roughly 5% character error rate — 61% fewer errors than the next-best model tested (Transkribus/Text Titan I at about 13%, Claude Opus about 23.3%, Gemini 2.5 Pro about 24.8%, GPT-4.1 about 56.7%), as recorded in the benchmark study. That is a single corpus of English secretary-hand material, not a universal claim; your own results will vary with hand, language, and image quality, and any transcription still needs verification against the image. But it sizes the gap between specialist and general tools on exactly the kind of material a Tropy user is likely to be photographing.

Where Leo differs from a paste-into-Tropy arrangement is that transcription does not sit outside the workspace. Leo pairs the reading with the surrounding workflow — upload (including straight from a phone camera in the reading room), the original image shown beside its transcription, custom nested folders, a structured metadata field set (Title, Creator, Date, Archive, Collection, Box, Folder, Identifier, Rights), global fuzzy search across every transcription, and export to Word, PDF, HTML, or TEI XML. There is also a separate AI layer that can run a finished transcription through a model to translate, summarize, classify, or extract named entities — each written to a new tab so the base transcription is never overwritten. The organizing capabilities overlap with what Tropy does; the reading and the analysis are what Tropy does not attempt.

Choosing between them — or using both

For a decision, the questions are concrete.

If your problem is organization alone

You have thousands of photos, you transcribe selectively or by hand, and you want a free, open, locally-controlled tool to structure and describe them. Tropy is an excellent fit, and its IIIF import and Dublin Core templates are genuine strengths. It is free and open-source, which for some projects and institutions is decisive.

If your problem is reading at scale

The transcription itself is the bottleneck, and hand-keying every will, register, or notarial act is what stands between you and analysis. Tropy leaves you at the seam, staring at a copy-paste job whose hard part it does not solve. That is the stage Leo is built for, without a model-training detour and without sending your images through a tool that will produce fluent guesses.

If you already live in Tropy

If you don't want to leave, the two are not mutually exclusive: Leo reads pages and exports clean text you can bring across, and Tropy continues to do the descriptive organizing it does well. The tools are complementary as much as competitive, and there is no contradiction in running an image-organizing tool alongside a reading tool. This is the same layered thinking behind any well-planned digitization workflow, where capture, description, recognition, and publication are distinct stages that constrain one another.

The wider set of HTR tools and their alternatives is worth surveying before committing, because the right answer genuinely depends on your material and your constraints. Note one boundary that cuts across both tools: neither is a scanner. Tropy and Leo both begin at the point where you already have images, so capture — the archive visit, the copy stand, the phone camera — remains your responsibility.

What does not change, whichever tools you choose, is the standard the text has to meet. A transcription is only useful if it is faithful to the page — if the strikethrough is still a strikethrough, the abbreviation is still marked, and the reading you cite is the reading that is actually there. Organizing your photos well does nothing for that; neither does a fluent transcription that quietly invents. The craft is in getting the words right, in a form you can search, defend, and return to. Choose the tools that let you keep faith with the source, and put the saved hours back into the reading.

Frequently Asked Questions

Does Tropy transcribe handwriting?

No. Tropy organizes and describes photographs of primary sources but does not read the text inside them. Its Notes pane — the field once labelled "Transcription" — is a free-text box: whatever you type or paste is stored and made searchable, but Tropy never generates that text from the image. The pixels stay inert until you or another tool produce the words. Text recognition has been described by its developers as a long-term goal, delivered eventually through a plugin hooked to an external OCR service. As of mid-2025, no such integration ships out of the box, so researchers who want recognized text run a separate engine and paste the result in by hand.

Can I use Tropy and Leo together in a manuscript research workflow?

Yes. The two tools solve different problems and are complementary rather than mutually exclusive. Tropy organizes and describes your archive photographs — structuring items, photos, selections, and Dublin Core metadata — while Leo reads the page, turning images of manuscript and printed material into searchable text. Leo exports clean text to Word, PDF, HTML, or TEI XML, which you can bring across into Tropy's Notes pane. This is the same layered thinking behind any well-planned digitization workflow, where capture, description, recognition, and publication are distinct stages. Note that neither tool is a scanner: both begin once you already have images, so capturing them remains your responsibility.

Why does general OCR fail on historical handwriting?

General-purpose OCR is engineered for clean, modern, high-contrast type, not manuscript hands. Tesseract reads printed text in over 100 languages but does not transcribe handwriting at all, and DEVONthink's ABBYY-derived OCR operates on printed text only, with handwriting explicitly unsupported. Feeding a photographed will or parish register to a generic engine returns unusable output because handwritten text recognition is a distinct problem from OCR. Even specialist HTR is demanding: out-of-the-box engines on unconstrained handwriting routinely exceed 20% character error rate, and reaching the low end typically requires per-corpus or per-hand model training with substantial ground-truthed data.

Why is a fluent transcription from a chatbot dangerous?

Because it produces readings that are wrong but read well. General LLMs downsample the high-resolution images that manuscript reading depends on, and they fail on historical handwriting in a particular way: they generate fluent, plausible prose that is not faithful to the page. A specialist engine that stumbles tends to err on individual characters or words — visible, recoverable mistakes you can catch against the image. A fluent fabrication is far harder to catch precisely because it reads so smoothly. For work whose defensibility depends on the text matching the source, that is the error you least want pasted into your notes and later cited.

How accurate is Leo compared to other transcription tools?

On a randomized 97-image sample of early-modern English manuscripts from the Folger Shakespeare Library, at ATR-1's release, Leo scored roughly 5% character error rate — 61% fewer errors than the next-best model tested, with Transkribus/Text Titan I at about 13%, Claude Opus about 23.3%, Gemini 2.5 Pro about 24.8%, and GPT-4.1 about 56.7%. That is a single corpus of English secretary-hand material, not a universal claim; results vary with hand, language, and image quality, and any transcription still needs verification against the image. Leo's ATR-1 engine is zero-shot, so there is no per-corpus model to train before you start.