Advantages
When NOT to use
How it works internally
- The backend downloads the PDF (1 time, no cache).
- Makes sample of 32 distributed pages (start, middle, end) to build the font model.
- Go through all the pages reading only the head (first 8 spans) to detect headings.
- Detects repeated headers/footers in the top/bottom 12% of each page.
- Returns JSON ~5-15KB with the entire map.
- Delete the temporary and finish.
Usage pattern for AI agents
Pattern 1 - search by section
Pattern 2 - search by density
Pattern 3 - user guided navigation
Actual comparison
PDF of 500 pages (academic paper, 10MB decompressed in Markdown):
AI Client pays 18x less. Your backend bills 8x less compute. Both win.
Honest limitations
- Heuristic detection. Sections are detected by font size + numbering + bold. It’s not real semantics. It works very well with structured documents, but worse with free-form PDFs.
- Tables not detected v1. Only headings + body chars + repeated headers/footers. For tables use
mode=balanced. pages[]truncated to 200. PDFs >200 pages exposepages_truncated: true; the agent must navigate tosections[].- No server cache: each call re-downloads the PDF. If you are going to make many, keep
content_hashon the client to reuse it viacache_key=in/convert/from-url.
Compatibility with other endpoints
- The spine tells you what to ask for. The actual extraction always goes through
/convert/from-url(or any other conversion endpoint) withpages=. mode=ultra_fast+pages== faster combination.
