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; our guides to making an Omeka S collection full-text searchable and to keeping transcriptions beside citations in Zotero pick up where those exports land. 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. 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 models have improved quickly on handwriting, but they downsample the high-resolution images that manuscript reading depends on, and when they go wrong on historical material they go wrong in a particular way: the reading stays fluent. Most often they quietly modernize, putting a familiar spelling in place of the one on the page; on a hard page they can supply words that are not there at all. A specialist engine that stumbles tends to err on individual characters or words, which are visible, recoverable errors you can catch against the image. A fluent reading 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 is specially tuned for historical documents and reads the image at high resolution, and it is trained to transcribe what is on the page rather than normalize it. Strikethroughs, marginal additions, expansions, archaic orthography and abbreviation marks are preserved; it does not over-correct or silently modernize. Output that trips its failure detection is hidden, retried, and refunded if it cannot succeed, and the errors that do get through are the recoverable kind, a wrong letter you check against the image beside the text. That is the property you want when the transcription has to stand up in published work.

ATR-1 is the default in Leo's model library: one menu in the transcription window, with the major OpenAI, Gemini and Claude models alongside if you want a second reading of a hard page in its own tab, and small models that read clean, legible print, such as a nineteenth-century book or a typescript, for a fraction of a credit an image. Whatever reads the page, the transcription still needs checking against the image, and the best test of any model is a sample of your own photographs.

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, with nested folders, per-document metadata, multiple tabs per image, and full-text search, and you avoid maintaining two systems. 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. 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 have AI or OCR to transcribe handwriting?

No. Tropy organizes and describes photographs of primary sources but has no built-in AI, OCR or handwriting recognition, so it 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. Its developers have described text recognition as a long-term goal, to be delivered 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, such as Leo's ATR-1, and paste the result in or keep the text in that engine's own workspace.

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 its mistakes read well. General models have improved on handwriting, but they downsample the high-resolution image that manuscript reading depends on, and on historical material their typical slip is quiet modernization: a familiar spelling in place of the one on the page, or on a hard page a word that is not there. A specialist engine that stumbles tends to err on individual characters or words, which are visible, recoverable mistakes you can catch against the image. Leo's ATR-1 is built for exactly this: specially tuned for historical documents, trained to transcribe what is on the page rather than normalize it. For work whose defensibility depends on the text matching the source, a fluent error is the one you least want pasted into your notes and later cited.

How does Leo's ATR-1 handle historical manuscripts?

ATR-1 is specially tuned for historical documents, handwritten and printed, in any language written in the Latin alphabet. It reads the image at high resolution, runs zero-shot with no per-corpus model to train, and transcribes what is on the page rather than normalizing it: abbreviations, deletions and archaic spelling survive. Suspect output is hidden, retried, and refunded if it cannot succeed, and errors that get through are recoverable, a wrong character or word you check against the image beside the text. Results vary with hand, language and image quality, so test it on a sample of your own photographs; any transcription still needs verification against the image.