Schema LawSign in with Google

OCR Handwritten Notes: What Machines Can Read

By Schema LawPublished Updated

OCR can read handwritten notes when the writing is neat, separated and in dark ink, and it struggles with fast cursive, abbreviations and faint pencil. Treat the output as a draft that makes notes searchable. It is not a transcript you can quote until a person has compared it with the page.

That answer covers a wide range of results. A block-printed intake form can come back nearly clean. A doctor's progress note written at speed can come back as a few real words in a field of guesses. The sections below explain why, which legal documents fall on which side, and how to run a fair test on your own pages.

A medical form in a chart is the page this usually means. You check the patient name, the date, and the dose. A short opinion in the margin, or a note that a witness is unavailable, often fails to appear in the draft. Read that margin on the page before you treat the text as complete.

Can software read handwriting at all?

Yes, some software reads handwriting, but the kind of engine matters. Older OCR engines were built for printed type and do poorly on script. Newer recognition models are trained on handwriting as well as print and can return usable text from tidy writing. Neither kind reads every hand.

The difference shows up in the tools' own documentation. The FAQ for Tesseract, an open-source engine built around printed text, answers the handwriting question this way: you can try, "but it won't work very well, as Tesseract is designed for printed text". Google's Cloud Vision documentation, by contrast, lists detecting handwriting in an image as a specific use of its document text feature. So "handwriting OCR" exists as a product category, and a tool that was never designed for it will fail in ways that say nothing about what is possible.

That split is the first thing to settle when someone asks whether AI can read handwriting on legal documents. Find out what the tool in front of you was built for. The post on how AI OCR differs from classic OCR explains the two approaches. No vendor's description tells you how its software will do on your client's handwriting, though. Only a test on real pages does.

Two words get mixed up here. Recognition of typed characters is usually called OCR. Recognition of handwriting is sometimes called ICR or HTR in vendor material. In practice one product often does both, and the label on the box matters less than the result on your page.

Why is handwriting harder than print?

Handwriting is harder than print because nothing about it is fixed. A printed "a" has the same shape every time it appears. A handwritten "a" changes with the writer, the pen, the speed and the letters on either side, and in cursive it is joined to its neighbors with no gap to mark where one letter ends.

Several separate problems stack up on a handwritten page:

  • No clean boundaries. Print leaves white space between characters. Cursive joins them, so the software has to decide where to cut, and a wrong cut turns "rn" into "m" or "cl" into "d".
  • One shape, several meanings. A quick vertical stroke may be a 1, a lowercase l, a capital I or a 7 without its bar. A person uses the sentence to decide. Software has to guess from the same context, and a name or a number gives it very little.
  • Lines that drift. Handwriting on unruled paper slopes and wanders. Lines can touch, with a descender from one hanging into the ascenders of the next.
  • Personal shorthand. "Pt c/o HA x 3 d" is a complete thought to the nurse who wrote it. Abbreviations, arrows, circles and crossed-out words are not in any vocabulary the software can lean on.
  • Weak marks. Pencil, light ballpoint and carbon copies leave thin gray strokes that a black-and-white scan can erase altogether. The post on scanning handwriting describes how pencil, blue ink and felt tip behave under the scanner.

Print gives recognition software thousands of identical examples of each letter. One writer's hand gives it a few dozen, all slightly different. That is why the same tool can read a typed contract almost without fault and then stumble on the note stapled to it.

Context makes it worse in legal files. The words that matter most are the ones software cannot predict: surnames, street names, drug names, dosages, dollar figures, dates. A recognition model that guesses "the" correctly from a smudge has no such help with "Szczepanski" or "0.5 mg".

Handwritten legal documents convert well when the writer was slow and the space was constrained: block capitals in form boxes, printed-style notes in dark ink, dates and amounts written one character per square. They convert badly when the writer was hurried, writing for themselves, or writing long passages in cursive.

DocumentWhat to expectWhy
Intake or court forms filled in block capitalsOften usable after a check of names and numbersSeparate letters, one field per box, a typed label beside each answer
Typed forms with a few handwritten entriesTyped text reads well; entries varyThe print anchors the layout, and the entries are short
A client's neat printed notes or timelineOften a workable draftConsistent letter shapes, dark ink, full words
Attorney notes from a hearing or callPatchySpeed, abbreviations, arrows, text at angles
Medical progress notes and prescriptionsFrequently poorFast cursive, clinical shorthand, small writing
Police field notes and witness statementsDepends entirely on the writerRanges from careful print to scrawl on a clipboard
Old ledgers and letters in formal scriptReadable to a trained model, hard for most toolsRegular but unfamiliar letterforms and faded ink
SignaturesDo not expect a nameA signature is a mark and rarely spells anything legible

The table is a starting expectation and nothing more. Two nurses on the same ward can produce one legible chart and one that defeats every tool. Sort a large set by writer if you can, test a page from each, and decide writer by writer what gets converted and what gets typed.

Some document types have their own posts because the stakes differ. A holographic will raises questions about the status of any transcription, which the post on OCR for a handwritten will and probate records addresses. Chart notes sit inside a larger records workflow, covered in the method for OCR on medical records for attorneys.

One common mistake is to judge a set by its first page. Fax cover sheets, typed face sheets and printed forms sit at the front of most files. The handwriting is usually deeper in. Pull your test pages from the middle.

Margin notes on a typed page

