PDF Text Extractor

What "Extract Text from PDF" Actually Means

There are two fundamentally different categories of PDF, and the extractor handles only one:

1. Digitally-authored PDFs. Word exports, Pages exports, LaTeX→PDF, web "Save as PDF," PDFs from databases/reports. The file contains text as text, sequences of glyph codes mapped to characters via embedded font information. Extraction reads these and reconstructs strings. Fast, accurate, lossless.

2. Scanned PDFs. Photocopier output, phone scans, archival document images. The file contains images of paper, no text. To "extract text" requires Optical Character Recognition, running an OCR engine (Tesseract.js in-browser, or Acrobat/Google Document AI server-side) over the page images. Slow, error-prone with skewed/dirty scans, and definitely not what this tool does.

A hybrid case exists: scanned PDFs that have been run through OCR (Adobe Acrobat's "Recognize Text," for example). These have an invisible text layer overlaying the image. Extraction reads the text layer, which is as accurate as the OCR was. Many older archived documents are this hybrid type.

To check which type you have: open the PDF, try to select text. If selection works (the cursor highlights individual words), it's a text-bearing PDF; the extractor will work. If selection picks up whole image blocks or nothing at all, it's image-only; OCR first.

How PDF.js Extracts Text

The PDF page content is a stream of operators, MoveTo, LineTo, ShowText, SetFont. ShowText includes a sequence of glyph codes plus position information. PDF.js:

1. Walks the content stream operator-by-operator.
2. For each ShowText, decodes glyph codes to characters using the embedded font's encoding table (ToUnicode CMap or built-in encoding).
3. Tracks the position of each character.
4. Returns text items with text + position information.
5. The extractor then sorts/joins these items into reading order (typically top-to-bottom, left-to-right).

This means: extraction quality depends heavily on the PDF's font encoding. A well-formed PDF with ToUnicode CMaps for every font returns clean Unicode. A PDF with proprietary or missing CMaps returns junk.

Common Quality Issues

Reading order in multi-column layouts. PDF.js reads in content-stream order, which is producer-dependent. Some producers write column 1 top-to-bottom, then column 2; others interleave. Multi-column academic papers are notorious. For these, server-side tools with layout analysis (pdftotext -layout, pdftohtml, GROBID for academic papers) are better.

Hyphenated line breaks. A word split as "hyphen-\nated" comes out as "hyphen-\nated", the dash and newline preserved. Post-processing should rejoin if you want full words.

Ligatures. "final" (fi ligature) might decode as "final" (U+FB01) instead of "final", two characters become one Unicode codepoint. Most processors handle this; some don't.

Spaces in some PDFs. Producer X inserts explicit spaces; producer Y positions characters with no space character and PDF.js infers spaces from gaps. Inference is imperfect, sometimes word boundaries are wrong.

Tables. Cells laid out as positioned text don't have any structural markup distinguishing "row" from "column." Extraction returns the cells joined as words; reconstructing the grid requires layout analysis. Tabula (Java tool) is designed for this.

Footers/headers. "Page 5 of 20" might appear mid-text in the extraction, interrupting body content. Some tools detect repeating header/footer patterns and strip them; this extractor doesn't.

Strategies for Better Results

1. Try the PDF first as-is. Modern Word/Pages output usually extracts cleanly.

2. If quality is bad, identify the issue. Run a few pages. Is reading order wrong? Are characters wrong? No text at all? Each implies different next steps.

3. For reading-order issues: switch to a layout-aware tool (pdftotext -layout on Linux/Mac).

4. For wrong-character issues: the PDF probably has bad CMaps. Try Adobe Acrobat's text export, which has more aggressive heuristics. Or accept the text is unreliable.

5. For no-text issues: the PDF is image-only. Run OCR first.

6. For special content (math, tables, code): use a content-aware tool. Tesseract OCR for math is unreliable; Mathpix is purpose-built. Tabula for tables. GROBID for scientific paper structure.

When Server-Side Tools Are Better

This in-browser extractor is the right choice for:

• Quick extraction of a few pages.
• Sensitive documents that can't be uploaded.
• No-install convenience.

For production pipelines, batch jobs, or layout-critical extractions:

• pdftotext (part of poppler), fast, reliable, has -layout mode for column-preserving output.
• Apache PDFBox, Java library, good API, configurable extraction.
• PyMuPDF (fitz), Python, excellent for programmatic extraction.
• GROBID, academic paper structure extraction (separates title, abstract, sections, references).
• Adobe PDF Extract API, paid, high-quality, handles complex layouts.
• Google Document AI / AWS Textract, cloud OCR + extraction with layout intelligence; very accurate, paid.

Privacy

PDF.js runs entirely in your browser. The PDF is read via FileReader, parsed in JavaScript memory, and the extracted text is rendered on the page. Open DevTools Network during extraction: zero outbound requests. Sensitive documents (NDAs, contracts, internal reports, medical records, legal filings) never leave your machine.