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 is built as both a reader and a collection hub: upload (including straight from a phone camera in the reading room), nested folders with a simple, Dropbox-like layout, the original image shown beside its transcription, and a structured archival metadata field set (Title, Creator, Date, Archive, Type, Collection, Box, Folder, Identifier, Rights). Each image can hold multiple transcription and annotation tabs — ATR-1, a translation, a summary, named-entity extraction — rather than a single notes field, so readings and analysis stack without overwriting the base text. Global fuzzy search runs across every transcription in the collection, and export goes to Word, PDF, HTML, or TEI XML. For most historians who mainly need to keep archive photos ordered, findable, and readable, that organizer-plus-reader combination is enough on its own. Tropy still goes further when the project depends on elaborate, extensible metadata templates, fine-grained selections, or a local open-source stack — especially common in art-historical and object-heavy work — but the reading step, and day-to-day collection management for text-first research, is what Leo is built to carry.

Choosing between them — or using both

For a decision, the questions are concrete.

If your problem is organization alone

You have thousands of photos and care first about structure and description. If you need a free, open, locally controlled desktop tool with extensible Dublin Core/RDF templates, fine-grained selections on the image, and IIIF import — the profile common in art-historical and object-heavy projects — Tropy is still the stronger pure organizer, and those strengths are genuine. If what you actually need is a clear folder hierarchy, light archival metadata, side-by-side image and text, and room to grow into full-text search once pages are read, Leo’s workspace is built for that and is more than enough for most researchers managing collections of archival images. The deciding question is whether elaborate metadata is the product, or whether organization is a means to reading.

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 into Tropy's Notes pane, and Tropy continues to do the deep descriptive organizing it does well. That paired setup is ideal when your templates, selections, or local/IIIF workflow are doing real scholarly work you do not want to rebuild. If your Tropy project is mostly folders of archive photos with light metadata, and what you lack is searchable text, Leo is often enough to carry both organization and reading in one place — nested folders, per-document metadata, multiple tabs per image, and full-text search — without maintaining two systems. For the practical handoff from a collection you have already sorted, see Adding Transcription to Tropy: Reading the Photos You've Already Organized. The tools are complementary as much as competitive; the right answer depends on how elaborate your descriptive requirements really are. 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. If you already keep research photos in Tropy and need the reading step, Adding Transcription to Tropy: Reading the Photos You've Already Organized walks through how to add HTR without throwing away the organization you built. 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. You can run them side by side, or let Leo cover both organization and reading if your descriptive needs are moderate. Tropy remains the stronger choice for elaborate, extensible metadata templates, image selections, IIIF import, and a free local open-source stack — requirements that show up often in art-historical and object-heavy projects. Leo reads Latin-script manuscript and printed pages into searchable text and also organizes the collection: nested folders, per-document archival metadata, multiple transcription and annotation tabs per image, side-by-side image and text, and fuzzy search across every transcription. Many historians who mainly need ordered archive photos plus full text find Leo enough without keeping a second system; others keep Tropy for description and export Leo’s text into Tropy’s Notes pane. Neither tool is a scanner — both start from images you already have.

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.