Margin notes are the hardest handwriting to place even when they are easy to read. The software must work out that the note is separate from the typed text, read it, and then decide where it belongs in the output. Any of those three steps can go wrong.

When you run OCR on handwritten margin notes, expect one of four outcomes:

  1. The note is dropped. Faint or small annotations may be treated as marks on the page and left out. Nothing in the output tells you something is missing.
  2. The note is read and placed at the end or the start. You get the words, but no link to the paragraph they sat beside.
  3. The note is spliced into the typed text. A comment written beside clause 7 lands in the middle of a sentence in clause 7. This is the dangerous case, because the output now contains a sentence the typed document never said.
  4. The note is read and kept apart. This is what you want, and you should confirm it rather than assume it.

Annotations that are not words cause their own trouble. Underlining and strike-through run across the typed letters and can damage recognition of the text underneath. A bracket in the margin may come back as a stray "[" or "1". Initials beside a clause, which matter a great deal in a contract, are short enough that software often reads them as noise or as random letters.

For a marked-up contract or a draft with a partner's comments, work from two things side by side: the converted typed text for searching and editing, and the page image for the annotations. Record each annotation yourself in a short list with the page, the clause it touches and what it says. That list is quick to make, and it is the only version of the marginalia you can stand behind. For a consistent way to write each entry, the post on transcripts shows how to record strike-outs, insertions and handwritten annotations.

Check the direction of the error too. If the output of a typed page contains a phrase you cannot find in the typed text, look in the margin before you assume the software invented it.

Getting the best result from a handwritten page

The best result from a handwritten page comes from a narrow goal, a faithful image and a strict reading of the draft. Decide first which pages you need word for word and which only need to be findable. Then scan the original sheet, and check the output for the kinds of error handwriting causes.

Set the goal page by page. A forty-page notebook rarely needs forty pages of exact text. Mark the handful of pages someone will quote or build a chronology from, and treat the rest as pages that only have to turn up in a search. The first group gets a line-by-line check against the image. The second group gets a glance and a label saying the text is unverified.

Give the software a faithful image. Scan the original in grayscale or color, never in pure black and white, and keep the whole sheet in the frame. The guide to scanning handwriting sets out which scan mode suits each kind of handwritten page and gives a checklist for inspecting a handwriting scan before recognition.

Test before you commit a set. Convert a few pages from different writers and see whether correcting the draft is faster than typing from the image. The post on choosing a converter explains how to build a test set from your own handwritten pages, and the conversion guide gives the count that tells you when to correct a handwriting draft and when to retype it.

In Schema Law, you sign in, upload a PDF, PNG or JPEG of up to 20 MB, and read the parsed pages next to your original. The free plan takes one document a day of up to three pages, which is enough for a first look at one writer's hand. The site makes no promise about any particular hand, and you should not assume one. The pricing page shows the limits if the test goes well and you have a larger set.

Read the draft for handwriting's own failures. A draft made from handwriting goes wrong in ways a draft made from print seldom does, and none of them announces itself. Check four things on every page that matters:

  • The line count. Count the handwritten lines and the lines of text. A faint line, or one squeezed in between two others, can be left out with no gap to show where it was.
  • Words that are real but do not fit. Read for sense. A sentence that is grammatical and slightly odd usually hides a misread word.
  • Crossed-out and inserted words. See whether a struck word came through as if the writer meant it, and whether a word added above the line landed in the right place.
  • Abbreviations. Compare each one with the page. "Pt", "w/o" and "cont'd" are exactly the strings software is tempted to turn into ordinary words.

An invented example shows how quiet these errors are. An attorney's note from a hearing in a fictional lease dispute reads: "Cont'd to 6/17, dept 4. Tenant's atty Brackley to file reply by 6/3." Suppose the draft comes back as: "Could to 6/11, dept 4. Tenants ally Brackley to file reply by 6/8." Almost every word is a real word, and the line looks like a sentence. Both dates are wrong, and a search for "atty" or "cont'd" will no longer find the note. Only a reader with the page beside the draft would catch any of it.

Whatever the tool, proofread handwriting more strictly than print. The method for proofreading OCR output against the original applies, with one addition: read numbers and names character by character, because handwriting errors tend to produce plausible words instead of obvious garbage.

When a person still has to transcribe it

A person still has to transcribe handwriting when the exact words will be quoted, filed or relied on, when the test pages needed more correcting than typing, or when the writing is shorthand only its author can expand. Software output remains useful in those cases as a finding aid.

Use a simple rule to sort the work:

  • Searching a file for a name or date. Machine output is enough, with the understanding that a miss does not prove the word is absent.
  • Building a chronology or summary. Machine output as a first draft, each entry checked against the page before it goes in.
  • Quoting in a brief, declaration or letter. Human transcription, or machine output verified word by word by someone who signs off on it.
  • Anything where the handwriting itself is in dispute. The original or its image is the evidence. A transcription is an aid to reading it, whoever or whatever produced it. How a court treats a transcription varies by jurisdiction, so check the rules that apply to your matter.

When a person does transcribe, the transcript has to show its doubts: a word nobody can read is marked as unreadable and never filled with a guess. The post on transcribing handwriting sets out how a transcript should mark words nobody can read and who should check a handwriting transcript, and how.

Keep the scan either way. The value of running OCR on handwritten notes is that a box of pages becomes something you can search and sort in minutes. The value of the image is that every reading can be checked. A file needs both, and the export formats Schema Law offers include a searchable PDF that keeps the original page image with the text behind it.

All posts in Difficult scans