The symptom
Copy a paragraph out of a PDF and paste it somewhere else, and it comes back looking like this:
The quarterly report shows continued growth in the
enterprise segment, though margins remain under
pressure from rising infrastructure costs. The team
expects this trend to continue into next quarter.Every line ends where the PDF happened to wrap it on the page, not where a sentence or a thought actually ends. Paste that into a chat message, a text editor with word wrap turned off, or a plain form field, and it reads as four short choppy lines instead of the two flowing sentences it actually is.
Why this happens
A PDF doesn’t store paragraphs the way a word processor does. It stores a fixed layout: this run of characters goes at this position on the page, that run goes on the line below it. When you select and copy text, most PDF viewers copy it line by line, inserting a line break at the end of every visual line — because as far as the file format is concerned, that’s genuinely where one line ends and the next begins. The paragraph structure your eye sees on the page was never encoded as “these lines belong together.” It’s an accident of where the page happens to end a line at the document’s original width, and that accident survives the copy.
The same failure mode shows up outside PDFs, too. Old plain-text emails hard-wrap at 72 or 80 columns instead of relying on the reading application to wrap for them. Terminal output piped into a file often does the same. Text extracted from scanned documents via OCR inherits whatever line structure the OCR engine detected on the page image, which is usually the same per-line breaks a PDF would produce. In every one of these cases, the underlying problem and the fix are identical: a line break that meant “the page ran out of room here” is being read as if it meant “the sentence ends here.”
Why “remove every line break” isn’t the fix
The obvious fix — strip out every line break — solves the choppiness but creates a worse problem on a multi-paragraph document. Every paragraph break was also encoded as a line break (usually two in a row, or one plus a blank line), so removing all of them indiscriminately joins the entire document into a single unbroken wall of text, with no way to tell where one paragraph ended and the next began. You’ve traded one visible problem for a less visible, harder-to-notice one: a reader can tell instantly that four choppy lines should be one paragraph, but a 400-word paragraph that used to be four separate ones doesn’t announce that anything is wrong. It just reads badly, in a way that’s easy to blame on the writing rather than on the copy-paste.
The actual fix: paragraph-aware joining
The fix that works: treat a single line break as a mid-paragraph wrap and join it with a space, but treat a line break followed by a blank line as a real paragraph boundary and leave it alone. Applied to the example above:
The quarterly report shows continued growth in the enterprise segment, though margins remain
under pressure from rising infrastructure costs. The team expects this trend to continue into
next quarter.One paragraph, flowing normally, exactly as it would have read on the page. If the source had multiple paragraphs separated by blank lines, those breaks survive untouched, because the rule only fires on a lone line break, never on one that’s already followed by a blank line.
This is different from “reflow” or “rewrap” the way a word processor does it when you resize a window. There’s no need to know the original font, page width, or margins, because the fix isn’t about producing a new line width — it’s about removing a line break that was never meaningful in the first place, while keeping the one that was. The output isn’t wrapped to any particular column count at all; it’s just one logical line per paragraph, left to wrap naturally wherever it’s pasted next.
How to tell before you even try to fix it
The tell is usually visible before you run anything: line lengths that are suspiciously uniform, all landing somewhere between roughly 60 and 100 characters, with a sentence’s punctuation falling mid-line as often as at the end of one. Real intentional line breaks — the ends of items in a list, the lines of a poem, a code block — tend to vary a lot in length, because they’re determined by content, not by a fixed page width. A document where nearly every line is close to the same length and few lines end on a period is a strong signal that what you’re looking at is page-wrapped text pretending to be paragraph structure.
Doing it without breaking anything else
The text cleaner’s “Remove line breaks” step has this paragraph-aware behavior on by default — paste the ragged text in, and it comes back as normal paragraphs with blank-line breaks intact. If the source also has other problems — duplicate boilerplate lines from a page-footer that got copied on every page, for instance — stack “Remove duplicate lines” before it in the same pipeline. Steps run in the order you place them, and cleaning up line-level noise before rejoining the paragraphs tends to give a cleaner result than doing it the other way around, since a stray repeated footer line is far easier to spot and remove while it’s still its own line than after it’s been merged into the middle of a paragraph.
Once the text reads as normal prose again, it’s also back in a shape any of the site’s other tools can use meaningfully — a reading time or speaking time estimate, for instance, only means something once the artificial line breaks are gone and the word count reflects real sentences rather than fragments.
One thing worth checking by eye afterward
Hyphenated words that were split across a line break in the original PDF (“infra-\nstructure”) will rejoin as “infra- structure” rather than “infrastructure,” since the hyphen was part of the original word-break, not punctuation to be stripped automatically. This is common enough to be worth a quick visual scan of the result, but rare enough that it’s usually faster to fix by eye than to try to catch automatically. An automatic “un-hyphenate” pass would just as often wrongly join a legitimately hyphenated compound word — “up-to-date” or “twenty-two” — that never should have had its hyphen removed, and a tool that guesses wrong silently is worse than one that leaves a small, visible fix for a human to make.