Ask an AI tool to read a scanned contract, and something strange happens: it tells you it understood the document.
It didn't.
I've watched this go wrong enough times that it stopped surprising me. Most PDF tools don't read a PDF at all.
They copy whatever characters happen to sit on the page, in whatever order the page happens to store them, and call that "extraction." A table becomes a wall of numbers with no rows. A form becomes text with no fields.
A scanned page becomes nothing, because there was never any text there to copy, just a picture of text pretending to be text.
If you've ever asked an AI assistant a question about a PDF and gotten a confidently wrong answer, this is very likely why. Here's what's really happening, and what it takes to fix it, including the exact engineering breakdown this piece is pulling from.
What you see is not what's stored
Open a PDF and you see a clean page: a heading, a paragraph, a tidy little table. None of that is actually in the file. Not really.
WHAT YOU SEE ON THE PAGE WHAT THE PDF ACTUALLY STORES
Q3 Report "Q" at (72, 40)
───────── "3" at (84, 40)
Revenue Costs " " at (96, 40)
142,500 88,200 "R" at (72, 58)
"e" at (81, 58)
(a clean heading "v" at (90, 58)
and a tidy table) ... character by character,
position by position
no row. no column. no table.
just ink, and where it goes.
I didn't quite believe this the first time someone explained it to me either. A PDF, underneath the page you see, is closer to a set of typesetting instructions: put this exact letter here, at this exact spot, in this font, at this size. It never says "this is a table." It never says "this is a heading." It just says where the ink goes.
That's fine for printing a page. It falls apart the moment you want a computer to pull meaning out of that page instead of just displaying it. Foxit's technical breakdown walks through this exact storage model in far more depth than a Medium post has room for.
Copying text isn't the same as understanding it
I used to assume "PDF extraction" meant a computer read the document roughly the way I would. It doesn't. Not by default.
Most extraction tools do exactly one thing well: they read those typesetting instructions and hand you back the characters, roughly in the order they were drawn. Engineers call this content serialization. You don't need the term. You just need to see where it breaks.
- A table with mismatched row heights, extremely common in financial statements, gets its rows silently merged into the wrong place.
- A signature, a stamp, or a logo isn't text at all, so it never gets copied, even when it matters for a real decision downstream.
- A scanned page has no underlying characters whatsoever. It's a photograph. Ask a basic tool to "extract" it and you get back nothing.
- A form field can hold a value stored completely separately from what's visually printed on the page. Copy the visible text, and you can lose the actual data entirely.
None of this is a bug in any one tool. It's the ceiling of what "copy the characters" was ever going to be able to do.
What actually understanding a document looks like
Real structural extraction asks a different question entirely. Not "what characters are here," but "what is this, and how does it relate to everything around it."
In practice, that's a few concrete things happening at once:
- Two blocks of text sitting side by side get recognized as two separate columns, not one garbled sentence.
- A cluster of numbers gets tied to a specific row of a specific table, not left floating as a page full of digits.
- A scanned page runs through actual character recognition first, so a photo of text becomes real, usable text.
- A form field's stored value gets read directly, instead of guessed at from whatever happens to be visually printed nearby.
A properly built system doesn't stop at "text" versus "not text" either. It typically recognizes something like a dozen distinct kinds of content on a page: titles, headings, ordinary paragraphs, tables, images, footnotes, hyperlinks, form fields, even stamped annotations, each one tagged for what it actually is.
Get all of that right, and a PDF stops being a picture a computer merely displays. It becomes structured data a computer can use: feed to an AI, drop into a spreadsheet, route into a CRM.
A quick before-and-after
Here's the same table, seen two ways. I find this comparison does more work than any explanation I could write around it.
BASIC EXTRACTION STRUCTURAL EXTRACTION
"Q3 Revenue Total 142,500 { "type": "table",
Q3 Costs 88,200 Net 54,300" "rows": [
["Q3 Revenue", "142,500"],
one wall of characters, ["Q3 Costs", "88,200"],
no rows, no columns, ["Net", "54,300"]
no idea what belongs ]}
where
every value knows exactly
which row and column
it belongs to
Left side, a machine can display it. Right side, a machine can actually use it. This is the exact transformation a properly built structural extraction engine is responsible for.
How this works, behind the scenes
You don't need to write any code to understand the shape of it. A structural extraction system like this usually runs in four plain steps.
UPLOAD ANALYZE CHECK STATUS DOWNLOAD
(get back a ──▶ (runs in the ──▶ (poll every ──▶ (get the finished,
ticket for background, couple of structured file)
the file) not instantly) seconds)
You hand over the document, and the system stores it and gives you back a ticket number for that file. You ask it to analyze the document, and because genuinely reading a messy page takes real processing time, it starts the job in the background instead of answering instantly. You check on that job every couple of seconds until it reports back done. Then you download the finished result: a structured file listing every table, form, heading, paragraph, and image the system found, each one tagged with exactly what it is and exactly where it sits on the page.
The first time I watched one of these jobs run, I kept refreshing before I realized the wait was the whole point, not a glitch. There's no single instant "read this PDF" button, because genuinely reading a messy real-world document was never going to be an instant operation. It's a careful pass through the whole page, once, done properly.
The proof isn't just anecdotal
This isn't just an opinion floating around engineering teams. NVIDIA ran its own comparison in 2025, testing a purpose-built extraction pipeline against a general-purpose AI vision model on real financial filings and reports. The dedicated extraction approach came out roughly 7% more accurate at pulling back the right information, and processed pages about 32 times faster.
I'll admit the size of that speed gap surprised me. The general-purpose model wasn't bad at describing a page in broad strokes. It was worse specifically at the boring, structural part: keeping every number tied to the correct row, every field tied to the correct label, consistently, every single time.
That consistency is exactly what a real business process needs. A rough guess can't reliably provide it, no matter how confident it sounds. It's exactly this gap that a dedicated structural extraction engine is built to close.
The part that quietly wrecks AI assistants specifically
If you've built or used any tool that lets an AI answer questions from your own documents, this is worth sitting with for a second.
That kind of tool works by chopping documents into chunks, then handing the AI the most relevant chunks for a given question.
If the reading order feeding those chunks is scrambled, say two columns merged into one garbled paragraph, or a table's numbers floating with no row labels, then no amount of clever search logic layered on top can recover the original meaning. You can't retrieve your way out of a bad starting chunk.
Correct structure has to happen before retrieval, not after.
It's not just AI assistants that get burned
RAG pipelines get most of the attention here, but they're not the only place this breaks down. I only started noticing this pattern once I stopped thinking of it as an "AI problem" at all.
- A finance team pulling numbers into a dashboard needs every value tied to the correct row label, or the dashboard is just confidently wrong.
- A sales team auto-filling a CRM from scanned contracts needs the actual form field values, not a best guess at whatever text happened to sit near a checkbox.
- A compliance team building an audit trail needs to know which stamps, signatures, and annotations exist on a document, not just the paragraph text.
Different teams, different tools, the same root cause every time: something upstream copied characters instead of understanding structure.
Signs your own pipeline already has this problem
A few blunt questions, if you're dealing with PDFs at any real volume. I've asked variations of these in enough conversations to know the honest answer usually comes with a pause first.
- Do your table exports ever have the right numbers sitting in the wrong row?
- Does anything break specifically on scanned or faxed documents, but work fine on ones typed directly into a PDF?
- Do form values ever come back blank even though the form clearly has data filled in?
- Does your AI assistant's answer quality quietly drop on longer, multi-column, or older documents specifically?
A yes to any of these usually traces back to the same root cause: something in the pipeline is copying characters, not reading structure.
Where this gets solved
Companies building document-heavy products don't solve this by hoping the AI figures it out. They solve it at the extraction layer, before the AI ever sees the document, using tools purpose-built to recognize tables, forms, scanned pages, and headers as the distinct things they actually are, not just characters on a grid.
Foxit's engineering team recently published a detailed technical walkthrough of exactly how this works under the hood, including the specific failure points in popular extraction libraries and how a properly built structural extraction engine avoids them. If you're building anything that touches PDFs at scale, invoices, contracts, scanned forms, it's worth the read: Inside Foxit's PDF Structural Extraction Engine.
The takeaway
Next time an AI hands you a confidently wrong answer about a document, look upstream before blaming the model. Somewhere before the AI ever got involved, a table probably lost its rows, or a scanned page never got read at all.
I think about this every time I see a demo where an AI "reads" a document flawlessly on stage. Stage demos use clean PDFs. Production doesn't. The gap between the two is exactly the gap this piece has been describing: copying characters versus genuinely understanding structure. Now you know which question to ask before you trust either one.
If you're building anything document-heavy
Foxit's developer team publishes breakdowns like this one regularly: PDF APIs, document automation, agentic document workflows. If "here's what's actually happening under the hood" is useful to you, Foxit Developer Solutions on LinkedIn is where they post it first, and the original technical write-up this piece is based on is worth bookmarking directly: Inside Foxit's PDF Structural Extraction Engine.
You can also follow Foxit's main LinkedIn page for the wider product news, outside of the developer-specific posts.
Top comments (0)