OCR Scanned Forms: Fields, Checkboxes and Fill-Ins

To OCR scanned forms so each answer stays with its field, stop treating the page as lines of prose. Convert it, then rebuild the pairs yourself: one row per field, holding the label, the value the software read and the value on the image. Read every checkbox from the page, never from the text.

Why is a filled-in form harder to read than a letter?

A filled-in form is harder to read than a letter because it has no single reading order. A letter is one stream of sentences. A form is dozens of small boxes, each holding a few words with no sentence around them, printed in one layer and answered in another.

Each of those features causes its own kind of trouble.

• No stream. Software has to decide whether to read across a row of boxes or down a column of them. Either choice is defensible, and either may differ from the order the form's designer had in mind.
• Two layers of ink. The pre-printed layer is small, even type. The answers were added later by a printer, a typewriter or a pen, and they rarely sit exactly where the form expected.
• Rules and boxes. The lines that separate fields are ink too. A value touching the bottom rule of its box can lose its descenders or gain an underline that reads as a row of underscores.
• Short strings. "04", "N/A", "X" and "2B" give recognition nothing to lean on. A word in a sentence can be confirmed by its neighbors. A two-character code cannot.
• Small captions. Field labels are often the smallest type on the page, tucked into the corner of a box.
• Shading and instructions. Gray "office use only" panels and italic instructions between fields get read as content.

The result is text in which every word may be correct and the form is still unusable, because you cannot tell which answer belongs to which question. Reading order in general is explained in the post on whether OCR can handle two-column documents. A form is the extreme case of the same problem.

Can OCR tell a checked box from an empty one?

OCR can sometimes tell a checked box from an empty one, but you should never rely on it. Text recognition looks for characters, and a tick is not a character. The mark may come out as an "X", a "V", a bracket, a stray letter or nothing, and an empty box may come out as "O" or "D".

Dedicated mark-reading systems exist for surveys and exam sheets, and they work because the sheet was designed for them and filled in under instructions. A form completed at a kitchen table is a different object. People answer checkbox questions in many ways:

Three habits keep checkbox data honest.

1. Use three values and not two. Record each box as checked, empty or unclear. Forcing an ambiguous mark into yes or no is how a wrong answer enters a spreadsheet with nothing to show it was ever in doubt.
2. Record pairs together. For a "Yes / No" question, write down the state of both boxes. Two ticks, or none, tells you something that a single "Yes" hides.
3. Look at the page for every box you rely on. That means the image, at a zoom where you can see whether a mark is a tick or a speck of toner.

The post on police reports has a section on form fields, checkboxes and narrative blocks as they appear on incident and collision reports.

Keeping each answer beside its field label

Keeping each answer beside its field label takes a deliberate step after conversion. Make a list of the form's fields once, from a blank or clean copy. Then, for each completed form, enter the value for every field in that fixed order, with the page image open beside you.

Know where this form puts its labels

Forms use four layouts, often on the same page.

The second layout does the most damage. Take a fictional rental application completed by a Marisol Vega. The row on the paper reads, left to right, "Monthly income", "Employer", "Start date", "Supervisor phone", with her answers in the boxes beneath. The converted text may read:

Monthly income Employer Start date Supervisor phone
4,150 Tri-County Dental 06/2021

Four labels, three values. She left one box empty, and nothing in the text says which. Is "06/2021" the start date, with no phone number given? Or did recognition miss a faint entry? Only the image answers that.

On this rental application the empty box matters as much as a filled one. You are building a lease file, so you check the tenant name, the landlord, the security deposit figure, and any quiet enjoyment wording printed in the rules section. A blank deposit line should say blank, confirmed on the image, before the row goes into the table.

Build the field list first

Number the fields on a blank copy of the form in the order you want to capture them. For each, note the label and the kind of answer expected: text, date, amount, identifier, checkbox or signature. A two-page form might have 60 fields. Making the list takes fifteen minutes and you make it once per form design.

Then follow four rules when you fill it in:

1. Every field gets an entry. Write "blank" for an empty field. A missing row is how answers slide up into the wrong field.
2. Copy the label from the form, not from memory. "Date of loss" and "Date of report" sit side by side on many claim forms.
3. Keep multi-line answers whole. An address spread over three ruled lines is one value.
4. Note the page. In a stack, each row needs the page number of the scan it came from, so anyone can go back to the image.

Some software reads forms by position: someone marks where each field sits on the page, and the tool reads those areas and nothing else. The post on what zonal OCR is explains that approach and where it breaks. The field list is worth making either way, because it is also your proofreading sheet.

Handwritten and typed entries on a pre-printed form

