OCR Hallucination: When Software Adds Words to a Page

An OCR hallucination is text in the recognized output that is not on the page: a word, a figure, a sentence or a whole paragraph that the software produced and the paper never held. Yes, OCR can add words. You notice only by comparing the output with the page image, because invented text reads as smoothly as real text.

The term comes from the vocabulary of language models. It matters to a lawyer for a plain reason. A garbled line sends you back to the original. A clean, plausible line does not.

What is an OCR hallucination?

An OCR hallucination is output that reads as ordinary text and has no source on the page. It differs from a misread, where the software looked at real ink and reported the wrong character. With a hallucination there may be no ink at all behind the words, or a smudge that the software replaced with something sensible.

The National Institute of Standards and Technology uses a more careful word for the same thing. Its Generative AI Profile, NIST AI 600-1, lists "confabulation" among the risks of generative systems and defines it this way:

The production of confidently stated but erroneous or false content (known colloquially as “hallucinations” or “fabrications”) by which users may be misled or deceived.

That definition covers generative AI in general. Applied to recognition, the false content is text attributed to a page.

Invented text takes several forms in a converted document:

• Completion. A line that runs off the edge of the scan is finished with words that fit.
• Filling. A faint or stained patch is replaced by a confident reading.
• Continuation. The output carries on after the page's text has ended.
• Looping. A sentence or a table row is repeated, sometimes with small changes each time.
• Substitution. A blank left for a date or a name comes back filled in.
• Tidying. A sequence the page left broken, such as paragraph numbers that skip, comes back complete.

Two things are not hallucinations, though they also put wrong characters in your text. A dictionary can pull an unusual word toward a common one, which the post on whether OCR uses a dictionary explains. And a scanner's compression can replace a character in the image itself before any recognition runs, as set out in the comparison of lossy and lossless compression.

How is an invented passage different from an ordinary misread?

An invented passage is fluent and wrong. An ordinary misread is wrong one character at a time. The misread keeps a visible trace of the ink it came from, such as "rn" for "m". The invented passage is made of correctly spelled words in grammatical order, so nothing about it invites a second look.

Here is one fictional line read three ways. The page is a lease, and a coffee ring has faded the middle of the line.

The second row is ugly, and every error in it can be traced to a shape on the paper. A spell checker flags three of the words. A reader winces and opens the scan. The third row would pass any spell checker and any skim. It is also the one that would cause a missed deadline.

The differences, side by side:

The last row is the same for both, and that is the point to hold on to. If you learned on older OCR to treat mess as the warning sign, the other rows show why that habit lets invented text through: this kind of error is tidy. Recognition gives you a reading of the picture, and the picture is the evidence of what the paper said.

Read a faint transcript with the picture open. Compare each party name with the ink, line by line. A smooth sentence can introduce a statute or a citation the sheet never printed, or assert a fact absent from the witness page. Keep the picture as your proof of what was said.

Why can a model-based reader write text that is not on the page?

A model-based reader produces its output by generating text, one piece after another, guided by the page image and by everything it learned about how language runs. Where the image gives it little to go on, what it learned about language can carry the output forward. The result is likely-sounding text, not observed text.

The National Institute of Standards and Technology describes the general mechanism in section 2.2 of its Generative AI Profile, NIST AI 600-1: "Confabulations are a natural result of the way generative models are designed: they generate outputs that approximate the statistical distribution of their training data; for example, LLMs predict the next token or word in a sentence or phrase." A system built to continue a sentence plausibly will continue it plausibly whether or not the page supports the continuation.

One published example

A research paper makes the design concrete. Nougat, a document-reading model published by researchers at Meta AI, converts images of academic pages into marked-up text. The authors write: "The model does not require any OCR related inputs or modules. The text is recognized implicitly by the network." The image goes in, and a sequence of tokens comes out.

The same authors are frank about what follows from that. Describing a failure in which the output starts repeating, they write: "The model can not recover from this state by itself." They add: "In general we notice this kind behavior after a mistake by the model." And because the model is "trained on one page at a time without knowledge about other pages in the document", they report inconsistencies across a document.

Those sentences describe one research model reading scientific papers. They say nothing about any commercial product. What they show is the shape of the problem: once a generating system makes a mistake, the mistake becomes part of the text it is continuing, and it can build on it.

Classic engines are not immune

Older, character-by-character recognition can also produce words that are not there, by a different route. The Tesseract project's FAQ for older versions of its engine, discussing settings that strengthen the dictionary, warns that such changes "also up the ability to hallucinate dictionary words." That appears in the Tesseract FAQ for older versions. The scale is different, a word at a time and not a paragraph, but the lesson is shared: any component that knows what text usually looks like can prefer the usual over the actual.

How model-based recognition differs from the classic kind in its other respects, including the questions it raises about where documents go, is the subject of the post on AI OCR for lawyers, which also lists the new failure modes to watch for.

Faint, cropped and repetitive pages where invented text is likeliest

Invented text is likeliest where the page gives the software weak evidence and the surrounding language gives it strong expectations. Faint print, cropped edges and repetitive layouts each do one or both. A rate measured on someone else's test pages does not tell you what will happen on your documents, so treat these as the pages to check first.

