FamilySearch Full-Text Search: What It Finds, What It Misses, and When to Transcribe the Image Yourself

FamilySearch Full-Text Search is a discovery layer, not a reading layer. This article sets out what its machine-generated transcripts can find, where they tend to fail — surnames most of all — and when you should stop searching, open the image, and transcribe it yourself.

The service runs your query against machine-generated transcripts of digitized record images, including nearly two billion records that traditional indexing has never touched, and returns pages where the machine's reading matched your words. That makes it unusually good at finding unindexed deeds, probate files, and land books. It is not a tool for reading them. FamilySearch itself warns that the AI transcripts may contain errors and tells you to inspect the original image. Treat a hit as a lead to an image, and do your own transcription whenever a name, a relationship, a date, a legal transfer, or a negative conclusion is going to sit in your tree.

That distinction — search layer versus reading layer — governs everything below. Get it right and Full-Text Search will open lines that have been stuck for years. Get it wrong and you will paste a machine's guess into your family tree and cite it as a record.

What the tool actually is

FamilySearch describes Full-Text Search as using AI and handwriting-recognition technology to create transcripts of records that traditional indexing has not yet made searchable, then scanning those transcripts for matches rather than searching a small set of curated fields. The Full-Text Search landing page offers keyword, name, place, year-range, and image-group-number search, and supports the operators `" "`, `+`, `-`, `?`, and ``.

Two terms are worth pinning down, because the difference explains most of what follows. OCR — optical character recognition — is built for printed and typed glyphs with predictable letterforms. HTR — handwritten text recognition — must infer text from variable individual hands, changing script conventions, line segmentation, and context. The broader HTR picture matters here: Full-Text Search is doing the harder of the two jobs, at continental scale, on material nobody has previously indexed.

The product history is short. It was announced and released in FamilySearch Labs at RootsTech 2024, then folded into standard search on 30 August 2025. The Labs-exit page documents rolling additions since — over a billion records in April 2026, over 256 million in May, 103 million in June. Those are dated product snapshots, not figures to add together, and they tell you something useful: coverage is a moving target. What isn't findable this month may be findable next.

The retrieval path — and where it breaks

Understanding the mechanism is what turns a frustrated searcher into an effective one. The path is:

image scan → automated recognition → stored transcript and search index → your query → hit.

The first three steps happen before you arrive. What the search matches is not the handwriting on the page. It is a stored string of characters that a machine produced from that handwriting. Your query never touches the manuscript.

Follow that through and the failure mode is clear. If the deed says Beecher and the recognizer stored Bracher, a search for "Beecher" has no stored token to match. No amount of clever querying bridges that gap, because wildcards and fuzzy matching operate on the index, not on the image. A `?` will get you from Beecher to Beacher. It will not get you to Bracher. This is an inference from the documented design, not a published FamilySearch error study — but it is the inference that should shape your search behaviour.

FamilySearch has not published a model name, training corpus, segmentation method, confidence threshold, or per-collection recall figures, and no independent CER or WER benchmark specific to Full-Text Search exists in the literature. A help article on why transcript editing is unavailable explains that editing is disabled during an update, citing privacy and record-owner concerns — which is a maintenance notice, not a statement that transcripts are human-reviewed. So the honest position is that we know the design and not the accuracy.

What the wider HTR literature tells us is that accuracy varies enormously by corpus, hand, language, and layout. Sánchez and colleagues' benchmark work in Pattern Recognition reports best word error rates around 9–14% across four datasets — 9.3% on modern English handwriting, 11.2% on French correspondence, 10.1% on seventeenth-century Catalan marriage registers written by a single hand, roughly 14% on a 1545 Castilian manuscript. Those are single-hand, line-level, model-matched conditions. A county deed book with six clerks, a bleed-through verso, and a tabular index page is not those conditions. Numbers from controlled corpora do not transfer to page-level retrieval in the wild.

Names are the least safe part of the page

This is the counter-intuitive point most genealogists miss. A page can read fluently and still get the one word you came for wrong. Recognition systems lean on context and vocabulary; proper names, place names, and archaic spellings have no dictionary or gazetteer support behind them, which is exactly the situation the historical named-entity literature identifies as hardest. Add orthographic variation across centuries and recognition noise, and surnames become the least reliable tokens on the page — while being the only ones you actually searched for.

Reported examples are consistent with this. A Family Tree Magazine review in April 2025 found readings such as Campbell → Campbee, Reiss → heirs, and Joseph → "J Piph". Anecdotal, not a population study — but note the shape of the errors. Reiss becoming heirs is not garble; it is a plausible word in a probate context, and nothing about it looks wrong in a search snippet.

