We Checked 60 Academic Papers: 78% Break Words in Half

Updated August 18, 2026 · 6 min read

Everyone who reads papers on a phone has hit this. You select a word to look it up, and what comes back is half a word, or two words fused together, or a fragment with a hyphen stuck to it. It feels like a bug in the reader. It usually is not.

We wanted a number rather than an impression, so we measured it.

The numbers

The first row matters as much as the second. Every single paper had extractable text — arXiv is born-digital, typeset from LaTeX, never scanned. This is the best case. The text layer is not missing or broken; it is working exactly as designed, and it still hands you half a word.

Half the hyphens are innocent, and that matters

The obvious way to measure this is to count every hyphen sitting at the end of a line. That number is wrong, and wrong in the direction that flatters the finding.

A line-ending hyphen can be two different things. In well-known split across lines, the hyphen is part of the word; select it and you get something sensible. In compre-hension, the hyphen was inserted by the typesetter to make the line fit, and selecting it gives you a fragment that is not a word in any language.

So we checked each split against the system dictionary: it counts as a broken word only if joining the halves makes a real word and the first half is not one. The result was almost an even split.

Had we skipped this step and counted every line-end hyphen, we would have published a number roughly twice the size. It would have been quotable and it would have been wrong.

It happens everywhere, but not equally

The spread is explainable. Machine-learning papers are dense with long compound terms in narrow two-column layouts, which is the worst case for a line breaker. Number-theory papers are half equations, so there is simply less running prose to break. No field escaped it.

Why a PDF does this and a web page does not

A web page reflows. Change the window width and the text re-wraps, so a word is never committed to being in two places. A PDF is a description of ink on a fixed page: the line breaks were decided once, when the document was typeset, and baked in.

When LaTeX needs to justify a line and a long word will not fit, it hyphenates. The resulting file genuinely contains compre on one line and hension on the next, with no marker saying they were once one word. Any reader — ours, Adobe's, your browser's — is reading a document where that word is already in pieces.

What this means when you are reading

• Look-ups fail silently. A dictionary asked to define hension returns nothing, and you cannot tell whether the word is obscure or the selection was broken.
• Search misses real matches. Searching a paper for a term that happens to be hyphenated across a line will not find that occurrence.
• Copy-paste carries the damage. Quoting a passage into your notes brings the hyphen and the line break with it.
• It is worse away from arXiv. Every document here was born digital. A scanned PDF has no text layer at all, and OCR introduces its own errors on top.

The practical consequence for anyone building a reading tool is that you cannot trust the text layer to hand you a word. You have to repair it — rejoin what the typesetter split, and use the surrounding sentence rather than the selection alone.

Where this study is limited

• One corpus. Recent arXiv preprints. It describes academic PDFs, not every PDF. Journal typesetting, government forms and scanned books all behave differently.
• Twelve pages per paper, not whole documents, to keep the run polite to arXiv's servers. Counts are therefore per-sample, not per-paper-total.
• One extractor. We used `pypdf`. Different readers extract differently, and a viewer built on PDF.js will not produce byte-identical text. Hyphenation is a property of the page layout rather than the extractor, so it survives that difference — but the exact counts would shift.
• We dropped a metric. We also counted typographic ligatures, then discarded the result: `pypdf` normalises most of them back to plain letters, so the figure described our tooling rather than the documents.
• One snapshot, taken on 18 August 2026.

Check it yourself

The script and its raw output are published with this article, including the per-paper table and the arXiv identifiers, so the run can be repeated or argued with. It takes one dependency and a few minutes.

If you re-run it on a different corpus we would genuinely like to know what you find — particularly on journal PDFs, where the typesetting is tighter and we would expect the numbers to be worse.

Why we measured this

We are building FlowRead, a PDF reader that lets you select a passage and get a definition, translation or explanation over the page. This measurement is the problem sitting directly underneath that feature: if the selection hands us half a word, the answer is wrong before the model is even asked.

It is also the reason a reading tool should look at the sentence around your selection rather than the selection alone. FlowRead is coming to iOS and Android — join the waitlist — and the finding above holds regardless of which reader you use.

Claims about other products were checked against their own public documentation on August 18, 2026. Vendors change plans and privacy terms without notice — if you spot something out of date, tell us at support@getflowread.app and we will fix it.