How to use an AI PDF summarizer without losing half the document

An AI PDF summarizer never reads your PDF. It reads what fell out of it.

The extraction happens once, at upload

When you attach a PDF to OpenCraft, the file is parsed once, at upload time — with pdf.js, and the recovered text layer is written to a plain .txt sidecar next to the original object. Every later turn replays that sidecar, not the PDF. The original bytes are kept, so a tool can still fetch the real file, but the summary, your follow-up questions, and any rewrite all read the same extracted text.

That design has one large benefit and one large consequence. The benefit: because the document arrives as text, any model can summarize a PDF, not just the few with native document input. The consequence: whatever the extractor missed is missed permanently, and no amount of re-prompting will recover it.

The limits, exactly

• 25 MB per PDF. Larger files are refused. A PDF’s parse cost is unbounded — pdf.js reads the whole document before a word comes out — which is why the ceiling sits below the 45 MB one for zip archives.
• Above 4 MB the bytes skip the request body. The browser takes a scoped token and uploads straight to Storage, then finalizes. Same stored result; you will not notice except that a big file takes longer to become ready.
• 320,000 characters kept in the sidecar. Anything past that is dropped at upload time and never exists again.
• 80,000 characters of one document reach the model per turn. Past that, the block the model receives ends with a visible notice naming the real length — for example, “truncated — showing the first 80,000 of 315,000 characters”. The model can tell you this, if you ask.
• Ten attachments per turn. Useful, because screenshots of unreadable pages are the standard workaround and they go to the model as actual pixels.

The failure that looks exactly like success

Fluency is not coverage

A pure scan is refused, which is the safe case: you find out at once. The dangerous case is the mixed document — a 90-page report where the appendix exhibits were scanned in, or a filing with twelve photographed pages among the typeset ones. That file uploads cleanly. The scanned pages contribute nothing. The summary that comes back is well organized, correctly cited to the pages it did see, and silently missing the exhibits.

Nothing in the output distinguishes it from a complete summary. NIST calls the general version of this confabulation: the model presents erroneous or missing-context content with the same confidence as verified content. With PDFs the model is not even confabulating — it is faithfully summarizing a document that was already incomplete when it arrived.

Why layout breaks extraction

A PDF does not store a document. It stores instructions for painting one. The PDF Association puts it plainly: an untagged file is only a description of appearance.

“put this glyph here, in this font, at these coordinates”

PDF Association

Reading order therefore has to be inferred from position and font size, and those heuristics fail precisely where documents get interesting: two columns, a table, a sidebar, a rotated exhibit, a footnote block.

There is a second, subtler point about extraction in OpenCraft: pages are merged into one continuous stream, so the text the model reads carries no page markers at all. Ask for page numbers and you will get plausible ones. Anchor on quoted phrases instead — those you can check — and derive page numbers separately, as the worked example below does.

Six ways a PDF loses content, and the tell for each

Add a seventh that is not a layout problem at all: length. Past 80,000 characters the model receives a truncation notice, and coverage simply stops around the same place every time you ask. The tell is that every re-prompt produces a thinner second half.

Worked example: a 90-page operations report

Four turns, in order

1. Inventory, not summary. “List every section heading you can see, in order, with the first eight words of each. Then say whether this attachment arrived truncated and at what character count.” The answer comes back with fourteen headings and a truncation notice. Sections fifteen through twenty-two and both appendices are simply not in the model’s view.
2. Split the file, keeping page numbers. Ask OpenCraft to fetch the original PDF and re-extract it page by page in the sandbox, writing one text file per twenty pages. Each chunk is now an attachment-sized read and carries the page range the merged stream had thrown away.
3. Summarize per chunk, with an anchor rule. Every material claim carries a verbatim quote of five to twelve words and the page it came from. Anything that cannot be anchored is written as “not established” rather than smoothed over.
4. Verify six anchors by hand. Search each quote in the original PDF. A quote that does not appear verbatim means the underlying text was scrambled — or was never there.

What you end up holding

One short section per major heading, a claims table with four columns (claim, quoted anchor, page, status), and — the part that matters — an explicit list of what the extraction never reached. In this file that list names the two scanned exhibits. You now know to open pages 87 and 88 yourself, which is information the fluent one-shot summary would never have given you.

Confidential documents, and documents that are simply too long

Know where the text goes

The file itself lands in a private bucket keyed to your account and is only ever served through short-lived signed URLs. The extracted text, though, is sent to whichever model provider you picked for that turn — that is what summarizing means. If a document is privileged, under NDA, or bound by a data-residency rule, the question is not whether the storage is private; it is whether that provider is approved. Redact before attaching, or do not attach.

Long documents degrade in the middle, not at the edges

Even inside the 80,000-character window, position matters. The Lost in the Middle study found that model accuracy is highest when the relevant passage sits near the start or end of the context and measurably worst when it sits in the middle. For a summarizer this is a practical instruction, not trivia: summarize in chunks small enough that nothing important is buried mid-context, and re-ask any question whose answer would have been in the middle of a long read.

When a summary is the wrong output entirely

Compression deletes exceptions

A contract, lease, policy, or licence carries its meaning in its carve-outs. Summarizing is the operation of dropping the less important material — which is exactly the operation that removes the exception clause, the survival provision, and the notice period. A summary of a contract tells you what the contract is broadly about. It does not tell you what you agreed to.

Absence is invisible to a summary

In legal filings, regulatory submissions, medical records, and audit reports, what matters is frequently what the document does not say: the warranty that was never given, the test that was never ordered, the disclosure that is missing. A summarizer reports presence. It has no way to report an absence it was never told to look for.

Use the summary as an index, not as the document

If you will quote it, cite it, file it, sign it, or rely on it in a dispute, quote from the PDF, not from the summary. Recompute any number that drives a decision from the source table rather than from the prose about the table. For anything with legal, medical, financial, or safety consequence, a qualified professional reads the document; the summary only tells them which pages to open first.

Used that way, an AI PDF summarizer is genuinely valuable — it turns ninety pages into a ranked list of what to read. Used as a substitute for reading, it is a confident account of a document nobody opened. If the job is to build something from the document rather than to find your way around it, the AI report generator workflow is the better starting point, and the OpenCraft use-case library covers the rest.