You need data out of a 200-page PDF because you want to feed a RAG pipeline, fill a database from contracts or filings, or ask questions that cross hundreds of pages.
If you tried putting the whole file into an LLM, we get it: the output was not good. Rows were missing, a total did not match, the answer was confident and wrong. That is not your prompt. These models were built to predict the next piece of text inside a limited window, not to read a long, structured document page by page and hand it back complete. Last evaluated: October 2026.
The short answer to how to do it properly: read the document page by page, join the pieces that belong together (above all tables that run over several pages), extract the fields from the joined result against a schema, and check that the output is complete. The rest of this guide shows why the shortcuts fail and what works.
If you put it all in an LLM, we get it: the output was not good
It is the first thing almost everyone tries, and it breaks for four reasons that have nothing to do with how well you wrote the prompt:
- The answer does not fit in the reply. Models accept far more input than they can write back in one response, so a long table cannot be returned in a single call, however large the input window is.
- The middle of the document gets read worse. Research on long contexts (Liu et al., 2023) shows that accuracy drops for information in the middle of a long input compared with the start and the end. The table that begins on page 87 sits in that zone. Source
- Cost and latency grow with the page count, and a failed attempt repeats the whole bill.
- Nothing tells you what is missing. The model answers fluently whether it saw every row or not.
The story does not end there for most teams, because the next idea is the obvious one.
So you split it into chunks, and that did not work either
Cutting the PDF into pages or fixed-size chunks solves the window problem and creates new ones. A table that runs over eight pages becomes eight unrelated fragments. Column headers that repeat on every page are read as data. A field that is printed once on page 1, such as the supplier or the contract number, is invisible to the chunk that reads page 40. Soon the code that stitches results back together is bigger than the extraction itself, and it breaks with every new layout.
The more careful variants (splitting by sections, or extracting each table row in parallel) help, but each leaves something open: a table that crosses a section boundary, or document-level fields living in a different call. We go through these trade-offs in our long-documents essay.
The approaches, side by side
| Approach | Keeps multi-page tables whole | Document-level fields next to table rows | Tells you if rows are missing | Typical limit |
|---|---|---|---|---|
| Whole document in one prompt | Only if it fits the reply | Yes | No | Output cap, middle-of-context loss, cost |
| Fixed-size or page chunks | No | No | No | Stitching code becomes the product |
| Split by sections, extract in parallel | Not across a section boundary | Needs a separate pass | No | Tables that cross a boundary |
| One extraction per table row, in parallel | Row by row | Separate call | Partly | Document context lives in another call |
| Agentic IDP (OCR + parse per page, extract across pages) | Yes, if table continuity is detected | Yes, same schema | Yes, if you add checks | Needs a parser that keeps layout and structure |
The last row is the pattern that holds up, and it is what an agentic IDP does. For tools that implement these patterns, see the best document parsing APIs.
The solution: an agentic IDP with OCR
The pattern that holds up is what an intelligent document processing (IDP) platform does: OCR and layout analysis first, then an agent that reasons over the whole document. anyformat works like this, in two layers:
- Parse every page on its own, in parallel. OCR and layout analysis split each page into blocks (text, tables, figures, headers, footers) and fix the reading order. Each page is independent, so 300 pages are 300 small jobs and not one huge one. Scans go through OCR first.
- Extract across the whole set of parsed blocks. An agentic extractor looks at the blocks of every page, recognizes which table fragments belong to the same table and joins them in order, and reads document-level fields from wherever they sit.
You describe the result once, as a schema with two kinds of fields: values that appear once per document (supplier, contract reference, filing date, total) and a table field with its columns. A single run returns both together, so you do not need a second pass or a join afterwards. In anyformat this is a Parse node followed by an Extract node, and the Extract node has an Agentic mode intended for dense tables and values that span several pages.
The table field is an object field with nested columns:
{
"name": "line_items",
"description": "One row per line of the table, across all pages",
"data_type": "object",
"nested_fields": [
{ "name": "description", "data_type": "string", "description": "Item description" },
{ "name": "quantity", "data_type": "integer", "description": "Quantity ordered" },
{ "name": "unit_price", "data_type": "float", "description": "Price per unit" },
{ "name": "line_total", "data_type": "float", "description": "Row total amount" }
]
}The result is a list with one entry per row, and every value carries a confidence score and the text and page it was read from. For the full flow with code, see how to extract structured data from a PDF with an LLM.
Try it on your own long document: the Free tier includes 50,000 credits with no credit card, enough to run a long file through this workflow.
It also works for RAG. If the goal is retrieval and not fields, the same parse step gives you the document as structured text with tables kept whole, ready to index. See PDF to markdown for LLMs.
How to check nothing is missing when you extract data from a long PDF
A long document makes silent loss easy, so build the check into the workflow:
- Count the rows. If the document says "42 items", the extraction should have 42 rows. A different count flags the document.
- Make the totals close. The sum of the line totals should match the printed subtotal, and subtotal plus tax should match the grand total. A validation step can run these rules on every document.
- Look at the confidence of the rows that matter. Set a threshold and route what falls below it to a person who sees the source page next to the value.
- Check the seams. Open the page breaks of one test document by hand: the last row of a page and the first of the next are where a table is most likely to be cut or duplicated.
Evidence on each value is what makes the manual check fast: the reviewer clicks a value and lands on the page it came from. See why grounding makes extraction auditable.
What it costs with anyformat
anyformat's pricing is credit-based, per page and per operator. At list rates, Standard Parse is 25 credits and Standard Extract 35 credits per page, so 60 credits per page; Agentic is 100 and 150 credits, so 250 credits per page. A credit costs €0.001 on Business and €0.0015 on Free and pay-as-you-go. For a 100-page document that is:
| 100-page document | Credits | Business (€0.001 per credit) | Free / pay-as-you-go (€0.0015) |
|---|---|---|---|
| Standard Parse + Standard Extract | 6,000 | €6.00 | €9.00 |
| Agentic Parse + Agentic Extract | 25,000 | €25.00 | €37.50 |
Validation rules are billed separately, per rule and once per extraction rather than per page; check the credits page for the current rate. Start with Standard and move to Agentic only for the documents where Standard gets a table wrong.
Limits, stated plainly
- Scans and photos lower accuracy for every method. Use a confidence threshold and a review step for them.
- Agentic mode does not support multi-file documents yet (several files treated as one document). Combine files before upload or process them separately.
- Very irregular tables (merged cells, tables that change columns halfway) need a test on your own files before you trust them.
- Accuracy depends on your documents. Before you rely on any vendor's headline figure, ours included, test fifty of your own, count rows against the source and measure field-level accuracy.
How to choose
If your documents are short and clean, a single prompt is enough. If they are long, ask each tool three questions: does a table that spans pages come back as one table, do document-level fields come back in the same result, and what tells me a row is missing? A tool that cannot answer the third one will fail you quietly. For a comparison of vendors, see our comparisons and, for a specific one, anyformat vs Docsumo.
Frequently asked questions
Can an LLM extract data from a 200-page PDF?
Yes, but not reliably in one prompt. The reply cannot hold a long table, accuracy drops in the middle of long inputs and nothing flags what was missed. Parse the pages separately and extract across them against a schema.
Why was the output of my long PDF not good?
These models were built to predict text inside a limited window, not to reproduce a long structured document. They also give no signal about what they missed, so a wrong answer looks the same as a right one.
How do I extract a table that spans many pages?
Detect which page-level table fragments belong together, join them in order, and ignore repeated column headers. Then compare the row count and totals with the document.
How do I get the supplier name and the line items in one result?
Declare both in one schema: single fields for the document-level values and an object field with nested columns for the table. One run returns them together.
How do I know no rows were dropped?
Count the rows against the document, make the totals close, and review low-confidence values with their source page open.
Can I use this for RAG?
Yes: the parse step returns the document as structured text with tables kept whole, ready to index.
How much does it cost per page?
At Standard rates, 60 credits per page (€0.06 on Business); at Agentic rates, 250 credits per page (€0.25 on Business).
Start with your longest documents. Upload the file that breaks your current pipeline, define the fields you need, and see the values with their confidence and their evidence on the page. The Free tier includes 50,000 credits with no credit card.
Disclosure: anyformat sells document extraction; the comparison criteria and dates are stated.
