Academic document checkers, the similarity scanners used by universities and journals to compare a submission against a corpus of prior work, do not read a PDF the way a person does. They extract the text layer first, then run pattern matching and n-gram comparison against the result. If that extraction is messy, the comparison is working from a distorted version of your paper, and the distortion runs in both directions: it can hide genuine overlap by breaking matching phrases apart, and it can flag innocent passages as suspicious by joining unrelated text together in ways that happen to resemble another source.
How similarity scanners actually read your submission
Most academic integrity tools work on shingles: overlapping sequences of a handful of words, typically five to eight, hashed and compared against an index of previously submitted or published text. A match on one shingle is a coincidence; a run of consecutive matching shingles is a flagged passage. This method is sensitive to exact wording, which means it is also sensitive to anything that changes the wording without changing the meaning, including artifacts left behind by PDF text extraction.
A citation that reads "climate models (Alvarez et al., 2019) consistently underestimate" in the source document but extracts as "climate models (Al- varez et al., 2019) consistently underestimate," with a stray hyphen and space where the name wrapped across a line, no longer matches the shingle index at that point. That specific five-word window fails to match, even though the sentence is identical. Multiply this by every line-wrapped sentence in a twenty-page paper and a scanner's coverage of your actual prose degrades quietly, without producing an error anyone notices.
Why broken line breaks distort matching
Hyphen splits break word boundaries
Justified academic typesetting hyphenates aggressively, since journal templates are optimized for print density rather than screen reading. Every hyphenated split is a word that, if left unrepaired, tokenizes as two fragments joined by a hyphen instead of one word. A shingle-based comparison built on five-word windows loses that entire window whenever one of its words is fractured this way. Rejoining the hyphen before submission restores the exact wording the scanner is trying to match against.
Merged headers corrupt section detection
Running heads (a repeated paper title or journal name at the top of every page) and folios (page numbers) get extracted as if they were body text, sitting between the last sentence of one page and the first sentence of the next. A scanner that is not specifically built to strip these artifacts sees a nonsense token sequence at every page boundary: the end of one sentence, a journal name, a page number, then the start of the next sentence. This does not usually trigger a false match, but it does waste the scanner's context window on noise and can occasionally break a legitimate quotation that happens to span a page boundary, so the checker under-detects a real citation issue instead of correctly identifying it as properly attributed.
A cleanup routine before you submit
The fix does not require rewriting anything. It requires extracting the text the same way the checker will, reading it, and repairing the artifacts before the file goes anywhere:
- Rejoin hyphenated words so that split terms and author names read as a single token again, matching the original wording exactly.
- Merge wrapped lines back into full sentences, so a shingle-based comparison sees continuous prose rather than fragments broken at arbitrary points.
- Drop running heads and page numbers so they stop interrupting the text at every page boundary.
- Read the cleaned output once, paying attention to quotations and citations specifically, since these are the passages a checker weighs most heavily.
Running your own paper through the text cleaner before submission gives you the same view of your document that a checker's extraction pipeline will have, entirely in your browser, without uploading the paper anywhere. The field guide covers the underlying extraction mechanics in more depth, including exactly how hyphen rejoining and line merging are decided.
What this doesn't fix
Cleaning up extraction artifacts addresses a mechanical problem, not an editorial one. It will not catch actual overlapping content, and it is not a substitute for proper citation. What it does is make sure a checker is comparing your real sentences against its index, rather than a garbled version of them, so any result you get, clean or flagged, reflects your writing rather than a PDF's line-wrapping decisions.