Extrair texto do PDF
PDF to Text pulls the words out of a document so you can copy or search them. It reads the text the PDF already carries, exactly as it was put in, rather than looking at the page and guessing at the letters the way OCR does. So a scan — which holds only pictures of words — produces nothing here, and the tool says so instead of inventing something.
A interface desta ferramenta está em inglês.
Drop a PDF here
or drop anywhere on this page · Choose a file · 100 MB
O guia abaixo está disponível apenas em inglês.
How does PDF to Text work?
A PDF does not contain paragraphs. It contains instructions to place glyphs at coordinates — “draw this character at x=72, y=708 in this font at this size” — repeated a few thousand times per page. Extracting text means collecting those instructions and reconstructing the words and lines from where things landed.
This is not OCR, and the difference matters
OCR looks at a picture of a page and recognises shapes as letters, with an error rate. Text extraction reads the characters the document already stores, exactly. When the text layer is present the result is perfect — every character, including the ones OCR reliably confuses, like rn against m and l against 1.
When the text layer is absent — a scanned page is a photograph, and photographs have no characters — there is nothing to extract. The tool reports how many pages came back empty rather than returning silence and letting you conclude your file was broken. For those documents OCR is the right tool, and it is a genuinely different piece of software.
Reconstructing line breaks
The text items pdf.js returns are positioned fragments, not lines. Joining them with spaces produces one long paragraph per page, which is unreadable for anything with a layout. So the vertical coordinate of each fragment is compared with the last: a meaningful drop is a new line, a larger drop is a paragraph break, and a fragment at the same height is a continuation.
This is an approximation and it is honest about being one. Multi-column layouts are where it shows: the extractor reads in the order the glyphs were drawn, which for a two-column academic paper is frequently across both columns rather than down one. Nothing short of full layout analysis fixes that, and layout analysis guesses.
Ligatures, hyphens and the missing space
Three artefacts turn up in extracted text often enough to recognise. A ligature — the single glyph for fi or ffl — may extract as one character that looks right and does not match a search for “fi”. A word hyphenated across a line break stays hyphenated, because the hyphen is a real character in the document. And two words with no space between them usually mean the PDF positioned them separately rather than writing a space character, which is common in text set by typesetting software.
Everything stays in the tab
The extraction runs in your browser. This matters more than for most tools, because the documents people extract text from are contracts, reports and statements — and the extracted text is the searchable, greppable, paste-into-anything version of exactly that.
Input
invoice.pdf (2 pages, text layer present)
Output
--- page 1 --- INVOICE 2026-0412 Ada Lovelace Ltd Due: 30 September 2026 --- page 2 --- Terms and conditions…
What options and edge cases does PDF to Text support?
| Parameter | Type | Default | Behaviour & edge cases |
|---|---|---|---|
| Text layer | read exactly | — | Characters are taken from the document as stored. No recognition, so no error rate — unlike OCR, which guesses from pixels. |
| Scanned pages | empty | reported | A scan is a picture of words and contains no characters. The count of empty pages is shown rather than left for you to infer. |
| Line breaks | reconstructed | on | From the vertical position of each text fragment. A meaningful drop is a line, a larger one a paragraph. Turn it off for a single flowing block per page. |
| Page markers | boolean | on | A --- page N --- line between pages, which makes a long extraction navigable. |
| Multi-column layouts | approximate | — | Read in drawing order, which for two columns is often across rather than down. Fixing this needs layout analysis, which guesses. |
| Ligatures | as stored | — | An fi ligature may come out as a single character that looks correct and does not match a search for the two letters. |
| Hyphenation | preserved | — | A word broken across a line keeps its hyphen, because the hyphen is a real character in the document rather than a rendering artefact. |
| Encrypted PDFs | declined | — | Unlock with the password first. |
Frequently asked questions
I got nothing back. Is my PDF broken?
Almost certainly not — it is a scan. A scanned document is a photograph of a page, and a photograph contains no characters, only pixels arranged to look like them. There is no text layer to extract, which is why the tool reports the number of empty pages instead of returning silence. For that document you need OCR, which recognises shapes as letters and has an error rate; this reads characters that are already there and has none.
Why is my two-column paper jumbled?
Because extraction reads glyphs in the order they were drawn, and for a two-column layout that is frequently left column, right column, left column — across the page rather than down each column. Reconstructing the intended reading order requires analysing the page geometry and deciding where the columns are, which is guesswork that fails on tables, sidebars and figures. This tool does not guess; it tells you what order the characters are in.
Why are some words run together?
Because the PDF never wrote a space between them. Typesetting software often positions each word independently rather than emitting a space character, so the visual gap is a coordinate difference with no character behind it. An extractor that inserted spaces wherever it saw a gap would also insert them inside kerned words, which is worse. This is the most common artefact in extracted PDF text and it is inherent to the format.
Is this OCR?
No, and that is the most useful thing to know about it. OCR looks at an image and recognises characters, which works on scans and has an error rate — it confuses rn with m, l with 1, and does badly on poor scans. This reads the characters the document already stores, so where there is a text layer the result is exact. The two tools solve different problems and neither substitutes for the other.
Can I extract text from just some pages?
The whole document is extracted with page markers, which makes it trivial to find the part you want — search for "--- page 7 ---" and take what follows. A per-page range would save you a scroll and cost you the ability to search the whole thing at once, which is usually the reason people extract text in the first place.
Is my document uploaded?
No. pdf.js runs in this tab — it is Mozilla's engine, the same code Firefox uses to display PDFs — and the text is extracted on your machine. connect-src 'self' in the page's Content-Security-Policy means the browser would block an upload attempt. That matters here because extracted text is the fully searchable, copy-pasteable version of whatever the document contained.