Last reviewed September 1, 2026

How do I pull data from handwritten or faxed forms?

Direct answer

Lower your expectations for free-form handwriting and raise your standards for the intake. A fax and a hand-filled form are two separate problems: Group 3 fax is a low-resolution, two-tone image by definition, and handwriting is variable letterforms that even people misread. Constrained handwriting — boxed digits, checkboxes, printed capitals on a form designed for it — reads far better than cursive, so the largest wins come from changing the form and the transport, then routing every hand-filled field through a review gate instead of straight into a database.

What a fax actually is

Group 3 fax encodes a page as a bilevel image — every pixel is black or white, with no grey in between — at a horizontal resolution around 200 dpi and a vertical resolution that depends on the mode. That is a deliberate 1980s bandwidth trade, and it is why faxed documents look thin and broken up close.

The practical consequence: a faxed page has already thrown away the information that would let a reader distinguish a hesitant 1 from a 7 with a short bar. No software recovers it. If you can influence how documents reach you — email the PDF, upload through a portal, scan once at 300 dpi and send that — you gain more than any tooling change will give you.

Constrained handwriting beats free handwriting, by a lot

Handwriting recognition research has always split the problem into handprinted characters — separated block capitals and digits, typically written into boxes — and unconstrained cursive. The first is a mature, well-studied task with public reference datasets. The second is difficult for humans as well.

You often control which one you receive. A form with comb boxes for a date, checkboxes instead of a write-in choice, and a separate signature area away from the data fields will be read far more reliably than the same information collected as free text on a blank line — and it costs one form redesign, once.

Replace write-in choices with checkboxes or a small set of tick options.
Use comb boxes (one character per cell) for dates, account numbers and postcodes.
Ask for block capitals explicitly, and leave enough room for them.
Keep signatures, initials and stamps physically away from data fields.
Print the form at a decent size — cramped fields cause overlapping strokes that no reader untangles.

Read the marks, not the prose

For hand-filled forms, a schema of narrow, typed questions outperforms a schema of open text fields. A boolean for "is the box ticked", an enum with the four options printed on the form, a date field with an explicit format instruction — each one converts a reading task into a choice among known answers, which is both easier and verifiable.

Dokyumi supports exactly those field types — string, number, currency, date, boolean, enum, array and object — and the documentation is direct about the limits: PDF, JPEG, PNG, TIFF and WEBP up to 20MB, 150 DPI or better recommended, scanned documents supported, and handwritten text limited in accuracy. Design around that last sentence rather than hoping it does not apply to your forms.

A review policy for hand-filled fields

Decide per field what happens when it is hand-written, and write it down before you go live. The rule that works: anything that identifies a person or moves money is verified by a human, every time, regardless of what any confidence score says. Anything descriptive can be auto-accepted and corrected later if it matters.

That policy is also your answer when someone asks why the system is not fully automatic. It is not a technical limitation you failed to solve; it is a control you chose, on the fields where being wrong is expensive.

Decision table

Field-risk policy for hand-filled forms

Classify every field on your form into one of these rows before writing a schema. The action column is the policy; the verification column is how a reviewer confirms it in seconds rather than minutes.

Field class	Examples	Auto-accept?	How a human verifies it fast
Identity numbers	SSN, policy number, member ID, account number	Never	Show the cropped image beside the value; check against an existing record
Money amounts	Claim amount, deposit, hourly rate	Never	Compare against the sum of any itemised lines, and against expected range
Dates with legal effect	Date of loss, signature date, service date	Never	Check against the postmark, the fax header, or a linked event
Checkbox and tick answers	Coverage elected, consent given, box ticked	Only when unambiguous	A single glance at the cropped box; ambiguous marks go to review
Constrained choices	State code, plan type, relationship	Yes, when it maps to an enum value	Reject anything outside the enum automatically
Names and addresses	Claimant name, mailing address	Yes, with fuzzy match to a known record	Match against your existing customer record; flag mismatches
Free-text notes	Description of incident, comments	Yes	Nobody verifies these; they are read when a case is worked

Nothing in this table depends on which vendor reads the page. It is a policy about consequences, and it stays valid when the technology improves.

Copy-pasteable artifact

A schema built for a hand-filled form

Written for marks rather than prose: booleans for boxes, enums for printed choices, an explicit format instruction on the date, and every risky field nullable so a blank stays a blank instead of becoming a guess.

intake-form-fields.json

