text_fields PDF Text Extractor star

What a PDF's Text Layer Actually Is

A PDF is not a picture of a page — at least, not usually. When a PDF is produced from a word processor, a web page, or typeset software, the page content is stored as a sequence of drawing instructions: "place glyph G at position (x, y) using font F at size S," repeated for every character on the page. Each of those glyph-placement instructions carries a reference back to a font's character-encoding table, which is how software can map the drawn shape back to an actual Unicode character rather than just a picture of one. This tool works by loading the PDF with Mozilla's open-source pdf.js library and calling its getTextContent() API on every page — critically, this reads that instruction stream directly, without ever rendering the page to pixels, so it works even on a device with no graphics acceleration and runs almost instantly compared to rendering.

This is fundamentally different from a scanned PDF, which is what you get when a paper document is photographed or run through a scanner and saved as PDF — in that case the "page" is just a full-page JPEG or TIFF image with no glyph instructions behind it at all, because no software ever knew what the text said; it only captured pixels. Calling getTextContent() on a scanned page returns nothing, or close to nothing, because there is no text layer to read — the information genuinely is not there in the file, in the same way you cannot select text on a scanned page in a normal PDF viewer. Recovering text from a scanned document requires a completely different technique, OCR (optical character recognition), which analyzes the pixel shapes and guesses at characters; that is a fundamentally different, much more error-prone process this tool does not perform. If your PDF is a scan, look for a dedicated image-to-text (OCR) tool instead — one is planned separately on this site.

Why Extracted Text Can Come Out of Order

A subtler problem affects even PDFs that do have a real text layer: getTextContent() returns glyph-placement items in whatever order they were originally drawn when the PDF was generated — not necessarily the order a human would read them in. Most simple, single-column documents are drawn top-to-bottom, left-to-right, matching natural reading order, so extraction looks correct. But a PDF exporter is free to draw content in any sequence it chooses, and many do not preserve visual order: a two-column academic paper, a magazine layout, a table, or a PDF with text boxes and callouts can easily have its drawing order interleaved or completely reversed relative to how a reader's eye would move across the page, because the specification defines position, not reading sequence. This tool concatenates each page's items in the order pdf.js reports them and separates pages with a clear --- Page N --- marker so you can see exactly which page each block came from and manually reorder a multi-column result if needed.

• Nothing is uploaded: the PDF is parsed entirely client-side using pdf.js running in your browser; the file never reaches this site's server.
• Password-protected PDFs will fail to open — this tool does not attempt to bypass PDF encryption or permissions.
• Extracted spacing may differ from the visual layout — tables in particular often extract as a flat sequence of cell values rather than a formatted grid, since PDF has no native concept of a "table" the way HTML does.
• Multi-page documents get page markers so you can tell where one page's content ends and the next begins, since PDF pages are otherwise independent content streams with no inherent paragraph break between them.