Developers say similar things about their own models. Anthropic's documentation on image input names low quality, rotation and very small images as conditions under which its model may make mistakes, and its guidance on vision limitations includes this instruction: "Do not use Claude for tasks requiring perfect precision or sensitive image analysis without human oversight." The authors of the Nougat paper on reading academic documents, for their part, write of their model's repetition failure that "the frequency increases for out-of-domain documents", meaning pages unlike those the model was trained on.

The boilerplate row deserves a lawyer's attention more than any other. Negotiated documents are valuable exactly where they differ from the form. An indemnity clause that drops a customary carve-out, a notice period of ninety days where the form says thirty, a governing law clause naming an unexpected state: each is a place where the page says something the usual wording does not, and where a system leaning on the usual wording has the most room to be wrong.

Repetitive pages carry a quieter risk. In a twelve-page bank statement, each row looks like the rows around it. An output that repeats one transaction or omits another still looks like a bank statement. Only a count, or a balance that fails to reconcile, gives it away.

How do you catch invented text in a converted legal document?

You catch invented text by checking the output against the page image, never against itself. Structural checks, such as counting pages, paragraphs and rows, find passages that were added, repeated or dropped. Reading the high-stakes items against the image finds the rest. Spell check and skimming find none of it.

Structural checks

1. Count pages. The output should have text for every page of the scan and for no others.
2. Match first and last words. For each page, compare the first few words and the last few words of the output with the image. Text that continues past the last line of the page was not on it.
3. Compare amounts of text. A page that is half white on the scan should give half a page of text. A short page with a long output needs reading in full.
4. Follow the numbering. Read the section, paragraph or line numbers down the image and down the output. A sequence that is neater in the output than on the paper has been tidied.
5. Count table rows. Count on the image, count in the output. Where the table has a total or a running balance, recompute it from the output.
6. Search for repeats. Copy a distinctive sentence from the output and search the output for it. Two hits where the page has one is a loop.

Content checks, on the items that carry weight

1. Read every number against the image. Amounts, dates, percentages, notice periods, section references.
2. Read every name against the image. Parties, signatories, entities, places.
3. Read every negative. "Not", "no", "except", "unless", "other than".
4. Check the blanks. Any field the page left empty should be empty in the output.
5. Check the damaged areas. Wherever the scan is faint, stained, stamped or cropped, read the output word for word.
6. Check anything you will quote. A quotation in a brief or a letter is copied from the output and verified on the image, every time.

A worked example

A fictional file: a three-page amendment to a supply agreement between Brightwater Mills and Kestrel Logistics, received as a fax and converted to Word.

Check 3 flags page 2. On the image, the page ends two-thirds of the way down, after clause 7. The output for page 2 runs longer and includes a clause 8 on "Entire Agreement". Clause 8 is not on the fax. It is a sentence of a familiar boilerplate kind, and the document's real clause 8, on page 3, concerns delivery windows. Check 4 confirms it: the output has two clauses numbered 8.

Check 7 then finds a second problem in clause 4, where the fax is faint. The image shows a price adjustment cap that can be made out, with effort, as 3.5%. The output says 2.5%, in clean type.

Neither error would have been caught by reading the Word file alone. Both showed once the image was beside it.

Two helpers

• A second, independent reading. Run the same pages through a different tool and compare the two outputs with a document comparison. Where they disagree, look at the image. Agreement is not proof, since two tools can share a weakness, but disagreement is a cheap pointer.
• A marked proof copy. Print or annotate the output with a tick beside each number and name as you verify it. An unticked figure is an unchecked figure.

The general method for reading recognized text against a scan, and how much to check on documents of different importance, is in the post on why OCR output is full of errors.

Schema Law shows the result page by page on screen so you can check it against the original before you export. The site's answers to common questions say plainly that nothing marks a passage as uncertain, and tell you to check names, dates and amounts against the original. Take that at its word: the checks in this section are yours to run.

What to ask a vendor about hallucination in its recognition

Ask a vendor how its recognition works, what it does when a passage cannot be read, and what it gives you for checking output against the page. Ask for answers in writing, and test them on your own documents. The table lists the questions and what a useful reply looks like.

Test, do not take on trust

Build a small trap set from closed matters or from invented documents, and run it through any tool you are considering.

1. A page with one line cut off at the right margin.
2. A page with a coffee ring or a heavy stamp over a figure.
3. A form with several fields deliberately left blank.
4. A table with two nearly identical rows next to each other.
5. A contract clause that departs from standard wording in one word.
6. A page that is blank except for a header.
7. A faint fax of a page with a date and a dollar amount.

For each, write down before the run what a faithful output would contain. Afterwards, mark every place where the output has text the page does not. The post on how to test OCR software covers building and scoring a fuller test set.

Two cautions about the answers you receive. A vendor's statement that its product "does not hallucinate" is a marketing sentence unless it comes with a method and results you can examine. And a good result on your trap set tells you about those seven pages on that day. It lowers your concern. It does not retire the checks.

How much verification a given use requires is a professional judgment for the lawyer responsible for the work, and the duties that apply to relying on software output vary by jurisdiction. Check the rules and any guidance from your own bar. What does not vary is the mechanics: text that will be quoted, filed or relied on for a number gets read against the picture of the page.