On-premises ICR that turns handwritten forms into structured, searchable data

The JSON is nested: pages contain paragraphs, which contain lines, which contain words. Each page carries its number, DPI, and coordinate origin (top-left by default, or PDF-style bottom-left). Each word carries its bounding box x and y, length, font size, text, and orientation. Each line optionally carries a bounding box.

That structure is what makes handwriting recognition reviewable rather than a black box. Every recognized value can be traced to a location on the page, so a misread name or figure can be surfaced, highlighted, and corrected before it reaches a system of record.

Because the output is a PDF, the rest of the Server SDK picks it up from there. Converting a searchable PDF to PDF/A is part of the base package. Converting it to DOCX, XLSX, PPTX, or HTML uses the Structured Output Module, a separate add-on on the same SDK.

Applying raw recognition output straight to the document is one call. With handwriting it rarely should be. Handwritten glyphs vary widely between writers, values escape the boxes a form designer intended, and pen colour and pressure change from page to page. That makes the correction step matter more than it does for print.

The API is built for that. Extract the results as JSON, run whatever validation your domain calls for: a spell checker, a lookup against expected patient or customer names, an allowlist or blocklist comparison and write the corrected values back.

The same entry point accepts JSON generated by a different OCR or ICR engine, so an existing recognition pipeline can be kept while Apryse handles validation, placement, and searchable-PDF generation.

Teams adding ICR to an application usually weigh four options: manual data entry, a cloud ICR API, a general-purpose AI model, or a standard OCR. Apryse ICR is the embedded SDK approach.

Handwritten fields are still routinely keyed in by hand or sent to an outsourced team, which sets a floor on cost, turnaround, and error rate that no amount of workflow tooling can move. ICR converts transcription into an automated step with a validation pass, so people review exceptions instead of typing every form.

A cloud service sends every page: intake forms, claims, clinical notes, to infrastructure you do not control. Apryse ICR runs inside your own application on your own servers. Handwritten content is disproportionately personal and regulated, so for most teams evaluating this, that is the deciding factor rather than a preference.

A general-purpose model can transcribe handwriting, but it infers text and layout across the whole page in one pass, which makes output variable between runs and hard to audit on a document you may later have to defend. ICR is purpose-built for character recognition and returns positional data alongside the text, so every recognized value traces back to a location on the page.

OCR is built for printed, machine-generated characters and degrades on handwriting, because its underlying assumption of consistent glyph shapes does not hold. ICR is trained for that variability instead of against it. The two are complementary: OCR for the printed body of a form, ICR for the handwritten fields.

Running ICR first is also the cheaper way to use a model. Handing an LLM a page image spends tokens on pixels; handing it the recognized text spends them on words, and a page of text costs a fraction of what the same page costs as an image. Recognition is a fixed local cost paid once on your own hardware, while image tokens are billed on every page of every run.