Extracting the Text from a PDF, and What the Layout Does to It

A PDF has no lines — only glyphs at coordinates

This is the fact everything else follows from, and almost no guide states it plainly. A PDF page is a list of drawing instructions. One of them says: put this glyph at this point, in this font, at this size. There is no object in the file that means “paragraph”, none that means “line”, and none that records which block of text a reader is supposed to read first. The format is defined by ISO 32000, and reading order is simply not part of what a basic page description carries.

So extraction is reconstruction, and this is where every tool differs. This one takes the run of glyphs that pdf.js hands back, each with its own position, and groups those whose baselines fall within half a glyph height of each other into a line. Within a line it sorts left to right and inserts a space wherever the horizontal gap exceeds a fifth of the glyph height — because a PDF that spaces words by moving the cursor emits no space character at all. That reconstruction is good. It is also the reason the failures below are the shape they are: they are all cases where the geometry of the page and the logic of the document disagree.

Two columns: the failure you will meet first

A two-column page was set up with four lines in each column and extracted. The result begins: “Revenue for the quarter rose by four Costs grew more slowly, at two per cent,”. The first half is the opening line of the left column; the second half is the opening line of the right one. They share a baseline, so as far as the reconstruction is concerned they are one line, and they are joined by a space.

Switching to “Join into paragraphs” makes it worse rather than better. The interleaved lines are now glued into a single block of prose in which every sentence is cut in half by a fragment of the other column. Worse still, the de-hyphenation stops working: the left column ended a line with “sub-”, but by the time the paragraph logic looks at the buffer the hyphen is no longer the last character — the right column's text is sitting after it. The output reads “by the sub- reclassification of contractors into the scription business”. The word “subscription” has been torn in two and the halves are eleven words apart.

There is no setting that fixes this, because fixing it means detecting the columns, and column detection is a genuinely hard problem that the tool does not attempt. The practical workaround is to extract a page at a time and cut the result apart by hand, or to accept that a two-column academic paper or a printed statute will need editing after extraction rather than before it.

Tables keep their rows and lose their columns

A four-column table extracted cleanly at the row level: “Region Revenue Cost Margin”, then “North 1,240 980 21%”. Every row is on its own line and in the right order. What is gone is the column boundary — cells are separated by a single space, exactly like words, so nothing in the output distinguishes a cell break from a word break. Paste that into a spreadsheet and you get one column.

The sharper problem is the empty cell. A table with a blank “Note” on one row and a blank “Supplier” on another produced “Chair Nordia 89.00” and “Desk back-order 240.00” — four columns arriving as three values, twice, with nothing to say which column was skipped. A reader reconstructing that table by eye would put “back-order” in the Supplier column. Nothing in the text says otherwise. And a cell whose contents wrap onto a second line becomes its own row: the note “discontinued, replacement pending” came out as “Lamp Vela discontinued, 15.00” followed by a line reading only “replacement pending”.

In paragraph mode the table stops being a table at all. The whole thing came back as one sentence: “Region Revenue Cost Margin North 1,240 980 21% South 870 910 -5% East 2,310 1,760 24%”. If your document contains a table you care about, use “Keep the lines” — and expect to rebuild the columns yourself.

Hyphens, ligatures and the header on every page

Hyphenation is handled, with a caveat. In paragraph mode a line ending in a hyphen has the hyphen stripped and the next line glued straight on, so “con-” and “cluded” become “concluded” and “re-” and “vised” become “revised”. Both were verified on a single-column page. But the rule is unconditional: it fires on any line-final hyphen, including one that belongs in the word. On a test page “long-” at a line end plus “term” produced “longterm”, and “e-” plus “mail” produced “email”. Neither is a typo in the source; both are the repair over-firing.

Ligatures are the good news, and they are worth understanding because they break search in tools that get them wrong. A typesetter's fi is often a single character in the font, and a subset font maps it back to Unicode through a table the PDF carries. Extract naively and you get U+FB01, which looks identical on screen and matches nothing when you search for “file”. The engine underneath this tool normalises by default, so the same test file returns “confirmed” and “fluently” as ordinary letters. Re-running the identical file with normalisation switched off returned the ligature characters instead — which is how we know the normalisation is what is doing the work.

Running headers and footers are extracted, on every single page, and nothing removes them. A 44-page Spanish consolidated decree yielded exactly 44 copies of “LEGISLACIÓN CONSOLIDADA” and 44 page-number lines, dropped into the middle of the running text. In the extracted file, one sentence ends mid-clause at the foot of page 5, is followed by a footer, a page marker and two header lines, and resumes on page 6. That is not a bug in the reconstruction — the header genuinely is on the page — but it means any long document needs a find-and-replace pass to strip the furniture before the text is usable.

