Skip to content
documentflare
Tutorials

Chrome's Built-in AI for PDFs: Local Summaries and Translation

Summarizing, translating and searching a PDF with models running inside the browser: what Chrome's built-in AI APIs and Transformers.js change for document privacy.

Table of contents

The reflex is now routine: to summarize a forty-page contract, paste it into ChatGPT or drop it into an “AI PDF summarizer”. LayerX’s Enterprise AI and SaaS Data Security Report 2025 measures what that reflex costs: 40% of files uploaded to GenAI tools contain personal (PII) or payment (PCI) data, and nearly four in ten of those uploads go through personal accounts, outside any corporate control. That is shadow AI: the tool is not the problem — the document’s journey is.

Built-in browser AI reverses that journey: the model comes to the document, not the other way around. Here is what this approach concretely enables on a PDF today — and what it does not.

Three capabilities, two technologies

In Document Flare’s public catalogue, three tools in the “AI” group share the same trust boundary: all computation happens on the device.

Summarize (/en/tools/summarize-pdf) builds on the Summarizer API in Chrome and Edge 138+ — the browser’s own model (Gemini Nano or Phi depending on configuration). The PDF’s text is extracted page by page with pdf.js, split into ~15,000-character chunks, then summarized through a map-reduce scheme: each chunk is condensed, then the concatenation of summaries is summarized again until it fits the model’s window. Two formats — key-points or tl;dr — and three lengths. The output is a downloadable Markdown file; the PDF itself is never modified. Full walkthrough: summarizing a PDF with local AI.

Translate (/en/tools/translate-pdf) uses the Translator API — same family, same browser requirement. Seven languages in the selector (English, French, Spanish, Arabic, German, Italian, Portuguese), with automatic source-language detection when the LanguageDetector API is available. The output is plain text exported page by page — layout is not preserved. Details in translating a PDF without the cloud.

Semantic search (/en/tools/semantic-search) rests on different technology: Transformers.js and ONNX Runtime Web. The paraphrase-multilingual-MiniLM-L12-v2 model (q8-quantized variant, ~115 Mio) turns passages and queries into vectors, computed through WebGPU when available, WASM otherwise. Ranking passages by cosine similarity finds “payment deadline” where the contract says “settlement within 30 days”. See local semantic search.

What actually travels on the network

“Local” does not mean “zero requests”, and precision matters here:

  • The model downloads once. For semantic search, roughly 115 Mio from Hugging Face, triggered only by your click on the activation button — the interface announces the weight before starting. For summarize and translate, the browser manages its own model download. These are server → device flows.
  • The document never leaves. Extracted text, embeddings, your query: everything stays in memory on the device. No POST request carries the PDF or its content.
  • Then, offline. The semantic search model is served from the browser cache on later visits; the ONNX Runtime binaries are self-hosted rather than fetched from a CDN. A cached model makes the tool usable with no connection at all.

You can replay this: open the Network tab of the developer tools (F12), enable “Preserve log”, drop a PDF and start indexing. On first use, downloads from huggingface.co appear — inbound only. No request departs with your document. The full protocol lives in the network test section of PDF tools without upload.

Who this boundary matters to

Local summarization is not a technical curiosity: it is the only clean answer to shadow AI for regulated documents. A lawyer summarizing opposing counsel’s brief, a physician facing a medical report, an HR team handling a disciplinary file, a DPO reviewing a processing agreement — in each case, the question is not “is the AI reliable” but “who was the document handed to”. With an on-device model there is no recipient: no processor to contract, no DPA to sign, no prompt persisting in a third party’s history. The dedicated articles on lawyers, medical records, HR documents and DPOs detail each framework.

The limits, unhidden

  • Summarize and translate require Chrome or Edge 138+. The API exists in neither Firefox nor Safari; even on Chrome, availability() may report unavailable depending on region, enterprise policy or flags. The panel says so honestly instead of producing a fake result.
  • A small model is not a large model. Gemini Nano runs inside your browser precisely because it is compact: expect decent summaries, not the fine-grained analysis of a remote model a hundred times its size. For a critical negotiation, the summary is triage, not conclusion.
  • Semantic search has a real entry cost: ~115 Mio to download, RAM for the in-memory index (never persisted), computation time proportional to the document.
  • A text layer is required everywhere. A scan without extractable text can be neither summarized, translated nor indexed. The local OCR (Tesseract WASM, five languages) extracts the text into a .txt file — it does not inject a text layer into the PDF, but gives you material to work with.
  • One file, 50 Mio, 1,000 pages for all three tools — memory bounds, not commercial quotas.

The logical next step: document, don’t promise

On-device document AI is young — the browser APIs are still evolving. What will not change: the trust boundary is verifiable in the Network tab, not on a marketing page. That is the same thread as our pillar article on PDF tools without upload: when the computation happens on your device, the promise becomes observable.