Why Is OCR Output Full of Errors? Causes and Fixes

OCR output is full of errors for one of three reasons: the page image is too poor to read, the software misjudged the layout, or the engine was not built for that kind of text. Find which one applies by zooming in on the image, then fix the input, change the tool or proofread.

Most people respond to bad output by trying a different converter, and sometimes that works. Often the second tool fails on the same lines, because the fault is in the picture and both tools were given the same picture. Ten minutes of diagnosis saves an afternoon of trial and error.

Suppose the page is a letter you will quote for an admission. You read the sentence character by character, because one swapped word changes what was admitted. If the line is headed for impeachment, compare it with the scan before it reaches a draft.

What causes OCR errors?

OCR errors come from the image, the layout or the engine. The image may not hold enough detail for the letters to be told apart. The software may read good letters in the wrong order or miss a region. Or the engine may be weak on that typeface, language or handwriting.

Image causes. These produce wrong characters.

• Too few dots per letter. Faxes, screenshots and scans at low resolution draw each character with so few pixels that an "e" and a "c" are the same shape. The documentation for the open-source engine Tesseract says it works best on images of at least 300 dpi.
• Lost gray. A scan saved as pure black and white turns faint text into nothing and thick text into blobs. The same documentation notes that converting to black and white can go badly when the background is of uneven darkness.
• Noise. Speckle, toner dust, punch holes and the dark borders at the edge of a scan can be picked up as extra characters.
• Generation loss. A copy of a copy thickens some strokes and breaks others.
• Compression. A PDF saved at "smallest file size" surrounds each letter with smudges.

Layout causes. These produce right characters in the wrong place.

• Skew. A tilted page makes text lines hard to separate, so lines merge or lose their ends.
• Columns and tables. Text is read across two columns as if they were one, or table cells slide into the wrong row.
• Overlaps. A stamp, a signature or a handwritten note across typed text hides part of it.
• Regions skipped. A letterhead, a footer or a text box is classed as a picture and never read.

Engine causes. These produce consistent errors on a clean page.

• Unusual type. Typewriter faces, dot-matrix print, very small or very condensed fonts.
• Unfamiliar words. Many engines lean on a vocabulary to settle doubtful letters. That helps with "the" and hurts with surnames, drug names and citations, which may be "corrected" into ordinary words.
• Handwriting. An engine built for print does poorly on it. The post on what OCR can read in handwritten notes covers the limits.
• Language and symbols. Accented names, section signs and currency symbols outside the engine's expected set.

There is a fourth source that is not OCR at all. A PDF may already carry a poor text layer from the scanner that made it. When you copy from that file you are reading old output, and nothing you do in your PDF viewer will change it. Run recognition again from the page images.

How do you tell a bad scan from a bad OCR engine?

Tell a bad scan from a bad engine by looking at the image where the error occurred. Zoom to 400% on the wrong word. If you cannot read it yourself, the scan is at fault. If it is plainly legible and still wrong in the output, the software or its reading of the layout is at fault.

Then look at how the errors are spread.

Three quick experiments settle most doubtful cases:

1. Run a control page. Convert a clean, typed page from the same tool. If that comes back right, the tool works and your problem page is the variable.
2. Run the same page through a second tool. If both fail on the same words, blame the image. If they fail on different words, the engines differ and one may suit this document better.
3. Check for an existing text layer. Select text in the original PDF and paste it. If garbage comes out before you have converted anything, the file arrived with bad text inside it.

The post with the triage checklist for a low quality PDF goes further on judging the input before you spend time on it.

The error patterns that matter in legal text

The error patterns that matter in legal text are the ones spellcheck cannot see and a reader will not question: wrong digits, wrong names, changed dates, dropped negatives and altered citations. A garbled word announces itself. A 3 that became an 8 does not.

• Numbers. 3 and 8, 5 and 6, 1 and 7, 0 and 6 swap. Decimal points vanish, so $1,250.00 becomes $125,000 or $1,25000. Commas become periods. A minus sign or the parentheses around a negative figure disappear, turning a debit into a credit.
• Letters for digits. O for 0, l or I for 1, S for 5, B for 8. These wreck account numbers, VINs, parcel numbers and Bates numbers, where there is no context to correct them.
• Dates. One digit changes the month or the year. Watch 2013 and 2018, 01 and 07, and dates where a slash was read as a 1.
• Names. "Hernandez" becomes "Hemandez" when r and n merge. "Clark" becomes "Dark". Vocabulary-driven engines may replace an unusual surname with a common word.
• Negatives and small words. "not" dropped at a line break. "shall" and "shall not" differ by a word that sits at the edge of the page. "or" read as "of", "and" lost between columns.
• Citations and section references. The section sign read as S, 5 or 8. Subsection letters and numerals confused: (l) and (1), (i) and (1), (v) and (y). Roman numerals misread as letters and digits: "III" as "Ill" or "111".
• Defined terms. Quotation marks and capitals lost, so a defined term reads as an ordinary word.
• Emphasis and structure. Strike-through read as live text. Footnote numbers fused onto the preceding word, giving "damages3". A header or page number spliced into the middle of a sentence that crosses a page break.
• Hyphens. A word split at a line end kept as "indem- nify", which then fails every search for "indemnify".

