# KleioBase vs Transkribus: Text Output or Research Intelligence?

Transkribus is a handwritten text recognition platform you can train on a specific hand. KleioBase is a research companion whose product is the analysis, not the text. Here is which problem each one actually solves, and when the answer is Transkribus.

Claims about Transkribus last verified 2026-09-21.


You have 400 pages of one parish register, photographed on a single trip, written by two priests over thirty years. Or you have 60 documents from four countries, collected over a decade from three different relatives, in four scripts, with nothing in common except that they are all about your family.

Those are different problems. Transkribus is built for the first one. KleioBase is built for the second.

**The short answer.** These are not really substitutes, because only one of them is in the analysis business. Transkribus is a handwritten text recognition platform whose distinguishing feature is that you can train a custom model on a particular hand and run it across thousands of pages. Its deliverable is text mapped to the document layout. KleioBase's deliverable is research intelligence over a connected archive: who these people are across every source, which two profiles are the same person, which dates contradict each other, which generation is missing. Transcription is one way data enters that archive, not what the archive is for. If your problem is volume in one consistent hand, use Transkribus. If your problem is that you cannot see your own evidence clearly, that is the other thing.

## Reading a document is an input, not the product

Worth stating plainly, because the shape of this comparison hides it: KleioBase is not a transcription tool. Transcription is one of two ways to get data in. The other is a GEDCOM import, and a researcher who imports a tree and never uploads a single scan still gets the whole product - duplicate detection across the tree, conflicting dates surfaced as conflicts rather than silently overwritten, missing generations flagged as gaps, a tree health score, and a companion that can be questioned about the whole archive in plain language.

That is the product. The reading step exists so that documents can join the same analysis, not because text is the deliverable.

## Transkribus wins on a homogeneous corpus

Model training is the thing Transkribus has that almost nothing else does. You correct a sample of pages by hand, the platform trains a recognition model on that specific handwriting, and the model then reads the rest of the collection considerably better than any general-purpose model would.

That is a real advantage, and it is worth being clear about when it pays off. Training has a fixed cost in your time, and it earns that cost back across volume. Four hundred pages of one clerk's hand is exactly the shape where it pays. Sixty documents in sixty different hands is exactly the shape where it does not, because you would be training sixty models.

Transkribus also does structural work that general models handle less reliably: line detection, table recognition, and field recognition, each priced as its own step. For a columnar census page or a ledger, the layout is half the information, and Transkribus treats it that way.

## The pricing models measure different things

Transkribus charges in credits. A free tier gives 50 credits a month, which the platform describes as roughly 50 pages. The Scholar tier is €99 a year for 900 credits, and there is a Team tier and a quote-based organisational tier above it. Prices are quoted including Austrian VAT at 20 per cent. On-demand credit packs are available without a subscription and do not expire, while subscription credits last only for the billing period.

One thing to read carefully rather than take from us: at the time of checking, the Transkribus pricing page listed the Team tier at €449 a year on the plan card and €399 a year in the FAQ further down the same page. Check the figure yourself before you budget on it.

The credit arithmetic is where the comparison gets slippery. Handwritten text recognition costs one credit per page, but table recognition and field recognition cost extra and still require text recognition underneath them, so a structured page can consume two or more credits. A flat page count is not a reliable estimate of what a real collection will cost.

KleioBase prices by processing credits per record with a free Explorer tier, and the [pricing page](/pricing) has the current figures. The honest comparison is not the headline number. It is that a Transkribus credit buys you a transcription and a KleioBase credit buys you a transcription, a translation, and the extraction and linking that follow it. Whether that is worth more depends entirely on whether you need the linking.

## Neither tool is a records database

Worth stating plainly because it catches people: neither of these is a place to go and find records. Transkribus reads documents you supply. KleioBase reads documents you supply. If you do not yet have images of your ancestors' records, the tool you need first is a repository such as FamilySearch or Ancestry, and our [comparison with FamilySearch Full-Text Search](/compare/kleiobase-vs-familysearch-full-text-search) covers that boundary.

