Your PDF, as text. No code required.

Drop a real PDF below. Watch it become plain text right here, in your browser. Nothing is uploaded. If a page is a scan with no text layer, this tool says so plainly instead of returning silence.

Drop a real PDF below to see its plain text, in reading order, right here. It runs entirely in your browser, and nothing is uploaded.

whats-hard-about-pdf

A PDF's text does not sit in file order. It sits wherever the page tree, the cross-reference table, and any incremental saves left it. This reader builds the actual object graph. It tokenizes PDF's dict, array, and string syntax. It reads classic cross-reference tables and the newer cross-reference streams, including PNG-style prediction. It reads objects packed into compressed object streams. It follows the /Prev chain that a file grows every time it is saved again without a full rewrite. When a later revision redefines an object, that revision wins. An editor's incremental save does not leave the old copy visible. Real-world PDFs often have a damaged cross-reference table. When that happens, this tool scans the raw bytes for objects directly instead of giving up.

Getting characters right decides whether the output is text or noise. A simple font's codes resolve through /ToUnicode when it exists. Otherwise they resolve through a named base encoding, such as WinAnsi, MacRoman, or Standard, plus any custom /Differences. Composite fonts use two-byte Identity-H encoding. Most modern PDF writers use it for embedded, subsetted fonts. These fonts need their own /ToUnicode CMap parsed correctly, including the range form that maps a whole block of codes at once. Some fonts offer no route back to Unicode at all. This tool says so plainly. It does not guess at Latin-1 and hand back a wall of question marks.

The last piece is reading order. This is where most naive PDF-to-text tools fail. A two-column academic paper read left-to-right by raw position comes out with every other line from the wrong column. This tool reconstructs word spacing from actual glyph advances, not estimated gaps. It checks whether a page's text genuinely splits into two columns before treating it that way. A centered caption or a wide table does not get chopped into columns it does not have. A page that is really just a picture, with no text operators at all, gets marked as a scan needing OCR. It is never silently reported as empty.

what-this-tool-does-not-do

Stated plainly, not buried. This reader doesn't decrypt encrypted PDFs. It doesn't run OCR on scanned pages (txtfetch's API does that automatically), and it doesn't reconstruct table structure beyond spacing. It doesn't handle right-to-left or vertical writing. It also doesn't read annotations, form-field values, attachments, or a tagged PDF's own declared reading order (/StructTree). What it does do is above: real reading order from the page tree, real character decoding, and an honest per-page verdict.

what-to-do-next

Got the text out and want the API call for it directly? The panel above already has it, with your file's real name. Extracting many PDFs, ones bigger than this browser tool's 25 MB cap, or ones that need OCR? See the full PDF extraction guide →

faq

Does this tool upload my PDF anywhere?
No. The whole read happens in your browser. The file's bytes never leave your machine. Only the finished text ever leaves, and only if you choose to copy or download it.
Does it get multi-column layouts right?
Yes, for the common case. This tool checks whether a page's text splits into two well-separated columns spanning most of the page. If it does, it reads the left column top to bottom, then the right column top to bottom, not interleaved line by line. A single wide paragraph or a table is not mistaken for columns it doesn't have.
What happens with a scanned page, or a scanned PDF?
It's reported plainly, page by page. A page with no text layer at all, just an image, comes back marked as a scan needing OCR, not as empty. A PDF that's part digital, part scanned gets a status per page, and the summary tells you how many of each. Nothing here runs OCR itself; that's exactly what txtfetch's API adds automatically.
Why does text sometimes come out garbled, or missing entirely, instead of empty?
Almost always a missing /ToUnicode map on a font using two-byte Identity-H encoding. That's the classic case with no route from character code back to Unicode. This tool checks for that map first, then falls back to named base encodings with any /Differences applied. When a font truly can't be decoded, it says so and leaves that text out. It doesn't dump raw bytes as Latin-1 and call it done.
Can it open a password-protected or encrypted PDF?
No. Decrypting a PDF, even one with an empty user password, is outside what this browser tool does. It reports the file as encrypted and points at txtfetch's API instead of returning a garbled attempt.
Does it handle a PDF with a broken or missing cross-reference table?
Yes. A damaged or absent xref table is common in real-world PDFs, so this tool has a real fallback. When the table doesn't check out, it scans the file's raw bytes for its objects directly. The result is marked as a partial read so you know it happened, but the text still comes out.
Does it extract tables, form fields, or annotations?
Not structured tables. Table cells come out as spaced text, the same way plain text extraction always has, not as rows and columns. Form-field values, annotations, and attachments aren't read either; those are separate parts of a PDF's structure left out of this pass on purpose. What it does get right is the running text and its reading order.
Is there a file size limit?
This tool reads up to 25 MB entirely in your browser. Bigger files, or a batch you want to automate, go through the same extraction via the API, which has no such limit.

That was one file. The API does the queue.

This page read your PDF on your own machine. The API reads a folder of them.

Read the quickstart →

Get an API key →