PDF Text Extractor
Extract every line of text from a PDF — copy to clipboard or download as .txt. Per-page sections.
PDF Text Extractor
How to extract text from a PDF
Add your PDF
Drag your file onto the dropzone or click to choose. The tool reads every page's text content and shows the result in the textarea.
Toggle page headers if needed
Tick Include page headers to add === PAGE N === dividers between pages — useful if you need to know which page each line came from. Untick for clean plain text suitable for re-processing.
Copy or download
Copy to clipboard drops the entire output into your clipboard — paste into Word, Notes, ChatGPT, anywhere. Download .txt saves the text as a UTF-8 file named after the source PDF.
PDF text extraction — the hidden plumbing of every document workflow
Extracting text from a PDF is the single most common "PDF utility" operation in any document-heavy job. Lawyers do it to feed contracts into review systems. Researchers do it to feed papers into RAG pipelines. Translators do it because their CAT tools need plain text input. Students do it to get quotes into essays without retyping. The volume is enormous, and the quality of the underlying extraction is the difference between five minutes of work and an afternoon of cleanup.
How PDF text actually works
A PDF doesn't store text the way a Word document does — as a flat stream of characters with formatting. Instead, each page's content is a sequence of drawing instructions: "place this glyph at this exact x,y coordinate." Text extraction means walking those instructions, identifying which ones place glyphs, mapping the glyphs back to Unicode characters, and reassembling the result in reading order. pdf.js — Mozilla's PDF engine, the one inside Firefox's built-in viewer — does this work for us, and marks where each line ends so the output keeps its line breaks.
Text in a PDF is positioning instructions, not paragraphs. Extracting it well means rebuilding the reading order from coordinates. That's why every "PDF to text" tool produces subtly different output.
Why it runs in your browser
Documents people extract text from — contracts, theses, filings, client files — are usually confidential. This tool reads the file in your browser tab and never uploads it; open the network panel while it runs and you will see no request carrying your document.
What this tool does — and what it doesn't
This extractor handles every PDF that has an embedded text layer — typical of digitally-created PDFs from Word, Pages, LaTeX, Google Docs, Acrobat, design tools, and any other modern document workflow. It does NOT handle scanned PDFs (image-only PDFs with no embedded text) — those need OCR first, which is a different operation. If you load a scanned PDF the tool says it found no text layer rather than guessing.
Glyph positions, not paragraphs: CMaps, columns, ligatures and tables
PDFs store text as glyph-positioning instructions, not as paragraphs. Extraction means walking those positions and reassembling the reading order from coordinates.
Unicode mapping in PDFs uses a CMap (character map) that translates glyph IDs to Unicode codepoints. Fonts with no usable Unicode mapping extract as gibberish — the text looks fine on screen but the characters behind it are unknown.
Multi-column documents (newspapers, academic papers) are notoriously hard to extract because pdf.js doesn't know columns exist — it walks left-to-right top-to-bottom by position.
Ligatures (fi, fl, ffi) are stored as single glyphs but should decode to multiple Unicode characters. pdf.js handles the common cases automatically.
Tables in PDFs almost never extract cleanly — the cell structure is invisible to the text-extraction layer. For tabular data, use a dedicated PDF-to-CSV tool.
pdf.js marks the last run of each line with hasEOL; this tool turns those into line breaks, so a page comes out as lines rather than one run-on paragraph.
Right-to-left scripts (Arabic, Hebrew) are the hardest case: pdf.js records each run's direction, but mixed-direction lines can still come out in an order you need to check.
Mathematical formulas (LaTeX-rendered) usually extract as the underlying letters and operators, not the rendered math. "x² + y²" becomes "x 2 + y 2" — a known limitation of all PDF-to-text tools.
pdf.js is Mozilla's, Apache-2.0 licensed, and served from this site: a 353 KB module plus a 1.4 MB worker (about 99 KB and 403 KB gzipped).
For RAG / LLM ingestion pipelines, extraction quality matters more than speed — bad extraction poisons every downstream prompt, so spot-check a page against the original.
FAQ
-
No. pdf.js runs entirely in your browser. The PDF is read into memory, text is extracted in memory, output is written to a textarea you can copy or download from. Open DevTools → Network and watch — zero outbound traffic.
-
The PDF is a scanned image with no embedded text layer. PDFs created by scanners typically contain only page images — there's no text to extract. Run the file through OCR first: Adobe Acrobat's "Recognize Text" tool, macOS Preview's "Export → Searchable PDF," or a desktop tool like Tesseract.
-
pdf.js reconstructs reading order from glyph positions, which doesn't always match human-perceived reading order. Multi-column layouts, sidebars, and footnotes can interleave unpredictably. For mission-critical extraction, run the output through a quick manual review — or use a more advanced tool like pdfplumber on the desktop.
-
No — output is plain text (UTF-8). For formatted output (Word, HTML, Markdown) you need a richer conversion tool. Plain text is what's useful for LLM ingestion, search indexing, and translation workflows.
-
If the password is restriction-only (no-copy, no-print), pdf.js will still extract via its own decoder. Open-password protected PDFs need the password removed first via Adobe Acrobat or macOS Preview.
-
Soft limit: browser memory. Large files are limited by memory rather than by the tool. The textarea preview may slow down with millions of characters — for very large documents, download as .txt and open in a real text editor (VS Code, Sublime).
-
Yes. pdf.js handles Unicode end-to-end. Chinese, Japanese, Korean, Arabic, Hebrew, Cyrillic, Greek, and most Indic scripts work out of the box. Check right-to-left text against the original: mixed-direction lines are the case most likely to come out in the wrong order.
-
Tables in PDFs are positioning instructions, not table structures. The extractor walks left-to-right top-to-bottom and produces text in that reading order — which interleaves cells from adjacent rows. For tables, use a dedicated PDF-to-CSV tool or pdfplumber on the desktop.
-
Yes — that's a primary use case. The output is clean UTF-8 plain text suitable for chunking, embedding, and storage in a vector database. The per-page header option is useful for citation tracking (knowing which page a chunk came from).
-
Yes on iOS Safari and Chrome on Android. Extraction speed depends on page count and the phone.
Method & sources
What this tool implements
- Corrected 2026-09-30: the batch-45 join added a space between any two runs without one, which split words at font changes ("(w-1)" became "( w - 1)" on ISO 32000 p.213); a test PDF drawn with a mid-word bold change now extracts "Hello world".
- Without pdf.js's CMaps a page whose Chinese font is not embedded extracted only its English line; the CMaps (Adobe, BSD) are now self-hosted and loaded.
- pdf.js is Mozilla's, Apache-2.0 licensed. Text in a PDF is positioned glyph runs, not paragraphs; columns, tables and mixed-direction lines are where extraction order most often goes wrong.
Sources
- Mozilla. PDF.js (Apache 2.0). https://mozilla.github.io/pdf.js/
- ISO. ISO 32000-1:2008, Portable document format — Part 1: PDF 1.7 (9.10 Extraction of text content; 9.7.5 CMaps). https://www.iso.org/standard/51502.html
Pick up where you left off
Stored only in this browser — never sent to our servers.