Why text copied out of a PDF comes out wrong

Copy a paragraph out of a PDF and paste it somewhere, and the result can be anything from perfect to unrecognisable. Words run together. Sentences arrive from two different columns interleaved. Every "fi" has become a square. Sometimes nothing comes out at all.

Each one is a specific consequence of how PDF stores text, and once you can recognise which failure you're looking at, the fix is usually straightforward.

The root of it: PDFs don't contain sentences

A word processor document stores a paragraph as a paragraph: a run of text with structure around it. A PDF stores something much closer to instructions for a printing press. Put this glyph at this coordinate. Put that glyph 4.3 points to the right of it. Move down 14 points and start again.

Nothing in the file necessarily says which glyphs form a word, which lines form a paragraph, or what order a human should read them in. When you select text, your reader is reconstructing all of that from positions, using heuristics: reasonable guesses that work well on ordinary documents and fall over on unusual ones. Every extraction failure below is a guess that went wrong, or information that was never in the file to begin with.

Nothing comes out at all

The page is a picture: a scan, or a photograph of a document, holding pixels your eye reads as letters rather than any text. There are no glyph instructions to extract because none were ever written.

The giveaway is that you couldn't select the text in your reader either; dragging across the page highlights a rectangular region rather than following the words. The fix is OCR, which recognises the shapes in the image and adds a real text layer behind it. Afterwards the document behaves like any other, though OCR introduces its own small error rate, so proofread anything where accuracy matters.

The words are right but the order is wrong

Classic on academic papers, newsletters and anything in columns. You get the first line of column one, then the first line of column two, then the second line of column one: a document read across the page instead of down it.

This is the reading-order problem, and it happens because the file records where each piece of text sits, not the sequence a human should follow. Extraction generally proceeds top-to-bottom, and on a two-column layout top-to-bottom crosses both columns. Well-made PDFs can include structural tagging that states the intended order explicitly, but most PDFs in the world aren't tagged.

Sidebars, pull quotes, headers, footers and figure captions cause the same trouble in a smaller way, arriving in the middle of a sentence they interrupt on the page. For a document with a simple layout, converting to Markdown gives a better result than raw extraction, because it rejoins paragraphs and preserves headings. For heavily columned documents, extracting one column's worth of page region at a time is tedious but reliable.

The spaces are missing or in odd places

Thequickbrownfox, or the opposite, T h e q u i c k. Both come from the same cause.

PDF has no obligation to store space characters. A space is often just a gap. The next glyph is positioned a bit further right, and nothing records why. Extraction has to infer a space from the size of the gap, comparing it against the font's expected character widths. Get the threshold slightly wrong and you either miss spaces between words or invent them between letters.

Justified text makes this markedly worse, because justification works by stretching the spaces to make each line reach the margin, so the gap that means "space" varies line by line. Letter-spaced headings and logos are the other common trigger. There is no fix at the file level, because this is information the document doesn't contain, so it's a matter of cleaning up afterwards, and a find-and-replace pass handles most of it.

Ligatures, quotes and accents turn into rubbish

"fi" becomes a box or vanishes. Curly quotes become question marks. Accented letters arrive as pairs of unrelated symbols.

Fonts identify their glyphs by internal numbers that need not correspond to any standard character code. To make text extractable, a PDF should include a mapping from those numbers back to real characters. It's called a ToUnicode map, and it is optional: plenty of producing software omits it, or writes an incomplete one.

Without it, extraction falls back on guesswork, and typographic niceties are where guessing fails first. Ligatures are the classic case: many fonts draw "fi" as one glyph, and if the map doesn't say that glyph means two letters, out comes something that isn't either. LaTeX documents, professionally typeset books and older files are the usual sources.

If a document consistently mangles the same characters, that's the signature of a missing or broken map. A find-and-replace fixes it quickly once you've identified the pattern. Where the text is badly damaged, an unexpected but effective route is to render the pages to images and OCR them: ignoring the broken text layer entirely and reading the page as a human would.

Tables become a wall of text

A PDF has no concept of a table. What looks like one is text at coordinates, sometimes with lines drawn around it, with no record of rows, columns or cells. Extraction produces the text without the grid, and any structure you get back has been inferred from alignment.

Simple, clearly-ruled tables often survive well enough to be usable. Anything with merged cells, multi-line entries or nested headers generally doesn't. PDF to Excel is aimed specifically at this problem and does better than plain extraction, but always check the output against the original, because a misaligned column in a spreadsheet is worse than obviously broken text, because it looks correct.

Choosing the right output

Much extraction disappointment comes from asking for plain text when something richer would have served better. Plain text discards every clue about structure, which is fine if you only want the words and wasteful if the document had headings worth keeping.

• Plain text, when you want the words and nothing else: word counts, search indexes, feeding a script.
• Markdown, when structure matters. Headings and lists survive as structure, and paragraphs are rejoined. The best default for notes, wikis and model input.
• Word, when you need to edit and keep formatting.
• Excel or CSV, when the content is tabular.

All of these run on your own device, which matters for this task in particular: contracts, papers and records are often documents you are not free to upload to a conversion site.