PDF to JSON with Bounding Boxes for RAG and Review
What a useful PDF-to-JSON API should return for RAG: elements, Markdown, reading order, tables, page numbers, and bounding boxes.
The minimum useful element shape
Each extracted element should include a stable id, type, content, page number, and coordinates where available. For RAG systems, this allows chunks to cite source pages and lets review interfaces highlight the original text region.
- ✓id
- ✓type
- ✓content
- ✓page
- ✓bbox or bounding_box
- ✓metadata
Tables need structure, not just copied text
Tables should be returned as rows and cells where possible. This helps retrieval systems answer data questions without flattening columns into confusing text streams.
Reading order prevents bad chunks
A top-level reading_order array or equivalent sequence makes ingestion predictable. It helps downstream jobs avoid mixing headers, footers, sidebars, and body content.
Use async jobs for production parsing
A production API should return a task_id quickly, process the PDF in the background, then expose completed JSON and Markdown from a status endpoint. This avoids holding long HTTP requests open for large documents.
What to verify before publishing
- 1Submit PDF and store task_id
- 2Poll until status is complete
- 3Persist elements with page and bbox metadata
- 4Store Markdown for model ingestion
- 5Store table rows separately where needed
- 6Use source metadata for citations
Questions about this guide
What are PDF bounding boxes?+
Bounding boxes are coordinates that identify where an extracted element appears on a PDF page.
Why does a JSON API also return Markdown?+
Markdown is easy for LLM ingestion, while JSON preserves typed elements, coordinates, tables, and metadata.
Is PDF-to-JSON parsing instant?+
Small files may finish quickly, but production systems should use async jobs because PDFs can be large or complex.