List PDF form fields

This capability reads that form structure and returns a clean inventory of every field, including its complete name, recognized field type, and current value. It handles the common AcroForm controls used for applications, questionnaires, approvals, and intake documents. Processing is deterministic and local to the parser: there are no network requests, model guesses, or random results. If the supplied document is not a PDF, is malformed, or contains no form fields, the request returns a clear input error instead of an empty result that could be mistaken for success.

Inspect the real structure behind a PDF form

Interactive PDF forms store controls separately from the words and lines painted on each page. A field may have an internal name such as customer.address.postcode even when the page only shows the label “Postal code.” This capability follows the document catalog to its AcroForm dictionary, walks the field tree, applies inherited properties, and returns terminal fields in document order. Each result contains the full field name, a normalized type, and the value currently stored in the PDF. Text boxes, checkboxes, radio groups, dropdowns, option lists, push buttons, and signature fields are distinguished using the field type and flags defined by the document. Hierarchical names are joined with dots so similarly named controls in different sections remain unambiguous. This makes the output useful as a machine-readable schema inventory, not merely a scrape of visible page text. When a checkbox has no active value it is reported as false, and an unsigned signature field is identified without pretending that a signature exists.

Provide the document and interpret the response

Send the PDF in the pdf parameter as plain base64 or as a base64 application/pdf data URL. The parser first validates the encoding and PDF header, then reads the indirect objects needed to locate the catalog and form field tree. The response includes fields, an array of records, and count, the number of returned fields. Field types use practical names such as TextField, CheckBox, RadioGroup, Dropdown, OptionList, PushButton, and Signature. Current values preserve strings and arrays where the PDF stores them, while checkbox state is returned as a boolean. Empty text-like controls use an empty string, making them easy to distinguish from absent fields. Do not treat the display label printed beside a control as its field name; only the internal form definition determines the returned name. The capability deliberately errors when no fields exist. That behavior helps automation detect a flattened PDF, a scanned paper form, or the wrong attachment instead of silently continuing with an empty field map. The maximum accepted encoded document size is bounded to keep parsing predictable.

Use the inventory safely in document workflows

A field inventory is a useful first step before filling, validating, migrating, or auditing PDF forms. For example, an onboarding system can compare the returned names against the keys produced by its application database before attempting to populate a template. A quality-control job can verify that a revised form still exposes the required fields and that control types have not changed unexpectedly. An archive migration can record which values were embedded in each interactive document before flattening it for long-term storage. Because the algorithm does not call external services or infer values from page appearance, repeated requests with identical bytes return identical JSON. That predictability is important for tests and audit trails. However, this is an AcroForm structure reader, not optical character recognition: a scan of a paper form has pixels but no interactive fields and therefore produces the no-fields error. It also does not modify, flatten, sign, decrypt, or repair documents. Encrypted files and PDFs whose relevant form objects cannot be read should be prepared with an appropriate PDF tool before submission.