A scanned PDF holds no text, and OCR is a different operation

This is the commonest disappointment, and it deserves a blunt answer. When a page is scanned or photographed, the PDF that results contains one image and nothing else. There are no glyphs, no font, no character codes — just pixels that happen to look like letters to you. Extraction has nothing to find, and no amount of choosing a different layout mode changes that.

The tool does say so, which not every tool does. Fed a page containing only an image, it returned the empty string and displayed a sentence explaining that the file holds no selectable text and is most likely a scan with no text layer to extract. It does not silently hand back a blank textarea, and it does not hand back a textarea containing only page markers — the emptiness is tested on the page bodies, not on the assembled string. Turning a scan into text needs optical character recognition, which reads the pixels and guesses at letters. This tool does not do that, and nothing in it does it quietly in the background.

Two ways a page comes back empty, and what you are told

First: a page range naming pages the file does not have. Type 99 against a two-page document and the range parser drops the out-of-range number, leaving nothing at all to extract. That is not the same thing as a page with no text on it, and it no longer gets the same answer: the message names how many pages the document actually holds and asks you to correct the range or clear it. Measured on a two-page file asked for page 99 — “None of the pages you asked for exist in this document: it holds 2 page(s).” A range that runs past the end rather than starting past it is simply clipped: asking for 1-3 of that same file extracts both pages without comment.

Second: a document that mixes typed pages with a scanned insert — a signed page, a fax, a certificate photographed and dropped in. That page carries no text layer, so it comes back empty while the rest of the document extracts perfectly. This is the case that used to pass in silence, because the emptiness was tested over the whole document and the typed pages satisfied it: the scanned page was reduced to a page marker with nothing under it, and to nothing at all once the markers were switched off. Emptiness is now measured page by page. On a four-page test file whose second page was an image, the extraction returned the other three pages and an amber line above them reading “1 page(s) carry no selectable text and came out empty: 2”; with pages 2 and 4 both images, the same line named “2, 4”. It is a warning, not a refusal — the text you did get is still yours. What it tells you is which pages need optical character recognition rather than a second attempt.

Frequently asked questions

Why does my two-column PDF come out as gibberish?

Because the left line and the right line are printed at the same height, and the reconstruction groups by height. It has no way to know that the page is divided into two reading zones — a PDF does not record that. So it reads straight across, joins the two fragments with a space, and moves down. Both layout modes do this; paragraph mode then compounds it by gluing the interleaved lines together. If you need clean text from a two-column document, extract one page at a time and separate the columns by hand, or find a version of the document that was never laid out in columns.

Can it read a scanned PDF, and does it do OCR?

No, and no. A scanned PDF contains an image of a page and no text objects at all, so there is nothing to extract; the tool returns nothing and tells you the file is most likely a scan with no text layer. Optical character recognition is a different operation — it looks at the pixels and guesses which letters they represent, which is why it can be wrong and why it needs to know what language it is reading. This tool does not do it, does not offer it, and does not silently attempt it. A quick way to tell before you upload: open the file in any reader and try to select a sentence. If the highlight does not follow the words, no extraction tool will help.

It said there is no text, but I can select text in my reader. Why?

Check the page range first. The box accepts anything and silently drops numbers the document does not have, so asking for page 99 of a ten-page file leaves nothing to extract — and the message you get says exactly that, naming how many pages the document really holds, rather than calling your file a scan. Clear the box and run it again. The other possibility is that the pages you selected are genuinely the scanned ones: a document can mix typed pages with a scanned insert, and if you asked only for that insert, there is nothing on it. Ask for the whole document instead. Every page carrying text is extracted, and the pages that came back empty are named in a warning above the result, so you can see which ones need optical character recognition.

Which layout mode should I choose?

Choose “Keep the lines” whenever the arrangement of the page carries meaning: tables, forms, invoices, anything with columns, and any document you intend to check line by line. Choose “Join into paragraphs” only for single-column running prose that you are about to paste into a document, where broken lines are a nuisance rather than information. Paragraph mode is the one that repairs hyphenated words, so it produces genuinely better prose — on the right kind of page. On the wrong kind it destroys the structure irreversibly, and you cannot get it back from the output; you have to run the extraction again.

Does it strip the header and footer that repeat on every page?

No. Every repeated element comes through once per page, and on a long document that is a lot of noise: a 44-page decree produced 44 copies of its header line and 44 page-number lines, sitting between the sentences they interrupt. Removing them reliably would mean recognising that a line is furniture rather than content, which is a judgement the tool does not make. The practical fix is a find-and-replace in a text editor after extraction: the header is an exact repeated string, so one replacement clears all of them. Do that before you count words or feed the text to anything else, because the repeated furniture will otherwise be counted as content.