PDF to text means reading the selectable text layer that lives inside a PDF document and reassembling it, page by page, into a single UTF-8 plain-text file that you can copy, search, or hand off to another editor. A browser-based PDF to Text Converter does this by handing the file to PDF.js, asking it for the bounded text items on every page in document order, honoring any explicit end-of-line markers, and joining the results into one TXT with a clear separator between pages. Nothing leaves your device: parsing, item collection, preview, copy, and download all run inside the same browser tab, and the original PDF is never modified or uploaded to a remote service. For digital PDFs created in a word processor, layout app, or typesetting tool, this approach usually returns clean, useful text. For image-only scans of printed pages, it returns little or nothing, because there is no text layer to read.
What "PDF to Text" Actually Means
The phrase sounds simple, but it describes a specific technical operation that is different from converting a document or running OCR. "Converting" usually implies changing the format — turning a Word file into a PDF, for example, or a PDF into a Word file. "OCR" implies recognizing glyphs from a pixel image and inventing characters that were never stored as text. PDF to text, as used here, means only this: read the text objects that already exist in the file, and write them out as plain characters in the order PDF.js reports them.
A digitally created PDF usually stores characters, font references, positions on the page, and text-showing instructions inside its content streams. PDF.js can expose those instructions as a stream of bounded text items, each carrying a string, coordinates, font information, and a flag that says whether the item ends a line. The converter consumes those items in order, joins them with conservative spaces, and writes the result to a single text file. That output is plain UTF-8 text; it is not HTML, not Markdown, and not a re-typeset document. The converter does not execute embedded scripts, follow links, fetch external resources, or interpret the result as anything other than inert plain text.
How a Digital PDF Stores Text
Understanding why some extractions look clean and others look jumbled starts with how PDFs actually describe their content. Unlike a Word document or an HTML page, a PDF does not store paragraphs as paragraphs. It stores characters placed at coordinates on a page. A PDF reader like PDF.js walks the content stream, pulls each text-showing instruction in the order it was written, and reconstructs what the page looks like by painting the glyphs in position.
Because of that, reading order in a PDF is whatever order the producing software chose when it wrote the file. A simple one-column letter reads top to bottom in the same order a human expects. A multi-column article, a sidebar next to body text, a table with cells filled in row by row, or a heading followed by a footnote can all interleave items in ways that do not match the visual reading order. Headers and footers are typically written once per page, so the same string can repeat on every page separator in the output. The converter follows the item order supplied by PDF.js and inserts conservative spaces between adjacent items; it does not try to rebuild columns, semantic headings, or table cells.
If a PDF was produced by scanning a printed page, none of this applies. The PDF holds a page-sized image (or several images) and almost no text data. PDF.js will report zero or near-zero text items for each page, and the converter will faithfully produce an empty or nearly empty result. That is not a bug; it is the correct behavior for a tool that only reads the text layer.
How to Extract PDF Text Locally in Your Browser
The PDF to Text Converter takes a single PDF and returns a UTF-8 TXT, all in your browser. Three steps cover the whole workflow.
- Choose one non-empty PDF up to 25 MiB from your device. The file must not be image-only if you want meaningful text; scans without a text layer need a separate OCR workflow.
- Click Convert to Text. The tool loads PDF.js and its shared worker only at this point, then walks the document page by page, reading bounded text items in page order and honoring any explicit end-of-line markers.
- Review the page and character counts shown in the preview, then copy the assembled text or download the UTF-8 TXT file using the deterministic filename derived from your original PDF.
Changing the input clears the previous output, so the counts you see always describe the file you just converted. If the file exceeds a limit — 25 MiB, 40 pages, the per-page text-item budget, the total text-item budget, the per-item length, or the total output character budget — the tool returns an error instead of a partial result that looks complete.
When a PDF Returns Nothing: Scans and OCR
The fastest way to figure out whether a PDF will give you text is to open it in any normal viewer and try to select a sentence with your cursor. If the cursor highlights individual words, the file has a text layer and the converter can read it. If the cursor drags the whole page as one image, the file is a scan, and the converter will not invent a transcript for it.
This distinction matters because OCR is a fundamentally different operation. OCR inspects pixel data, runs shape recognition, and guesses characters. PDF text extraction reads instructions that were stored as characters when the PDF was created. The PDF to Text Converter does only the second job, by design. If you have a scanned contract, an old book chapter, or a photographed invoice, you need an OCR workflow first; only then can the resulting text be reused, copied, or downloaded as a TXT.
Limits the Converter Enforces on Every File
The converter applies several hard caps to keep the browser tab responsive and to prevent silent partial results.
| Constraint | Limit | What happens if exceeded |
|---|---|---|
| File size | 25 MiB | Conversion is rejected before parsing starts |
| Page count | 40 pages | Conversion is rejected before parsing starts |
| Text items per page | Bounded | Page is reported as over budget and conversion fails |
| Total text items across the file | Bounded | Conversion fails with a clear message |
| Single text-item length | Bounded | Item is rejected and conversion fails |
| Total output characters | Bounded | Conversion fails before a partial file is written |
Encrypted, malformed, unsupported, or damaged files also fail. The tool does not bypass passwords, repair PDFs, validate digital signatures, or claim that any extracted content is accurate or safe. Anything the limits touch is treated as failure, not as a truncated success.
Reading Order, Columns, and Other Layout Quirks
Even on a perfectly digital PDF, the text you get back is only as good as the order PDF.js was asked to walk. A simple letter, a flat one-column report, or a manuscript with normal body text tends to come out clean. Documents with multiple columns, callout boxes next to body copy, tables, fillable form fields, headers paired with running footers, or text drawn one glyph at a time can produce results where a heading appears in the middle of a paragraph, where a sidebar starts before the body text it sits beside, or where the same footer string repeats at the bottom of every page separator.
The converter does not try to hide these quirks. It preserves the item order PDF.js supplies, honors explicit end-of-line markers, and inserts conservative spaces between adjacent items so words do not run together. Each page receives a clear separator in the combined output so that a footer from one page and a heading from the next cannot silently merge, and empty pages remain represented so the page count in the report stays aligned with the source document. Repeated headers, hidden text, ligature normalization, and accessibility ordering may all appear according to the PDF's own structure, which is one reason a quick review against the original is worth doing before quoting or republishing the text.
When to Use the Converter (and When Not To)
Use the PDF to Text Converter when you want to quote a passage of accessible text, build a rough searchable draft from a PDF, inspect whether a file actually has a usable text layer, or move simple page text into another editor. Local processing means the document never leaves the browser tab, which is useful for contracts, internal memos, or anything else you would not want uploaded to an unknown server. If you would like a focused walkthrough of that local-processing guarantee, see how local extraction keeps your PDF in the browser.
Skip the converter and reach for a different tool when visual fidelity matters more than text reuse. PDF to JPG, PDF to PNG, and PDF to Long Image all keep the page looking exactly like the original; they are the right choice for archiving, sharing, or printing visually rich layouts. When the source is image-only, a dedicated OCR workflow is the only path, because the converter will not invent a transcript from pixels. For a complete extraction round-trip in the other direction, plain text can be turned back into a clean paginated PDF with the TXT to PDF tool. The original PDF is never modified by the converter, so you can always re-export it, re-render it, or hand it to another tool.
Related reading: Remove PDF Password to JPG Convert: A Local Method.