I went back to Turnitin's file-requirements page this morning to re-check a sentence I had quoted somewhere. It was not there. Neither were the six others I had from the same page.
Not moved to an anchor further down. Not reworded around the edges. Gone, and the surrounding paragraphs rewritten into shorter sentences by someone doing a plain-language pass.
Here is the check, run against both the student-facing and instructor-facing copies of the page, because the two are near-identical (4,381 and 4,362 characters of article text today):
| String I had saved | Hits, student page | Hits, instructor page |
|---|---|---|
nearly universally available in word processing software |
0 | 0 |
Neither file type will support images or non-text data |
0 | 0 |
rename their file with a name other than that of the original file |
0 | 0 |
files created with software other than Adobe Acrobat |
0 | 0 |
Text with visual effects is not supported |
0 | 0 |
must be submitted through a web browser |
0 | 0 |
25 words / 40MB (an iOS submission path with its own limits) |
0 | 0 |
Similarity Report (control — known present)
|
2 | 2 |
The control row is the only reason the rest of the table means anything. A counter that returns zero for everything is indistinguishable from a broken counter, and the difference matters here because those are all negative claims.
One of the seven is a substantive rule and not just phrasing. The old PDF sentence excluded files created with software other than Adobe Acrobat. Today the exclusion list stops at multiple embedded files, and what used to be a hard rule now reads as a recommendation: Turnitin recommends making your PDF using Adobe Acrobat or Microsoft Word 365. Same topic, different force.
Even the blacklist bullet moved: it used to be Password protected files and today it is Password-protected files. If you are string-matching vendor docs in a pipeline, there is your reminder.
So: everything below is what the page says on 15 September 2026, and I would not assume it survives the quarter.
Two rule sets, and the assignment picks which one you are under
This is the part that explains most "why did my upload fail" questions, and almost nobody checks it first.
"If an assignment is set to allow any file type, Turnitin will accept any file that: is less than 100MB / is less than 800 pages"
"If an assignment is set to allow only files that Turnitin can check for similarity, Turnitin will only accept files that can generate Similarity Reports. This includes: files less than 100MB, files with a minimum of 20 words, file less than 800 pages"
(The file less than 800 pages typo is theirs, verbatim.)
The bar is set by the assignment configuration, not by your file. A 40MB Apple Pages document passes the size check and fails the second rule set. The error you see does not tell you which mode you are in, and you cannot see the setting.
The accept list: 11 entries
In similarity mode, the formats that can produce a report, exactly as listed:
Microsoft Word (.doc and .docx) · Corel WordPerfect · HTML · Adobe PostScript · Plain text (.txt) · Rich Text Format (.rtf) · Portable Document Format (.pdf) · OpenOffice (.odt) · Hangul (.hwp and .hwpx) · PowerPoint (.pptx) · Google Docs via Google Drive
And the escape hatch, which is one of the few quotes that survived the rewrite word for word:
"If you are using an unsupported word processor, you may need to save your plain text file as .txt or .rtf in order to upload to Turnitin."
The reject list: 8 entries
"Turnitin will not accept the following to generate Similarity Reports: Password-protected files / Microsoft Works (.wps) files / Microsoft Word 2007 macros-enabled .docm files / OpenOffice Text (.odt) files created and downloaded from Google Docs online / Document (.doc) files created using OpenOffice, as they are not 100% Microsoft Word equivalent / Apple Pages / Spreadsheets created outside of Microsoft Excel (e.g., .ods) / Text with visual effects"
Read rows four and five together, because they are the interesting ones: the producer matters, not just the extension. A .doc written by OpenOffice and a .doc written by Word are the same four characters and are not treated the same, and an .odt is on the accept list unless it came out of Google Docs, in which case it is on this one. Extension-based validation cannot express either rule.
Two more that catch people every single term: Apple Pages, because macOS hands you .pages without ceremony, and password-protected files, because a password is not a corruption and nothing about the upload looks wrong.
PDFs: the extension is not the check
"Turnitin will not accept PDF image files, forms, portfolios, files that do not contain highlightable text (e.g., scanned documents that are images), or documents containing multiple embedded files."
And the diagnostic, which is a text-layer test written for people who have never heard the phrase "text layer":
"To determine whether a PDF contains actual text, copy and paste a section of the content into a plain-text editor such as Microsoft Notepad or Apple TextEdit. If no text appears, the file does not contain selectable text and will not be accepted."
Thirty seconds, no tooling, and it is exactly the right test. A scanned page is a picture of words.
Slides and spreadsheets both get flattened
"Turnitin changes the PowerPoint into a static PDF. It keeps your text and images but removes presenter notes, videos, and animations."
Note what that implies: the text in your speaker notes is not in the document that gets checked, and neither is anything that only exists as an animation state. Also worth knowing if you are wiring up an LMS: The .ppt extension does not work with integrations. Use .pptx instead. The page lists the channels that do accept PowerPoint — Turnitin.com, Turnitinuk.com, LTI tools, the Moodle Plagiarism Plugin, Moodle Direct V2 and D2L V2.
Excel behaves like printing:
"The version of the file shown in the Document Viewer will look the same as if you had saved the Excel file as a PDF and submitted it to Turnitin."
The page is explicit about the consequence too. Content outside the print area can prevent .xlsx files from generating properly and may result in a failed submission. Set your print area before you upload, or the columns nobody configured simply are not in the submission.
The debugging order
When an upload fails or a report comes back empty, work down this list before you blame the network:
- Which rule set is this assignment under? If you cannot tell, ask. It changes everything downstream.
- Is the producer of the file on the reject list? Not the extension. The program that wrote it.
- If it is a PDF, do the copy-paste test. Takes half a minute and settles it.
- Is there a password on it? This one fails quietly.
- On macOS, are you certain that is not a
.pages? - Slides or spreadsheet? Check what survives the flattening: notes and animations do not, off-print-area cells do not.
One last thing, and it is the reason I wrote the top half of this post rather than just the bottom half: if you are going to rely on a sentence from a vendor's help centre, screenshot it with the URL and the date visible. I lost seven this morning and only noticed because I went back to check.
I keep a longer format map on my own site at humanpen.net/blog/turnitin-supported-file-types — and in the spirit of the above, it still quotes the pre-rewrite wording. Same failure mode, on my own page, which is roughly the point.
Top comments (0)