PDF to Text

Think about the PDFs you actually need the text out of. A signed lease. An invoice you have to retype into an expense form. A discharge summary from a hospital. A scanned passport page for a visa application. A bank statement a landlord asked for. Every one of those is a document you would not hand to a stranger, and every mainstream "PDF to text" service on the web works by asking you to do exactly that: upload the file to a server you know nothing about, where it is processed under a retention policy you did not read, by a company whose security you cannot audit. This tool never asks. The recognition engine — a self-hosted build of Tesseract compiled to WebAssembly — downloads into your browser and runs there, the PDF is opened and rendered locally by pdf.js, and the text comes back without a single byte of your document leaving the machine. There is no upload to trust, no server-side copy to delete, and no account to close afterwards. You can prove it in thirty seconds by opening your browser's network inspector and watching nothing go out while a page is read.

It reads a picture of your page, not the PDF's text layer

This is the single most important thing to understand, and almost nobody says it. There are two completely different ways to get text out of a PDF, and the entire category conflates them. The first is extraction: if the PDF was produced digitally — exported from a word processor, printed to PDF from a browser, generated by an accounting system — it contains an actual text layer, characters stored as characters, and a program can simply read them out perfectly, every time. The second is optical character recognition: turn the page into a picture and have a model look at the shapes and guess which letters they are. This tool does the second one, always. Every page of every PDF you give it is rasterised to an image and then read visually, exactly as if you had photographed it. Give it a pristine, digitally generated PDF and it will still OCR it as a picture of text rather than lifting the perfect characters that are sitting right there. That is a genuine limitation and it is stated here rather than buried, because the consequence is real: on a born-digital PDF, a text-layer extractor would give you a flawless result and this will give you a very good one with the occasional character-level slip. Where OCR is the only option — scans, photocopies, faxes, photographed pages, anything that was paper before it was a file — it is the right and often the only tool for the job.

Twenty pages per run, said out loud

There is a hard cap of twenty pages in a single run. Drop in a longer document and the first twenty are read and the rest are skipped — and the tool tells you so, in the results, with the exact count of pages it read and the exact count it left behind. It does not quietly truncate and let you discover the missing half later. The cap exists because OCR is genuinely expensive work and it is happening on your device: each page has to be rendered, then examined by a neural recogniser, and doing that unbounded in a browser tab is how you get a frozen phone, a killed tab, and no output at all. Twenty pages is the size at which a laptop stays responsive and a mid-range phone survives. If your document is longer, split it in whatever you use to view PDFs and run the parts in sequence — the model is already cached after the first run, so subsequent batches start immediately. A server-side service can offer you two hundred pages because it is spending its own CPU, and the price of that offer is your document sitting on its disk. That is the trade this tool declines to make, and the twenty-page cap is the visible cost of declining it.

What comes out, and how it is arranged

Plain text. Selectable in the browser, copyable to the clipboard with one button, and downloadable as a .txt file. Multi-page runs are separated by a marker line reading --- Page 3 --- before each page's content, so you always know where one page ended and the next began, and so a long result can be split again later by anything that can find that pattern. What you do not get is a formatted document. Columns are flattened into reading order, tables lose their grid and come back as sequences of cell contents, headers and footers appear in the flow wherever they sat on the page, and bold, italics, and font sizes are gone entirely — OCR reads characters, not layout. For the jobs people actually bring here — quoting a clause, retyping an invoice total, making a scanned report searchable, pasting an address, feeding a document to something else — plain text is precisely what you wanted. If you needed a formatted Word file back, that is a different category of software and this is not pretending to be it.

English, printed. Not handwriting.

Two limits worth knowing before you spend time on a document. First, the recognition model shipped here is English. That is one trained model, about two megabytes, downloaded from this site's own servers on first use and cached afterwards — and that constraint is exactly what makes the privacy promise affordable, because every additional language is another multi-megabyte download to your device. Latin-script fragments inside English text, like names, product codes, and URLs, generally survive fine; a full document in Hindi, Arabic, or Chinese needs its own model and will come back as nonsense without one. Second, the engine is trained on typeset and printed characters. Printed documents, laser and inkjet output, thermal receipts, typewritten pages, labels, and rendered screen text are its home ground. Handwriting is not supported. Careful separated block capitals sometimes come through; ordinary cursive will produce confident-looking garbage, and the failure is silent because OCR always returns something. If your PDF is a scan of handwritten notes, no amount of scan quality will rescue it, and it is better to know that now than after twenty pages.

Getting a better read out of a bad scan

Because pages are rendered before they are read, the quality of what the recogniser sees is the quality of what is on the page. Three things dominate the result. Contrast: dark text on a light background, evenly lit. A shadow crossing the page, or a photocopy so faint it has gone grey, is the most common cause of a garbled region — the engine thresholds the image into black and white, and a gradient moves that threshold mid-paragraph. Straightness: lines should run horizontally. Slight skew from a hand-fed scanner is tolerated; a page scanned sideways or upside down is not, so fix the orientation in your PDF viewer and re-export before running it here. Resolution and cleanliness: a scan made at 300 DPI reads far better than one made at 96, and speckle from a dirty scanner glass or a heavily compressed fax gets interpreted as punctuation. If the PDF is a photograph of paper rather than a scan, the same rules that govern photographing any document apply — square-on, in focus, filling the frame, no glare. And since everything runs locally, retrying a better version costs you nothing but the seconds it takes.

Proofread the numbers, always

OCR errors are not evenly dangerous. A mangled word announces itself — you read it, it is obviously wrong, you fix it. A mangled digit does not. The classic confusions are 0 against O, 1 against l against I, 5 against S, 8 against B, and rn read as m, and they cluster wherever the source was soft or shadowed. In prose those slips are visible and harmless. In an amount, a date, an account number, a policy reference, or a dosage they are invisible and expensive, because the wrong number looks exactly as plausible as the right one and it will travel unchallenged into whatever spreadsheet or form you paste it into. So use the output the way you would use a fast first draft from a careful assistant: trust the words, verify every figure against the original page before it matters. The per-page separators help here — check the numbers on one page at a time against the page image rather than scanning a wall of text and hoping.

Locked and broken files are turned away, not mangled

Two categories of file will stop immediately with a plain message rather than a spinner that never resolves. Password-protected PDFs are refused: the tool will not attempt to open an encrypted document, so remove the password in whatever application you normally use, save a copy, and run that. Corrupt or malformed PDFs get the same direct treatment — the failure is detected when the first page is rendered, before you have committed to a long run, so you find out in a second rather than a minute. Both messages say what happened in ordinary words. That is a deliberate choice: the worst behaviour a document tool can have is failing ambiguously, because you are left unsure whether to wait, retry, or go find another copy of the file. If your input is a single image rather than a PDF, the image to text tool is the same engine pointed at screenshots and photos.