Why does text copied from a PDF break onto every line?

A PDF has no paragraphs to copy

The reason pasted PDF text arrives shattered is structural, and knowing it explains why no PDF reader fixes the problem properly.

A PDF describes a page as a set of drawing instructions: place this glyph at these coordinates in this font at this size. It is a description of appearance, closer to a vector drawing than to a document. There is no paragraph object, no sentence, and frequently no explicit space character — a space is often just the next glyph being positioned further along.

So when a viewer copies text it is performing a reconstruction. It sorts glyphs by position, decides which ones form a line based on their vertical alignment, and decides where words break based on horizontal gaps. That reconstruction is a heuristic, and it produces a newline at the end of every visual line because that is genuinely all the structure available.

This is also why the other artefacts appear. Hyphenated words split across lines come through with the hyphen intact, because the hyphen is a real character on the page. Text in two columns interleaves if the reader sorts by vertical position across the full page width. Headers, footers and page numbers arrive inline, since nothing marks them as different from body text. Ligatures — the single glyphs used for pairs like fi and fl — sometimes copy as one character that a later search for the two-letter spelling will not match.

Tagged PDFs, which carry an accessibility structure describing headings, paragraphs and reading order, do much better. They are the exception rather than the rule, and a document produced by scanning or by an older tool has no tags at all.

Rejoining lines without destroying the real ones

The obvious fix — remove every line break — is wrong, because some of those breaks are meaningful. Paragraph boundaries, list items and headings are all real structure that a blanket removal destroys.

The distinction that works most of the time is that a break inside a paragraph follows a line that ran to full width, while a break between paragraphs follows a short line. So the rule is to join a line to the next when it does not appear to end a sentence and reaches near the typical line length, and to keep the break when the line is noticeably short or ends in terminal punctuation.

Blank lines are a stronger signal and should be preserved outright. Where a document separates paragraphs with an empty line, collapsing only the single breaks within blocks and leaving the doubles intact reconstructs the structure almost perfectly.

Hyphenation needs handling before joining, not after. A word split as "informa-" and "tion" should rejoin with the hyphen removed, while a genuinely hyphenated compound broken at its hyphen should keep it. There is no reliable automatic rule, which is why the practical approach is to remove hyphens at line ends and then check the result — the errors are few and obvious.

List items and headings are the cases to inspect manually. Any automatic rejoining will fold a short heading into the paragraph beneath it, because a heading looks exactly like a short line ending a paragraph. Where a document is heavily structured, it is faster to paste, rejoin and then restore the headings than to attempt a rule that handles them.

The characters that survive the paste

Once the line breaks are sorted, a second class of problem remains, and this one is invisible.

Non-breaking spaces are the most common. They look identical to ordinary spaces and are a different character, so a search for a phrase containing one fails against a version typed normally, and code that splits on a space does not split there. Documents produced by word processors are full of them.

Typographic punctuation is the next. Curly quotation marks, en and em dashes, and ellipsis characters all differ from their typewriter equivalents, which matters whenever the text will be used as data — a name containing a curly apostrophe will not match the same name typed with a straight one. Whether to normalise them depends on the destination: keep them for prose, flatten them for anything that will be compared or searched.

Soft hyphens are worse than either, because they render as nothing at all unless a line happens to break there. A word can contain one invisibly, and it will fail every comparison while appearing correct on screen.

Then there are the direction and formatting marks — zero-width spaces, byte order marks and bidirectional overrides — which occasionally arrive from PDFs generated by unusual pipelines. All of them are invisible and all of them break exact matching.

The practical approach is to normalise deliberately rather than to hunt for individual characters: collapse all whitespace variants to ordinary spaces, decide once whether to keep typographic punctuation, and strip zero-width characters entirely. Doing it as a step rather than reactively avoids the situation where three of the four problems are fixed and the fourth surfaces a week later.

Sorting, deduplicating and checking the result

Text extracted from a document is frequently a list rather than prose — email addresses, references, part numbers, names — and lists have their own cleanup.

Deduplication is the first step and the one with a hidden trap: whether two entries are duplicates depends on how the comparison treats case, surrounding whitespace and those invisible characters. Two lines that look identical will survive a naive deduplication if one carries a trailing space or a non-breaking space. Trim and normalise before deduplicating, not after, or the operation silently does nothing.

Sorting has the same sensitivity plus one of its own. A plain sort orders by character code, which puts all uppercase letters before all lowercase ones and places digits before letters. That is rarely what anybody wants from a list of names, and the fix is a case-insensitive or locale-aware comparison. Numbers embedded in text sort as text too, so item 10 sorts before item 2 unless the sort understands numeric segments.

Finally, count the result and compare it to what you expected. Extraction from a document is lossy in ways that are easy to miss — a column dropped, a page skipped, entries merged where a line break was removed too eagerly. A count that disagrees with the source by a few percent is the cheapest possible detection of a problem that is otherwise invisible until someone relies on the data.

Where a layout needs testing before the real content exists, placeholder text is the right filler precisely because it is obviously not real. Using realistic-looking draft content risks it shipping unnoticed, which is a well-documented way for nonsense to reach production.

Questions