PDF to JSON — what the emitted shape contains and what a pipeline can branch on
Machine-readable output is only useful if you know exactly which fields exist. This route reads a PDF in the studio tab and emits one JSON document describing the pages: totals and metadata up top, one entry per page below, and two counters a pipeline can act on. It does not emit byte counts, font lists, coordinates or embedded image inventories, so a consumer that expects those will fail — plan against the fields that are actually there.
Text comes from the PDF text layer, not from OCR: a page that is only a scanned photograph returns nothing.
Processed on your device. Files aren’t sent anywhere.
The shape you receive
The output is a single JSON object, not an array of files. It describes the document once and then repeats a small record for each page that was processed.
- Drop one PDF, up to 20 MiB; a document above 40 pages is rejected rather than truncated.
- Choose pages 1 through 40 with the slider, or Every page to describe the whole document.
- The route reads each page's stored text and measurements; it is not OCR, so pages drawn as artwork contribute no characters.
- You receive a source filename, a document block, a pages array, a character total for the processed pages, a list of processed pages without text, and a note.
- Download the JSON and feed it to your index, report or QA script.
What a pipeline can branch on
- pagesWithoutText identifies processed pages that yielded no extractable characters. That can mean a scan, a blank page or outlined lettering; it does not distinguish those cases.
- textCharacters per page is counted before any clipping, so a page that reports a large count is genuinely large even if its text field was cut.
- The top-level textCharacters totals only the processed pages. It covers the full document only when you choose Every page.
- width, height and rotation describe the page in points, which is enough to flag landscape pages or odd formats in a batch.
- title, producer and author come from the document's own metadata and may be absent; treat them as optional, not guaranteed.
Per-page caps, not a global cap
Each page's text field stops at 200,000 characters and carries an explicit marker inside that page's text. The character counts stay complete because they are taken before clipping, so a report can distinguish a clipped page from an empty one.
Questions about the JSON output
Does the JSON include coordinates or fonts?
Can the report distinguish a scan from a blank page?
Is the text field complete for long pages?
Field by field
| Field | Where it lives | Use it for |
|---|---|---|
| source | top level | Naming the input file the report describes |
| totalPages, title, producer, author | document block | Batch summaries and provenance |
| page, width, height, rotation | each page entry | Page inventory, orientation checks |
| textCharacters, text | each page entry | Per-page volume and the extracted characters |
| textCharacters | top level | Total for the processed pages without re-summing entries |
| pagesWithoutText | top level | Finding processed pages with no extracted characters |
| note | top level | Reading the route's own caveat alongside the data |
Fields that do not exist
There is no byte size, PDF version, pixel dimension list, font inventory, text-run detail, has-text-layer flag, embedded image list or truncated boolean in this output. Writing a consumer that reads those will produce undefined values, not data. Coordinates are likewise absent: the route reports page measurements and characters, not positions on the page.
Using the output in a report
A practical pattern is a two-pass review: read the document block and pagesWithoutText first to decide whether the batch is text-bearing at all, then walk the pages array for volume and orientation. Because text order is heuristic — it follows the document's own content stream and does not reconstruct columns — treat the text field as searchable material rather than as a faithful transcription of the layout.