Summarize a PDF Without Uploading It: How Local Document AI Works

A PDF lands in your inbox: sixty pages of research, a two-hundred-page contract, a board pack due tomorrow. You need the substance, not the whole thing. The obvious move — drop it into a chatbot — means uploading the document. For a published paper that is mildly rude; for a contract, a medical record, or anything under NDA it is simply not allowed.

Running it locally is entirely practical, and the way it works is more interesting than it looks. Three stages, each with its own failure mode, and knowing which stage failed turns “the AI gave me nonsense” into a two-minute fix.

Stage 1: extraction — the step that decides everything

The document is parsed page by page in your browser using pdf.js, the same open-source renderer Firefox uses. It reads the PDF’s text layer: the actual character data embedded in the file.

Here is the failure mode that accounts for most “it returned nothing” reports: a scanned PDF has no text layer. To pdf.js it is a stack of pictures. There is nothing to extract, so extraction returns nothing, so the summary has nothing to work with. The model is not broken and the file is not corrupt — it is an image.

The fix is a two-step pipeline: run the pages through OCR first to produce text, then summarize. If your document came out of a scanner, a fax, or a phone camera, start there. Word processors and LaTeX almost always embed a real text layer; scanners almost never do.

Stage 2: chunking — why the document is cut into 8,000-character parts

A language model can only consider a fixed window of text at once. This pipeline uses parts of 8,000 characters, roughly two thousand tokens — chosen to sit comfortably below the model’s context window rather than testing its limits.

The interesting part is where it cuts. A naive splitter counts 8,000 characters and slices, which regularly lands mid-sentence or mid-argument. This one splits on paragraph boundaries and fills each part up to the limit, so a part almost always ends where the author ended a thought. That single detail measurably improves summary quality: a chunk that ends mid-sentence produces a confused summary of a sentence that does not exist.

The tool shows you the result of this stage before you commit — page count, character count, and how many parts the document was divided into. A forty-page paper is typically a handful of parts; a two-hundred-page contract is a few dozen. If the part count looks wildly off, you have found your problem before spending any inference time.

Stage 3: map-reduce — summarise the parts, then summarise the summaries

With a short document that fits in one part, the pipeline takes a single pass and streams the answer as it is generated. With a long one it runs a map-reduce:

• Map. Each part is summarised independently into concise bullets, capped at 380 generated tokens. Every part gets its turn — nothing is silently dropped because the document was long.
• Reduce. Those per-part summaries are concatenated and distilled into one answer, with a larger budget of 900 tokens for the final synthesis.

This is why a local tool can handle a document far larger than its context window. The alternative — truncating to the first N pages and hoping — is how you get a confident summary of a contract that completely misses the liability clause on page 180. Map-reduce costs more compute and is the only approach that actually sees the whole document.

You can watch it happen: the interface reports which part is being processed, so a long run shows real progress rather than an indeterminate spinner.

Asking questions instead: the “NOTHING RELEVANT” trick

Summarising is the default; asking is often more useful. In question mode each part is not summarised but interrogated: the model is told to extract only what bears on your question, quoting key phrases where possible, and — this is the clever bit — to reply with exactly NOTHING RELEVANT if the part contains nothing applicable.

Those explicit nulls are then discarded before the final synthesis. The effect is a cheap, effective relevance filter: instead of asking a small model to hold two hundred pages in mind and find the one clause that matters, you ask it forty narrow questions and keep the three that answered. It is the same reason a research assistant reads section by section rather than skimming the whole binder at once.

What you get back is grounded in specific parts of the document rather than generated from the model’s general knowledge — which is what you want when the answer has consequences.

The model: four-bit weights and a one-gigabyte first load

The language model is a compact instruct-tuned network in the 1.5–1.7 B parameter class (SmolLM2 1.7B / Qwen2.5 1.5B depending on the tier), loaded through Transformers.js with 4-bit quantisation. On WebGPU it loads as q4f16 — four-bit weights with sixteen-bit activations, around a gigabyte of download. On the WebAssembly fallback it uses q4.

Two honest consequences. First, that download is real and it happens once; afterwards the browser cache means subsequent documents load immediately. Second, the WASM fallback is genuinely slow for generation — the tool warns you outright rather than pretending otherwise. If you find yourself waiting, the cause is almost always that you are on the CPU path. Chrome or Edge on a machine with a modern GPU is the difference between a coffee break and a few seconds.

Recipes

A 60-page research paper

Summarise first to get the shape of the argument. Then switch to question mode for the parts that matter to you: What is the sample size? What are the stated limitations? What did the authors fail to control for? Question mode against the methods section is where this workflow beats reading the abstract twice.

Contract review

Do not ask for “a summary”. Ask targeted questions: What are the termination conditions? Who bears liability for data loss? What are the payment terms and deadlines? Then read the passages it quotes. The output is a reading guide, not legal advice — but it turns two hundred pages into the four you actually need to read carefully.

Literature triage

Summarise a batch of papers one at a time and keep the bullets. Ten papers in fifteen minutes tells you which two deserve a full read, and you never had to upload your research direction to anyone.

Scanned documents

OCR first, then summarise. It is two tools instead of one and it is the only route that works — and because both run locally, the intermediate text file never leaves the machine either.

Limits worth knowing before you trust the output

• Tables and figures are largely invisible. Text extraction captures prose; the meaning locked inside a chart usually is not recovered.
• Reasoning across distant parts is limited. Map-reduce sees everything, but each part is read in isolation. A conclusion that depends on jointly reading page 4 and page 190 may not surface.
• Numbers deserve verification. Treat every figure the summary states as a claim to check against the source page.
• Encrypted or permission-locked PDFs cannot be parsed without the password, by design.

Why this belongs on your own machine

Documents people need summarised are disproportionately documents that must not be uploaded: contracts under negotiation, medical records, personnel files, unpublished research, anything covered by an NDA or a data-processing agreement. The cloud version of this task creates a server-side copy governed by someone else’s retention policy.

Locally there is no copy. The file is parsed in your browser’s memory, the model runs on your hardware, and the answer appears. Try it with the PDF summarizer — start with something you have already read, so you can judge the summary against knowledge you already have. That is the fastest way to calibrate how much to trust it.