How to search what the machine may have written

Once you accept that you are querying a machine's reading rather than the record, search strategy changes. You stop asking "how do I spell my ancestor's name" and start asking "what might the recognizer have put on this page."

Query the record type, not just the person

Land and probate books are formulaic. The words grantor, grantee, heirs, executor, administrator, witness, dower, quitclaim, messuage, and appurtenances appear on thousands of pages and — being common, high-frequency vocabulary — are more likely to be recognized correctly than a rare surname. Combine a legal phrase with a place and a year range and you can narrow to a handful of pages you can read yourself. This is often faster than fighting the name field.

Use the operators deliberately

Phrase search in quotation marks for fixed legal formulae. `+` to require a term. `-` to strip out a common namesake swamping your results. `?` for a single uncertain character, `` for a run of them — useful where you suspect the hand's terminal letters were misread, e.g. `Beech`.

Search adjacent evidence

An occupation, a farm name, a witness, a neighbouring landowner, a mill or a creek. Names cluster: find the neighbour and you often find the page.

Search the same target several ways

Spelling variants, the wife's name, the mother's maiden surname, a distinctive middle name. Each query is a separate throw against a different set of stored tokens.

Treat a null result as a search failure, not evidence of absence

A negative hit means one of three things: the collection is outside current coverage, the page was never digitized, or your query didn't match what the machine stored. None of those means the record doesn't exist. Fall back to catalog browsing by locality and date, then to image-group browsing — the older, slower method that still finds what search can't.

When to stop searching and transcribe the image yourself

There is a clean line here, and it comes from genealogical standards rather than from technology.

Use the machine reading for discovery and triage: locating candidate pages, deciding which of forty deed images is worth an hour, getting the gist of a long probate packet. Do your own transcription when the record is going to carry weight — a name in your tree, a parent-child relationship, a land transfer that establishes residence, a date that resolves a conflict, or a negative conclusion you intend to publish.

The Board for Certification of Genealogists' guidance on converting records into reliable copies is explicit about what a transcript owes the source: don't correct, modernize, or standardize spelling, punctuation, or dating, and place any addition of your own in square brackets so your words are visibly distinct from the writer's. A machine transcript optimized for search does not meet that bar, because search rewards a plausible modern reading and scholarship rewards a faithful one. The same principle sits behind the Genealogical Proof Standard: reasonably exhaustive research, accurate citation, correlation, conflict resolution, written conclusion.

Citation follows the same logic. Evidence Explained's guidance on layered citation of FamilySearch digital microfilm puts the original volume and page in one layer and the website providing the images in another. A Full-Text hit gives you the second layer. You still have to open the image to get the first.

If you're new to doing this properly, the mechanics of faithful genealogy record transcription — verbatim copying, the difference between a transcript and an abstract, how to handle dates and abbreviations — are worth an evening. For the paleography itself, guides to reading old handwriting and to secretary hand cover the letterforms that mislead most often, and record-specific method exists for wills, parish registers, and census returns.

Transcribing the pages you found

The awkward reality is that a good afternoon on Full-Text Search leaves you with forty screenshots and a reading problem. That is the stage where a purpose-built transcription tool earns its place — and where the choice of tool matters more than most people expect.

The instinct is to paste the image into ChatGPT, Claude, or Gemini. Don't, for the same reason you shouldn't trust a search snippet: general models downsample the image and lean heavily on their language model, so they err by producing fluent, plausible text that reads like a period document and isn't one. That failure mode is specifically dangerous for genealogy, because a fabricated legatee or a smoothed-over surname looks exactly like a real one. Specialist HTR fails differently: it errs on characters and words you can catch against the image beside it.

Leo is built for that stage. Its transcription model, ATR-1, is specialized for Latin-script documents of roughly the past five hundred years — which means the alphabet, not the language: English wills, French notarial acts, German Kurrent parish books, Dutch and Spanish registers are all in scope, while Greek, Cyrillic, Hebrew, Arabic, and East Asian scripts are not. It runs zero-shot, so there is no model to train before you can read your deed book. It preserves what is on the page — strikethroughs, insertions, marginal notes, abbreviations, archaic spelling — rather than normalizing it into modern prose, which is precisely the property BCG's verbatim standard requires. Transcription and translation stay separate jobs: the base reading stays in the source language, and Translate is a distinct operation that writes to its own tab, leaving the original untouched.

