Overleaf, LaTeX and Turnitin: What a Compiled PDF Can Change

Turnitin accepts PDF, but that does not reveal what its private extractor sees. In our reproducible fixture, mutool and PyMuPDF each returned 694 whitespace-delimited words from one two-column pdfTeX file; pypdf returned 692. The compile and the extractor both shaped the text stream. That is measurable. A Turnitin input or score effect is not.

That boundary is the whole article. The source, three PDFs, nine raw extraction streams and measurement script are retained with the evidence package; the five-minute check near the end is the version to run on your own paper.

One `.tex` file: the standard `article` class, `twocolumn`, 10pt. It contains an abstract, four numbered sections, inline and display maths, an `itemize` list, an `algorithm` environment with numbered pseudocode lines, a `table` float, a `figure` float with a caption written as a full sentence, one footnote long enough to wrap, and two `\cite` calls resolving to a numbered bibliography. The two-column builds produce two pages; the one-column control produces three.

Compiled with pdfTeX 3.141592653-2.6-1.40.26, TeX Live 2024. Read with three independent extractors: mutool 1.25.6, PyMuPDF 1.26.0, and pypdf 6.4.0.

After collapsing every whitespace run to one space, mutool and PyMuPDF each returned 694 words from the two-column pdfTeX PDF. Pypdf returned 692. The three streams preserve the same broad section order, but the two-word gap is enough to reject the convenient claim that independent extractors see an identical object.

The most repeated warning about submitting a two-column PDF is that the extractor reads straight across both columns and turns your paper into interleaved nonsense. It did not happen here. The last sentence of the abstract, at the foot of column one, arrives immediately before the first sentence of the Introduction, at the head of column two. The order is intact for the whole document.

One layout, one class, three extractors, one machine. That is the size of the claim. A journal's own `.cls` with an unusual float placement or a sidebar could behave differently, which is exactly why the check at the end of this article is worth five minutes on your actual file rather than on ours.

Something else broke instead, and it is much less discussed.

Here is a verbatim run from the PyMuPDF stream, with whitespace normalised and nothing between the quoted endpoints removed:

"…justification for treating a visually correct page as a reliable 1This footnote is deliberately long enough to wrap onto a second line so that its position in the extracted stream can be observed and compared with nearby prose. 1 Table 1: Primary outcome by condition. Condition Mean SD Control 12.4 3.1 Intervention 18.9 2.7 Figure 1: The framed area is a fixture rather than a reported empirical result. text stream…"

In the source, `reliable text stream` is one phrase. In this extraction, the footnote, a bare page number, the table caption and cells, and the figure caption all land between `reliable` and `text stream`. The footnote marker also attaches to the preceding punctuation elsewhere as `follows:1`.

The bare `1` in that quote is the page number. Put the page streams together and it sits between the footnote and the table, even though no reader sees it as part of either passage.

None of that is visible damage to the PDF. It is what this named local extractor returned, and it shows why "the sentence before" and "the sentence after" are not stable concepts until the extraction method is known.

LaTeX can hyphenate at line breaks, and a narrow column creates more opportunities. PyMuPDF found 22 split tokens in our two-column pdfTeX build. These are six of them:

ex- poses · differ- ences · specifica- tions · observa- tions · justifica- tion · partici- pants

Then we compiled the identical source as a single column and changed only the class option. PyMuPDF returned 678 normalized words and five split tokens instead of 22: `or- dinary`, `extrac- tion`, `jus- tification`, `partici- pants`, `par- ticular`.

Same source, one layout switch, and a different set of breaks. This is one fixture rather than a rule for every class file, but it is enough to justify checking the compiled file instead of assuming the source tokenisation survived.

We compiled the same source a third time with XeLaTeX, same two-column layout, same words on the page.

In the pdfLaTeX build, all three tools exposed zero tokens containing the ligature codepoints `ff`, `fi`, `fl`, `ffi` or `ffl`. In the XeLaTeX build, PyMuPDF and pypdf each exposed six: `affiliated`, `affiliation`, `difficult`, `efficiency`, `insufficient`, `office`. Mutool exposed zero because it normalised those glyphs back to ordinary letters. A naive search for `efficiency` therefore succeeds in one stream and misses in another.

The equation changed in the other direction. In the pdfTeX file, mutool returned a Unicode replacement character for the summation sign while PyMuPDF and pypdf returned a capital `X`. In the XeLaTeX file, all three exposed the actual `∑`. Both the compiler and the extractor mattered.

The Turnitin pages cited here do not identify its extractor or describe these transformations, and we are not claiming any of this moves a score. We are claiming something narrower and checkable: the text layer is a product of the compile, and different extractors can expose different characters from the same PDF.

Four passages from the vendor's own documentation bear directly on a paper shaped like this one. There is more on those pages; these are the four that touch a LaTeX submission.

The format is accepted. Turnitin's file requirements for an AI Writing Report list `.docx, .pdf, .txt, .rtf`. That proves a PDF can be processed; it says nothing about which extraction chain is used. Does Turnitin detect AI in a PDF works through the documented part of that question.

Only prose counts. The FAQ defines what gets analysed as qualifying text:

"This qualifying text includes only prose sentences, meaning that we only analyze blocks of text that are written in standard grammatical sentences and do not include other types of writing such as lists, bullet points (short non-sentence structures), or other non-sentence structures."

The next sentence is the one worth carrying: "This percentage is not necessarily the percentage of the entire submission." Your `itemize` bullets and your `algorithm` lines are not sentences. Neither is a row of table cells. How Turnitin handles maths equations and non-prose content covers what that means for a paper that is mostly formulae. Note what does count, though: a `\caption` written as a full grammatical sentence, which is how most people write captions, arrives in the stream looking exactly like body prose.

Bibliographies are excluded. A release note dated 9 August 2023 says a bug that highlighted AI writing inside references was fixed and "Bibliographies are now excluded when processing the AI writing report", with the same note adding that existing submissions have to be resubmitted before that applies to them. What the vendor does not publish is how a bibliography gets identified inside a flattened text stream, and our extraction gives no clue either: `References` arrives as an ordinary word, followed by `[1] J. Smith, "A study of things," Journal of Testing, vol. 4, no. 2, pp. 100–110, 2019.` with nothing marking the boundary. Do not build a plan on either reading of that. What the reference exclusions actually cover sets out what is documented and what is not.

Short papers behave differently. Once a document is down to a few hundred words, the vendor's own wording is that prediction becomes "mostly 'all or nothing' because we're predicting on a single segment without the opportunity to overlap", and its next sentence adds that mixed content there can be flagged as entirely AI-generated. A six-page conference paper that is half equations may not have much qualifying prose in it at all. Short documents and the all-or-nothing problem has the mechanism.

`\cite{smith2019,jones2020}` arrived in the extraction as the four characters `[1, 2]`. `\ref{sec:method}` arrived as `2`. `\label` left nothing behind at all. Section headings arrived as their number and title separated, so `2 Method` sits in the stream directly after the previous sentence, and the earlier cross-reference `Section 2 describes the method.` reads as prose containing a stray digit.

Which means every plan built on citation formatting is acting on something that is not there. There is no citation object in the extracted text, only brackets and digits, and Turnitin's published description of the calculation does not name a citation at any step of it. Why did Turnitin flag my references lists the specific edits that follows from, and why each of them has nothing to act on.

You do not need any of the tools we used. Open your compiled PDF in whatever viewer you have, select all, and paste into a plain text editor. That is one more extraction path, not a proxy for Turnitin, but it can reveal problems in the text layer you are actually submitting.

Read it for these, in this order:

1. Split words. Search for a hyphen followed by a line break. Every hit is a word that has stopped being one word.
2. Where your floats landed. Find a table caption and read the two sentences around it. If the caption and its cells have landed inside a paragraph, that is the reading order for that paragraph now.
3. Your captions. If a caption is a full grammatical sentence, it looks like prose, because it is prose.
4. The maths. Read one display equation in the pasted text. Whatever you see is what an extractor got. If characters are missing or wrong, that is a fact about your font embedding, not about your algebra.
5. The start of the bibliography. Look at whether anything in the plain text marks where the reference list begins. In ours, nothing did.
6. Your name and affiliation. They are in the text layer too, which matters if you are submitting anywhere that expects anonymity.

If you keep your `.tex` under Git or in Overleaf, do this once per major revision rather than once at the end. And on the separate question of whether the writing history in Overleaf is worth anything as a record, where version history lives in Word, Google Docs and Overleaf has the free-plan retention rules and what to do about them, which are more specific than most people expect.

For a LaTeX paper the answer is boring and correct: change the source, recompile, and never edit the PDF. The sentence lives in the `.tex` file. Everything else is a rendering of it.

The chain gets awkward when it ends somewhere other than a PDF. A supervisor may want track changes, a journal may require a Word manuscript, or someone may send back an AI writing report drawn on the compiled PDF and ask which passages will change. You now have the same paper in two formats.

For an English DOCX version, HumanPen can limit a rewrite to passages you select or passages matched from a Turnitin or iThenticate report. Humanize is currently English-only; it does not take `.tex` or a compiled PDF as the editable source. Confirm the paragraph-level scope, keep the LaTeX source as the master, and recheck the converted document after download. Eligible results can continue lowering AI for free.

Should I submit the `.tex` file instead of the PDF? Submit whatever the assignment or journal asks for. A `.tex` file is plain text with markup in it, and every command in it would arrive as literal characters, so it is not a cleaner version of your paper for any reader, human or otherwise.

Do my equations raise my AI score? They are not prose sentences, so by the vendor's own definition they are outside qualifying text. The explanatory sentences around them are inside it. On a paper that is mostly equations, that means the number is computed over a small slice of the pages.

Does the two-column format itself cause problems? Broad section order held in this fixture. Under PyMuPDF, the two-column build had 22 line-break splits and the one-column build had 5. That is a measured difference for this class file, not a rule for every journal template.

My institution wants a Word file and I write in LaTeX. Then you have a conversion step, and that step is where numbering, cross-references and citation fields are most likely to break. Convert once, late, and check the object types rather than reading the first two pages.

Can I use Overleaf's history to show how the paper was written? It is a record, not a verdict, and on the free plan most of it disappears after a day unless you label versions. The article linked above covers the exact rule and the labelling habit that fixes it.