## Side by side

| | Transkribus | KleioBase |
| --- | --- | --- |
| Core job | Handwritten text recognition at scale | Linking records into one connected archive |
| Custom model training | Yes, on all tiers | No |
| Translation to English | No | Yes, alongside the original-language transcription |
| Layout, tables, fields | Line, table and field recognition as priced steps | Structured extraction of people, dates and places |
| Cross-document person linking | No | Yes, with duplicate detection |
| Questioning your whole collection | No | Yes, in plain language |
| Free tier | 50 credits a month | Explorer plan |
| Best shape of problem | Many pages, few hands | Few pages, many hands and languages |

## When Transkribus is the better answer

**You have a large corpus in one hand.** Hundreds or thousands of pages from one register, one notary, one clerk. Train the model and let it run. Nothing we do competes with that.

**You need the layout preserved precisely.** Tables, columnar registers, forms where cell position carries meaning. Transkribus maps text to layout as a first-class output.

**You are building a searchable edition.** Transkribus Sites turns a transcribed collection into a published searchable edition. That is a different deliverable from a family archive and we do not produce it.

**You are working in a script with a trained public model.** The Super Models cover a lot of ground, and for some scripts a specialist trained model simply reads better than a general one.

## What KleioBase does instead, and what it does not

We are a tool in this space, so read this as disclosure rather than neutral assessment.

KleioBase is an analysis layer over your whole archive. Whatever the source, a GEDCOM import or a scan you photographed in an archive, everything lands in the same structured model of people, dates, places and relationships, and the work happens there: it matches people across every source, so the Maria Kowalska in an 1871 baptism and the Marya Kowalski in an 1893 marriage register become one profile with a documented life rather than two entries in a spreadsheet. It flags likely duplicates, raises conflicting evidence as a conflict instead of letting the last edit win, surfaces [research gaps](/what-is/negative-evidence), scores how complete and connected a tree is, and lets you put a plain-language question to the whole collection at once.

When a document does need reading, it is read and translated on the way in. That is the input adapter Transkribus competes with, and it is genuinely the smaller half of what is happening.

That matters most on exactly the pile Transkribus is least suited to: mixed languages, mixed hands, mixed decades, collected slowly. We read [German Kurrent](/transcribe/german-records), [Latin parish registers](/transcribe/latin-parish-records), [Cyrillic revision lists](/transcribe/russian-cyrillic-records), [Hebrew](/transcribe/hebrew-records) and [Yiddish](/transcribe/yiddish-records) without you choosing a model first.

Now the honest limits.

**No model training.** If a general model misreads a particular clerk's hand, you cannot teach it. You correct the output. Across 400 pages of that hand, that is a worse deal than training a model once.

**No layout-faithful table output.** We extract structured genealogical data, not a reconstruction of the grid. For a record where column position is the meaning and you need the grid preserved, Transkribus does this properly and we do not.

**We are not a repository.** We only know the records you give us. Nothing is searched on your behalf across external archives.

**Extraction is reviewed, not trusted.** Every reading is shown to you before it enters your archive, which is a deliberate design choice, but it does mean a large batch carries real review time. There is no version of this where you upload 400 pages and walk away.

## Where to start if you are choosing this weekend

Count your documents and count the distinct hands. If the ratio of pages to hands is above roughly fifty to one, try Transkribus first and train a model. If it is below ten to one, the training step will cost you more than it returns, and the linking is where your remaining hours actually go.

If you land in between, the combination is legitimate. Train in Transkribus for the bulk register, then bring the whole collection, register and strays alike, into KleioBase so the people in them end up in one place. Both platforms have a free tier large enough to test the fit on a handful of your own pages, which is a better basis for deciding than any table we could write.

Canonical: https://kleiobase.com/compare/kleiobase-vs-transkribus