A completed form holds up to three kinds of content: the pre-printed text, typed answers and handwritten answers. Expect the pre-printed text to convert best, typed answers nearly as well when they sit clear of the rules, and handwritten answers to be the least reliable part of the page.

Typed entries

Answers added by a printer or a typewriter are ordinary print. The problems are positional.

• Entries that ride the line. Typed text that sits on the rule of its box loses the tails of "g", "p" and "y", or picks up the rule as an underline.
• Overflow. A long employer name runs out of its box and into the next one, and the two values join.
• One character per box. Fields drawn as a row of small cells, common for identification numbers and dates, split a value with vertical rules. The rules may be read as "l", "1" or "|" between the real characters, so nine digits come back as seventeen characters.
• Pre-printed hints. Gray "MM/DD/YYYY" guides under a date field merge with the date typed over them.

Handwritten entries

Handwriting on a form combines two hard problems: the writing itself, and writing squeezed into a small box by someone in a hurry. Printed capitals in separate cells fare best. Cursive across a ruled line fares worst. General recognition tools vary widely here, and the Schema Law homepage says its recognition is weaker on handwriting than on clean print, so test a few of your own forms before planning around the result. The method for turning handwritten pages into typed text is in the post on how to convert handwriting to text.

For a form, the practical rule is simple: type handwritten answers into your field list from the image. Use the converted text as a hint for long narrative boxes and ignore it for short ones, where typing five characters is faster than checking five.

Marks that are neither

Signatures, initials beside a correction, a "RECEIVED" stamp and a clerk's handwritten file number are all content, and none of them is an answer to a field. Give them their own rows: "Signature present: yes", "Correction initialed at field 14", "Stamp date". Whether a signature is present can matter as much as any typed answer, and converted text will show it as a scribble of letters or as nothing.

Numbers written or typed into boxes are the entries most likely to be wrong and least likely to look wrong. The post on why OCR gets numbers wrong covers the digit swaps and the checks that catch them.

Which export fits a stack of identical forms?

For a stack of identical forms the destination is a table with one row per form and one column per field. A spreadsheet format gets you closest. Keep a searchable PDF of the stack as well, so every row can be traced to its page image.

No export from a general OCR tool hands you that table ready-made, because the tool does not know which words on the page are labels. What the export can do is make the rebuilding quicker. Choose by what happens next.

Every Schema Law plan, the free one included, exports all of these formats. The plans differ in how many pages they take, as the pricing page shows, and you can export the same upload again in another format, so the choice is not final. The full list is under export formats.

Preparing the stack

A stack converts into a usable table only if it is regular. Before you scan or upload:

1. Sort by form version. Look at the revision date or form number in the footer. A 2019 edition and a 2023 edition of the same form put fields in different places, and each needs its own field list.
2. Fix the page count. If each form is two pages, confirm every form in the stack has both, in order. One missing reverse side shifts every later form by a page.
3. Remove or flag attachments. A stapled pay stub or a continuation sheet belongs to its form and is not page three of the pattern.
4. Keep the order. Number the paper forms in pencil, or note the first and last name in the stack, so row 27 of the table can be matched to the 27th form.

Building the master table

Put the field labels across the top of a spreadsheet in field-list order. Add three columns at the left: form number, starting page in the scan, and form version. Each form becomes one row. Add one more column at the right for notes, where "field 22 unclear" and "second signature missing" go. The notes column is what lets a later reader trust the other sixty.

Proofreading a converted form field by field

Proofread a converted form by walking the fields in order with the image open, comparing each value on the paper with the value in your table. Reading the converted text top to bottom will not find a correct answer sitting under the wrong label. Only a field-by-field pass does.

The proof sheet

Use the field list as the sheet. A few rows from the fictional rental application show the pattern:

The order of work

1. Count first. Confirm the number of pages and the number of forms. Then confirm your table has an entry for every field, including the blanks.
2. Identifiers. Check each case, account, policy and identification number one character at a time. Count the characters as well as reading them.
3. Dates and amounts. Compare every one with the image. Where the form repeats a fact, such as a date of birth on page one and again beside the signature, compare the two.
4. Checkboxes. Go to the image for each. Record checked, empty or unclear.
5. Signatures and initials. Present or absent, dated or undated.
6. Free-text boxes. Read the narrative answers against the image last, when the short fields are settled.

Blank is not the same as unread

When a field has no value in the output, there are two possibilities: the person left it empty, or the software skipped a faint entry. Your table should say which. "Confirmed blank" means someone looked at the box.

How much of a stack to check

The identifiers, dates, amounts and checkboxes you will rely on get checked on every form. For the remaining fields, check a set pattern, such as every fifth form, and widen it if you find errors. Write on the master table who checked what and when. The general routine for proofreading OCR output against the original applies to any narrative pages attached to the forms.