A PDF can tell you which program wrote the file. It cannot tell you who, or what, wrote the words. That is the whole of AI PDF detection in two sentences. Everything below is about reading the first fact carefully and not mistaking it for the second.
I built the AI detection tool on PDFCheck, so I know exactly what it looks at: two metadata fields. This guide shows how the score adds up, what ten common producer strings actually scored when I ran them through it, and the cases where the result is misleading.
The two fields that matter
Most PDFs carry metadata in two places. The document information dictionary holds fields such as Title, Author, Creator and Producer. XMP is a block of XML inside the file that can repeat those values and add document IDs. Adobe's metadata overview describes both.
Creator names the application the document was written in. Producer names the software that wrote the PDF bytes. A Word export says Microsoft Word in both. A file built by a Python script often says ReportLab PDF Library - www.reportlab.com. A file saved from Chrome says Skia/PDF.
Both fields are optional and trivially easy to set. A library such as pdf-lib exposes setCreator and setProducer as ordinary method calls, so a program can write anything it likes there, including "Microsoft Word".
Why some generators are linked to AI
When you ask a chatbot or an agent to make a PDF, it usually writes a short script, and that script reaches for a well-known library: ReportLab or WeasyPrint in Python, pdf-lib or PDFKit in JavaScript, or a browser driven by Puppeteer or Playwright. Each leaves its name in the metadata unless someone changes it.
The same libraries also run invoicing systems, bank statements and booking confirmations. A ReportLab fingerprint on a utility bill is normal. The same fingerprint on a cover letter the sender says they typed in Word is worth a question. So the useful question is never "was this AI?" It is "does this creation path fit what I was told about the file?"
How the score adds up
The detector reads Creator and Producer, preferring the XMP versions when present. It joins them, lowercases the text and looks for every name in its software catalogue as a plain substring. Catalogue entries with an AI association add points. Two further rules apply only after at least one point has been scored, and a few words add points regardless. The full method is on the how we detect page.
| Rule | Points | Names or words involved |
|---|---|---|
| High-association generator | 40 each | ReportLab, PyPDF, PyPDF2, pdfplumber, WeasyPrint, pdf-lib, PDFKit, Puppeteer, Playwright; also the words OpenAI, Anthropic, Claude, ChatGPT, GPT, Gemini, Bard, Copilot |
| Medium-association generator | 20 each | FPDF, FPDF2, jsPDF, Headless Chrome |
| Low-association generator | 10 each | pdfmake, wkhtmltopdf |
| Author field empty | 10 | Only when the score is already above zero |
| Title field empty | 5 | Only when the score is already above zero |
| Words in Creator or Producer | 5 or 10 | python 5, script 5, api 5, automated 10, generated 10 |
The total is capped at 100. A score of 0 is reported as No Indicators, 1 to 24 as Few Indicators, 25 to 49 as Some Indicators and 50 or more as Strong Indicators. From 25 upwards the file is counted as having AI-generator indicators, which also adds a warning to the screening checks and caps the full report's Document health number at 65.
Worked example: a producer that names ReportLab
Take a file whose Producer is ReportLab PDF Library - www.reportlab.com with Creator, Author and Title all empty. ReportLab matches at the high weight for 40. Because the score is now above zero, the empty Author adds 10 and the empty Title adds 5. Total: 55, Strong Indicators. The summary the tool returns reads:
Strong AI-generator indicators (risk score 55/100). Created using ReportLab, which AI assistants often use. This is not proof the content was written by AI.
Fill in an Author and a Title on the same file and it drops to 40, Some Indicators. Nothing about the content changed.
What ten common producers scored
On 12 October 2026 I ran typed-in creator and producer strings through the detector, once with an author and title present and once without. These are test inputs, not values read from files made by those products, but they show the shape of the scale.
| Creator / Producer text tested | With author and title | Without author and title |
|---|---|---|
| Microsoft Word / Microsoft: Print To PDF | 0, none | 0, none |
| Writer / LibreOffice 24.2 | 0, none | 0, none |
| LaTeX with hyperref / pdfTeX-1.40.25 | 0, none | 0, none |
| TCPDF 6.7.5 (http://www.tcpdf.org) | 0, none | 0, none |
| GPL Ghostscript 10.08.0 | 5, few | 5, few |
| FPDF 1.86 | 20, few | 35, some |
| wkhtmltopdf 0.12.6 / Qt 4.8.7 | 10, few | 25, some |
| WeasyPrint 61.2 | 40, some | 55, strong |
| pdf-lib (https://github.com/Hopding/pdf-lib) | 40, some | 55, strong |
| PyPDF2 | 80, strong | 95, strong |
Three rows deserve a note. Ghostscript scores 5 because "Ghostscript" contains "script", which is a quirk of substring matching and nothing more. PyPDF2 scores 80 before the empty-field bonus because PyPDF2 also contains pypdf, so two catalogue entries match. And a custom producer reading "Report generated by API" scored 15 from the words "generated" and "api" alone, with no library named at all.
Where the result misleads
False positives are common and boring. Invoicing platforms render bills with headless Chrome, reporting servers use ReportLab or WeasyPrint, and web apps assemble PDFs with pdf-lib. A test invoice with a HeadlessChrome creator, a Skia/PDF producer and a title but no author scored 30, enough to be counted as having indicators even though no language model came near it. Windows users printing to PDF through the PScript5.dll driver pick up points from the "script" inside the driver name.
False negatives are just as easy. Text written by an AI assistant, pasted into Word or Google Docs and exported carries the word processor's name and scores 0. Re-saving, compressing or printing the file to PDF replaces the original generator name. Metadata can be retyped in seconds. A score of 0 says the two fields hold no known clue; it says nothing about who wrote the words.
Detectors that read the writing itself are not a clean escape either. In the 2024 NIST GenAI pilot, performance varied widely from system to system: some generators slipped past most detectors and some detectors caught almost everything. Treat any single score, from any tool, as a lead.
What to do with a flagged file
- Check the exact file you received. Any re-save on your side overwrites the Producer value you wanted to inspect.
- Read the matched names, not just the number. The report always lists which catalogue entries matched, so you can see whether it was pdf-lib or the word "script".
- Compare the path with the story. A Word document that arrives as pdf-lib output needs an explanation. A system-generated invoice from ReportLab does not.
- Look outside the file. Earlier drafts, version history in the source system and the workflow the sender describes are stronger evidence than any metadata field. If the question is whether the file was altered after it was made, read how to check if a PDF has been edited.
- Read the writing yourself if that is the real question. Pull the text out with the text extractor; this detector does not attempt that job. The font checker can add a clue about the export path, but it has the same limit: it describes the file, not the author.
Without PDFCheck, Acrobat shows Creator and Producer under File > Properties, and Poppler's pdfinfo prints them in a terminal. You would just be doing the catalogue lookup in your head.
Ask how the document was produced before you decide anything, and never use a score alone for an academic, hiring or legal decision. If authenticity matters more than authorship, check a digital signature with the signature checker and confirm the document with the issuer through a channel you already trust.