Model-based readers add a pattern of their own: fluent text that the page does not contain. Instead of "Hemandez", you get a clean, confident, wrong sentence. The post on how AI OCR differs from classic OCR explains why and what to ask about it.

Proofreading OCR output against the original

Proofread OCR output by comparing it with the page image, in a fixed order, with the checks matched to the stakes. Reading the output alone is not proofreading, because the errors that matter read as normal text. You need the original in view for every item you verify.

Set up the comparison

Put the page image and the output side by side on one wide screen or two. Match page for page before you match word for word. Confirm the page count is the same, and that page 12 of the text is page 12 of the scan.

Exports help here if you pick the right one. In Schema Law's Word export, each source page starts a new page, so the two stay aligned. The plain text export separates pages, and the Excel export puts body text on a sheet with a page number beside each block. Any of those lets you go from a line of output to the page it came from. One limit: the text layer in the searchable PDF export is placed down the page in reading order, not under each individual word, so clicking a search hit takes you to the right page and you find the word on it by eye.

Check in this order

1. Completeness. Page count, then first and last line of each page. Missing pages and skipped blocks are the errors no later step will catch.
2. Structure. Headings in order, paragraph numbering unbroken (a jump from 4 to 6 means 5 was lost or misread), columns read in sequence, tables with the right number of rows.
3. Critical facts. Every amount, date, name, address, identifying number and citation, each read character by character against the image.
4. Arithmetic. Add line items and compare with stated totals. Check that date ranges run forwards. Count the digits in phone, account and ZIP numbers.
5. Operative language. Read the sentences that create obligations, deadlines or exceptions in full, watching for a lost "not".
6. Everything else. Read through or sample, depending on what the text is for.

Techniques that find more

• Read digits aloud in pairs. "Four one, two seven" from the image against the output. Slower, and far more reliable than glancing.
• Two people for anything that will be filed. One reads the original aloud, including punctuation. The other follows the output.
• Search for telltales. Find "rn", "l1", "O0", "- " and " " (two spaces) in the output. Each hit is a place to look.
• Compare against a known version. If you hold an earlier draft or a typed copy of the same document, run a comparison in your word processor. Every difference is either a real change or an OCR error.
• Sample by rule, not by mood. For long documents you will not read in full, check a fixed pattern such as every fifth page plus every page with a table, and widen it if you find errors.

Record what you did

Note who checked the document, against which file, and how far the check went. Mark anything unreadable as unreadable instead of guessing. If the text will be relied on later by someone who was not there, that note tells them how far they can trust it.

Fixes ranked by effort

Fixes rank from free to expensive: get a better source file, correct obvious capture faults, run recognition again, rescan from paper, and finally proofread or retype. Start at the top. Each step down costs more time.

1. Ask for the native file. A PDF saved from the word processor or records system that created the document has exact text and needs no OCR. Always ask before working on a scan.
2. Find a better copy you already hold. The emailed version instead of the faxed one. The first-generation scan instead of the one that was printed and scanned again.
3. Fix orientation and skew. Turn sideways pages upright and straighten tilted ones. The guide to how to OCR a crooked scan has the steps.
4. Stop damaging the image. Use the full-size file, not one that was compressed for email or run through "reduce file size".
5. Run recognition again from the page images. If the file came with a poor text layer, replace it. If your first tool did badly on a clean page, try another. Schema Law's free plan reads one document a day of up to three pages, which is enough to compare on your own problem page. The pricing page lists the paid limits.
6. Rescan the paper. If you have the original, scan it properly. Scanner settings are covered in the guide to digitizing law firm paper files.
7. Proofread and correct. For the passages you need, fix the text by hand against the image.
8. Retype. For a short passage from a hopeless page, typing it is faster than correcting it.

Two things to avoid. Do not enlarge or sharpen a poor image in a photo editor and expect better text, because no editing adds detail that was never captured. And do not run find-and-replace across a document to repair a recurring error without reviewing each hit. Replacing every "l" before a digit with "1" will fix ten account numbers and break a subsection reference.

How much accuracy a legal task needs

How much accuracy a legal task needs depends on what happens if one character is wrong. Searching tolerates errors. Quoting and filing tolerate none. Calculations need every digit. Set the level of checking by the use, not by a headline accuracy percentage.

Percentages mislead here. A page of single-spaced text holds roughly 3,000 characters. Output that is 99% correct at the character level still has about 30 wrong characters on that page. If they fall in "the" and "and", nobody is harmed. If one falls in a payoff figure, the percentage was irrelevant. No vendor's stated figure, measured on its own test pages, predicts where the errors will land on yours.

When a search matters, remember that OCR errors hide documents. A name misread on the one page where it appears will not be found by searching for the name. Search for fragments, for likely misreadings and for nearby words. For quotations specifically, the post on how to quote text from a scanned PDF sets out a tighter routine.

Whatever the task, keep the page image with the text. The image is what the document says. The text is a tool for finding and reusing it, and the export formats Schema Law offers include a searchable PDF that keeps the two in one file.