On accuracy, the only figures worth quoting are measured ones. 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 against about 13% for Transkribus's Text Titan I, 23.3% for Claude Opus, 24.8% for Gemini 2.5 Pro, and 56.7% for GPT-4.1 — 61% fewer errors than the next-best model, with the full comparison published here. One corpus, one language, one point in time; treat it as directional and, better, test any tool on your own pages before you rely on it.

Two honest limits. First, no character error rate is zero, and the workflow assumes you read the transcription against the image — Leo shows them side by side for that reason. Second, the known weak spot is directly relevant here: pages that combine dominant printed structure with dense handwriting, such as pre-printed deed and ledger forms, where the model can favour the printed headers over the manuscript entries. On those pages, expect to work harder.

Students, academics, and archives can apply for free credits through the Leo Transcription Grant, on the condition that the resulting transcriptions and images are published openly — which requires holding or clearing the rights to publish them.

Working the two layers together

The productive habit is to treat Full-Text Search and your own transcription as two distinct layers of the same research, each doing what the other cannot.

The search layer buys you recall. It looks inside nearly two billion images no human indexer has reached, in seconds, for free. That matters for anyone whose ancestor appears only as a witness on a deed or a residual legatee in someone else's will — the records traditional name indexes were never going to surface.

Your transcription layer buys you fidelity: a verbatim reading, tied to a specific volume and page, with your uncertainties marked and your editorial additions bracketed, which you can put in front of another researcher and defend.

Confusing the two is how errors propagate. A machine transcript copied into a tree becomes a fact, gets copied again, and within a year appears in three other people's research with no image behind it. The record it came from still says what it always said; nobody has looked.

So run the searches. Run more of them than feels necessary, from more angles, and re-run them in six months when coverage has moved. Then open the image, read the hand, and write down what is actually there. The tools have changed which records you can find. They have not changed what it takes to know what a record says.

Frequently Asked Questions

What is FamilySearch full text search and how does it work?

FamilySearch Full-Text Search runs your query against machine-generated transcripts of digitized record images, including nearly two billion records that traditional indexing has never covered. AI handwriting recognition reads each scanned page, stores a transcript, and indexes it; your search matches that stored text, not the handwriting itself. It supports keyword, name, place, year-range, and image-group-number searching, plus the operators `" "`, `+`, `-`, `?`, and ``. It was released in FamilySearch Labs at RootsTech 2024 and folded into standard search on 30 August 2025. Treat a hit as a lead to an image, not as a reading of it.

Why can't I find my ancestor's surname in FamilySearch Full-Text Search?

Most likely because the recognizer stored a different string than the one you typed. Search matches the machine's reading, so if a deed says Beecher and the transcript says Bracher, there is no token to match — and wildcards won't bridge it, because they operate on the index rather than the image. Surnames are the least reliable words on a page: proper names have no dictionary or gazetteer support behind them, unlike common legal vocabulary. Try searching the record type instead (grantor, heirs, executor) with a place and year range, search adjacent evidence like neighbours or witnesses, and try spelling variants.

Are FamilySearch full-text transcripts accurate enough to cite?

No — cite the record, not the transcript. FamilySearch itself warns that AI transcripts may contain errors and directs you to inspect the original image. It has not published a model name, training corpus, confidence threshold, or per-collection recall figures, and no independent error benchmark specific to Full-Text Search exists. Reported misreadings include Campbell rendered as Campbee and Reiss as heirs — plausible-looking words that don't announce themselves as wrong in a snippet. Evidence Explained's layered citation approach puts the original volume and page in one layer and the website in another; a Full-Text hit gives you only the second.

Does a null result in Full-Text Search mean the record doesn't exist?

No. A negative hit means one of three things: the collection sits outside current coverage, the page was never digitized, or your query didn't match what the machine stored. None of those is evidence of absence. Coverage is also a moving target — FamilySearch has documented rolling additions since the tool left Labs — so a search that fails today may succeed in six months. When a search comes up empty, fall back to catalog browsing by locality and date, then image-group browsing: slower, but it still finds what search cannot.

Should I use ChatGPT to transcribe the record images I find?

Not for genealogy. General-purpose models downsample images and lean heavily on their language model, so they fail by producing fluent, plausible text that reads like a period document but isn't one — a fabricated legatee looks exactly like a real one. Specialist handwriting recognition fails differently, erring on characters and words you can catch against the image. On a randomized 97-image sample of early-modern English manuscripts from the Folger Shakespeare Library, Leo's ATR-1 model scored roughly 5% character error rate, against 23.3% for Claude Opus, 24.8% for Gemini 2.5 Pro, and 56.7% for GPT-4.1. Always read any transcription against the image.