Docyield's form parser reads a filled-in form — a PDF or an image — and returns every labelled field paired with the value written against it. Application forms, intake sheets, surveys, registration documents, government paperwork: whatever the layout, you upload the file once and get back a tidy list of label-and-value pairs you can review, export, or push into another system, instead of squinting at the page and copying each answer by hand.
Forms are unusually varied. Two documents asking for the same information can arrange it completely differently — fields in columns, values in boxes, answers ticked rather than typed. Because the parser captures whatever labels appear on the document rather than expecting a fixed set, it adapts to the form in front of it instead of breaking when a field moves or a new question is added. That flexibility is what lets a single tool handle the long tail of one-off and bespoke forms that no fixed template could ever cover.
What a form parser actually does
A form parser separates the structure of a form from the answers somebody entered on it. It finds each label — the printed prompt, such as "Date of birth" or "Policy number" — and pairs it with the value supplied next to it, then returns those pairs along with the form's title or type. The result is a clean record of what the form says, with the question and the answer kept together.
Crucially, this is field capture rather than text dumping. Plain optical character recognition would give you every word on the page in roughly reading order, leaving you to work out which scrap of text is a prompt and which is an answer. The parser does that pairing for you, so "Email" and the address beside it arrive as one label/value pair rather than two unrelated lines. On a dense form with dozens of fields, that pairing is the difference between data you can use immediately and a transcript you would still have to untangle line by line.
Why label-and-value capture beats raw OCR
On a form, position carries meaning: an answer is only useful if you know which question it belongs to. OCR alone discards that relationship — it flattens the page into a sequence of characters, and you are left reconstructing the pairs with fragile rules about what sits next to what. That breaks the moment a layout shifts the answer below the label instead of beside it.
Capturing label/value pairs preserves the meaning directly. Each answer travels with its prompt, so a downstream process can read "the value for Account number" without parsing the surrounding text. Returning the form title alongside the fields also tells you what kind of document you are looking at, which is handy when you are processing a mixed pile of paperwork. Together those two pieces — a name for the form and a clean set of answers — give you enough to file, route, or store the document without ever opening it manually.
Who uses a form parser
- Operations teams digitising paper intake, registration, or application forms into a database.
- HR onboarding new hires from completed starter and benefits forms.
- Insurance and claims staff capturing answers from claim and proposal forms.
- Healthcare front desks turning patient intake sheets into structured records.
- Anyone who receives filled-in PDFs by email and needs the answers as data rather than a scan.
Accuracy, blanks, and review
Results are strongest on clearly printed, well-aligned forms. A clean digital PDF or a flat, sharp scan parses very reliably. Handwriting, faint print, skewed photos, and dense layouts all make recognition harder, so a clearer source improves the captured values — particularly for handwritten answers, which are inherently more variable than typed ones.
Where a field is left blank on the form, its value comes back empty rather than invented — the parser will not guess an answer that the person never wrote. If a handwritten character is ambiguous, that uncertainty can carry through, so for the minority of forms where every field is critical it is worth a quick check against the original. No parser is right on every field every time, and keeping the source page beside the captured pairs makes the occasional fix quick.
Handling checkboxes, sections, and multi-page forms
Real forms are more than a column of text boxes. They have checkbox and radio selections, grouped sections with sub-questions, repeated blocks, and continuation pages. The parser reads the document in context, so a ticked option is captured as the chosen value and a question split across two lines is still paired with its answer rather than fragmented.
Because the field list is driven by what is actually on the page, you are not constrained to a predefined template. A form with an extra section, a reordered block, or a layout the parser has not seen before still comes back as a sensible set of label/value pairs, which is what makes the same tool usable across many different form types. That is a real advantage over template-based approaches, which demand that you map every form layout in advance and then re-map them whenever a department tweaks its paperwork — overhead that quietly grows with every new form variant.
Output formats and scaling to the API
Each parse can be exported as JSON, CSV, Excel (XLSX), or XML from the same result. JSON suits developers feeding answers into an application; CSV and Excel suit teams who want the label/value pairs as spreadsheet rows, one row per field; XML fits older systems that expect markup. Because the formats are just serializations of the same captured data, you can switch between them instantly without re-parsing the form.
When you need to process many forms — a batch of applications, a stack of intake sheets, a backlog of scanned paperwork — the Docyield API and batch dashboard run them at volume and return the same schema you see here, with webhook delivery for hands-off workflows. The field shape stays identical between the free tool and the API, so a prototype you build against a single form keeps working when you point it at thousands. That continuity is what makes it safe to start small and grow into automation without rewriting your integration.
What the form parser returns
Every form comes back as a title plus a list of the labelled fields found on it. Blank fields are returned with an empty value rather than a guessed one.
- Form title
- The title or type of the form, such as the heading printed at the top of the page.
- Fields
- The list of every labelled field detected on the form, each captured as a label paired with its value.
- Field label
- The printed prompt for a field — for example "Full name", "Date of birth", or "Policy number".
- Field value
- The answer entered against that label, returned empty when the field was left blank on the form.
How to extract fields from a form
- 1Upload your form — drop a PDF, PNG, JPG, or WEBP onto the box above, or click to choose a file.
- 2Wait a few seconds while Docyield reads the document and pairs each label with its value.
- 3Review the captured fields and check any answers you want to confirm against the original.
- 4Choose your output tab — JSON, CSV, Excel, or XML.
- 5Copy the result or download the file, ready to import into your system or store.
Frequently asked questions
Processing documents at scale?
Batch upload, an extraction API, and webhooks for 100+ documents a month.