OCR Training Data Generation

The problem

Labeled document data is the bottleneck in every OCR project. Real forms carry names, Social Security numbers, account numbers, and medical detail, which means they cannot be handed to an annotation vendor without a legal review that often kills the project outright. The documents that survive that review are the boring ones, so the corpus skews toward clean, common cases and starves the model of the rare layouts it will actually fail on. Hand annotation then adds weeks of latency and a steady error rate: a mislabeled box teaches the model the wrong thing just as effectively as a correct one teaches it the right thing.

The SymageDocs approach

SymageDocs inverts the pipeline. Instead of collecting documents and labeling them, it generates the underlying facts first and derives the document from them, so the label is known before the pixel exists. Every job emits per-instance annotated JSON, a tabular CSV of the identity data, and FUNSD-format ground truth — all three ship in every bundle regardless of what you requested, because they are the foundation the rest of the output is built on. You choose the render surface: typed PDF, typed PNG, handwritten PDF, or handwritten PNG. Scaling from ten documents to ten thousand is a change to one integer in the request.

What you actually get

• Rendered pages as typed or handwritten PDF and PNG, produced from the real form layout rather than a generic template.
• FUNSD-format ground truth in every bundle, giving word-level text with bounding boxes in a canonical coordinate space tied to the render DPI.
• Per-instance annotated JSON describing every field on every document, including the field identifier from the form definition.
• A tabular CSV of the underlying identity data, so you can join a document back to the simulated person who produced it.
• Everything delivered as a single zip; very large jobs switch to a sharded layout with a size-budgeted preview archive, a manifest, and per-shard archives.

How it works

1. 1

   Simulate the people

   The generator builds fictional identities with internally consistent lives: an occupation drawn from BLS Standard Occupational Classification codes, a real ZIP code tied to an actual city, a household with a spouse and dependents where the filing status calls for them, and income derived from that occupation's BLS wage distribution and the state and metro area they live in rather than sampled at random.

2. 2

   Fill a real form layout

   Each identity is mapped onto a shipped form definition. The layouts are the real ones, not approximations — the CMS-1500 definition carries 212 fields, the 2024 Form 1040 carries 141 across two pages, and the 2025 single-page W-2 carries 45. Values land in the boxes a real preparer would use.

3. 3

   Render and label in one pass

   The rasterizer records where every token was drawn as it draws it. The FUNSD export and the render share a canonical coordinate space derived from the page size and DPI, which is what keeps the boxes aligned with the pixels instead of approximately aligned.

4. 4

   Download and train

   The finished job is a single zip of pages plus ground truth, delivered through a short-lived presigned download link. Bundles are not retained indefinitely, so keep the archive you trained on rather than planning to re-fetch it later.

By the numbers

Field and page counts are read from the shipped form definitions in the SymageDocs form library. Library-size figures count every definition the API can generate; the public form reference pages under /forms document a curated subset of them, so that page shows a smaller number. Output-format availability reflects the current API contract; the ML export formats (BIO, YOLO, COCO, Donut) sit behind a feature flag that is not enabled in production, so treat them as a preview rather than a generally available option.

Who this is for

Teams training or fine-tuning text detection and recognition models — Tesseract and PaddleOCR pipelines, transformer-based extractors, and in-house detector/recognizer stacks — who need volume and layout variety without a data-access review. It is also a fit for benchmarking: because you control the generating distribution, you can build a held-out set that deliberately over-represents the conditions your production model gets wrong, which is difficult to do with a corpus you merely collected.

Where SymageDocs is not the right tool

SymageDocs generates documents, not photographs of documents. If your production input is a phone camera capture with perspective distortion, glare, and motion blur, synthetic pages are the wrong shape for the last mile of that problem and you should pair them with a real or augmented photographic set. It is also not a general-purpose OCR corpus: the library covers structured business and government forms, so it will not teach a model to read handwriting on lined notebook paper, historical manuscripts, or natural-scene text. And if you already have a large, legally cleared, well-labeled corpus of exactly your production documents, you do not have the problem this solves.

Relevant forms

Frequently asked questions

What ground-truth format does the OCR training data come in?

Every bundle contains FUNSD-format ground truth, per-instance annotated JSON, and a tabular CSV of the identity data. Those three are foundational: they are emitted on every job and cannot be requested or disabled, because the rest of the output is derived from them. Additional ML export formats — BIO for token classification, YOLO and COCO for detection, and Donut for end-to-end parsing — exist behind a feature flag that is not enabled in production today, so they are a preview capability rather than something an account can have switched on. Plan on FUNSD, and talk to us if your pipeline needs one of the others.

Are the bounding boxes exact, or approximate?

They are exact by construction. The labels are not produced by running an OCR engine over a rendered page and trusting the result, and they are not traced by hand. The renderer records each token's position as it draws it, and the FUNSD export shares a canonical coordinate space with the raster, derived from the page dimensions and the render DPI. That removes the annotation-error floor you inherit from any human- or model-labeled corpus.

Can I train on handwritten documents as well as typed ones?

Yes. Handwritten rendering is a first-class output surface, available as handwritten PDF or handwritten PNG, and it uses a dedicated renderer over a stroke library rather than a handwriting-style font. Ground truth is emitted for handwritten output the same way it is for typed output, so a mixed typed-and-handwritten corpus is a single job with multiple output formats rather than two separate pipelines.

Is the synthetic data distinguishable from real documents?

Not by a trivial marker. It is an explicit engineering rule that generated output carries no systematic tell — no fixed SSN prefix, no watermark, no stamp — because any such marker would let a model learn the shortcut instead of the task. Generated identifiers such as SSNs and EINs follow real structural rules and are randomized within them. The documents are of course not real, and no real person is represented; the point is that the difference is not a feature the model can key on.

How many documents can I generate?

Quantity is a parameter on the job, and the public generation API accepts up to 10,000,000 per request — a sanity ceiling against a mistyped figure rather than a capacity limit, since large jobs are chunked across workers and assembled at the end. Past roughly two gigabytes uncompressed the download switches from a single zip to a sharded layout: a preview archive, a manifest, and per-shard archives, so you can start inspecting the data before the whole corpus has transferred. The preview is bounded by a size budget rather than a fixed document count, so how many documents it contains depends on how large each one is. Your credit balance and rate limit, not the schema, are what you will actually run into first.

Do the same seed and settings reproduce the same corpus later?

The generated data does, within a generator version — seeds are recorded in the instance JSON and are genuinely useful for tracing and bisecting a data issue. Two caveats, and we would rather state them than have you discover them. Across generator versions the guarantee lapses: as form definitions and distributions change, the same seed produces different output. And handwritten rendering is not seeded — the writer is drawn independently on every render call, so handwritten pixels differ between runs even when the underlying field values are identical. When you need the exact bytes you trained on, keep the downloaded bundle as an artifact rather than relying on regeneration.

Related use cases