[
  {
    "key": "form_completed_by_hand",
    "type": "boolean",
    "required": true,
    "description": "True if the entries appear hand-written rather than typed. Used to route the whole submission to review."
  },
  {
    "key": "claimant_name",
    "type": "string",
    "required": true,
    "description": "Name as written in the name field, in block capitals if that is how it appears. Do not expand initials or correct spelling."
  },
  {
    "key": "date_of_loss",
    "type": "date",
    "required": true,
    "description": "The hand-written date in the Date of Loss box, as YYYY-MM-DD. The form prints MM/DD/YYYY; convert it. Return null if any digit is unreadable rather than guessing."
  },
  {
    "key": "coverage_elected",
    "type": "enum",
    "required": true,
    "options": ["basic", "standard", "premium", "declined", "unclear"],
    "description": "Which coverage box is ticked. Use unclear when two boxes are marked, a mark is crossed out, or no box is marked."
  },
  {
    "key": "amount_claimed",
    "type": "currency",
    "required": false,
    "description": "The hand-written amount, as a number with no currency symbol. Return null if the decimal position is ambiguous."
  },
  {
    "key": "signature_present",
    "type": "boolean",
    "required": true,
    "description": "True if there are ink marks in the signature area. Do not attempt to read the signature itself."
  },
  {
    "key": "illegible_fields",
    "type": "array",
    "required": false,
    "description": "Names of any fields on the form that could not be read confidently.",
    "items": { "type": "object", "fields": [
      { "key": "field", "type": "string", "required": true },
      { "key": "reason", "type": "string", "required": false }
    ] }
  }
]

Two moves matter most here. "Return null rather than guessing" turns an unreadable field into a visible gap instead of a plausible wrong number. And "unclear" as an enum option gives ambiguity somewhere legitimate to land — without it, ambiguous marks get forced into one of the real answers.

Terminology bridge

Reading hand-filled forms is ICR; the review step is human-in-the-loop verification

OCR conventionally refers to machine print; intelligent character recognition (ICR) is the term for hand-written input, and handprint is the industry word for separated block capitals and digits. Analysts fold all of it into intelligent document processing. The review pattern — a person confirming specific fields with the image beside them — is human-in-the-loop verification, and on hand-filled documents it is a design requirement rather than a fallback.

ICR
handprint recognition
mark detection
human-in-the-loop verification
forms processing

Follow-up questions

How accurate is handwriting extraction?+

It depends almost entirely on how constrained the writing is, and Dokyumi publishes no handwriting accuracy figure — the documentation states that handwritten text has limited accuracy. Test with fifty of your own real forms, count the fields a reviewer had to correct, and use that as your number.

Should I use vision mode for hand-filled forms?+

Often, yes. A schema’s OCR mode can be standard (OCR, then field mapping) or vision (the page image goes to a vision model directly), and layout and mark position carry a lot of meaning on forms. It is a per-schema setting, not a per-request flag, so keep hand-filled forms on their own schema.

Can I stop accepting faxes?+

Sometimes the sender genuinely cannot change — courts, some carriers, some clinics. Where you can offer an alternative, a portal upload or an emailed PDF removes an entire layer of degradation, and it is usually an easier conversation than people expect.

Evidence notes

Sources and limitations

Sources used

ITU-T T.4 — Group 3 facsimile terminals — the fax standard: bilevel encoding and the resolutions that limit what a faxed page can contain.
NIST Special Database 19 — handprinted forms and characters — the reference dataset for handprinted character recognition; evidence that constrained handprint is a distinct, studied task.
IRS Form W-9 — a widely used form designed for hand completion — boxes, checkboxes, and a separate signature area.
Claude vision documentation — image guidance for the vision path Dokyumi uses in vision mode.
Mistral OCR documentation — the OCR service behind standard mode, and what it does with scanned input.

Limitations

Dokyumi documents handwritten text as limited in accuracy and publishes no handwriting benchmark. Nothing here should be read as a claim that cursive extracts reliably.
Signature detection in the schema above reports that ink is present in an area. It is not signature verification, identity proof, or authentication of any kind.
Faxed input has lost detail before it reaches any software. Improving the transport beats improving the reader.

Published and last reviewed September 1, 2026. Product behavior can change; the linked API, pricing, and security pages are the controlling public references.

Keep reading

Deeper guide

Parsing government forms

Fixed official forms, including the hand-filled ones, in more depth.

Proof artifact

W-2 parser field guide

A fixed official form, extracted field by field, with the real response shape.

Product surface

File requirements and OCR modes

Formats, resolution guidance, and the standard versus vision distinction.

Test your worst hand-filled form

Build the schema above, send fifty real forms, and count the corrections. The free plan includes 25 credits a month and 2 schemas, with no card required, which is enough to test this on your own documents before deciding anything.

Read the quickstart