Document Forensics

A document forensics check reads what a file carries beyond its visible content: who the metadata says wrote it, which tool produced it, when its timestamps claim it changed, what earlier revisions, embedded files or invisible text still sit inside it. Drop a PDF, PNG or JPEG below and this page reports those facts locally, in your browser, each with the concrete values it was read from. Two limits up front: the file is never uploaded — it is parsed on this device and nowhere else — and this tool reports facts, not verdicts: structural evidence cannot prove who created a file, so there is no score and no authorship judgement here. The companion article, PDF metadata and hidden data, explains where each kind of data hides and how real leaks happened; the PDF Accessibility Checker covers a PDF’s reading structure, and the Binary Inspector covers executable files.

Last updated:

Or drop the file anywhere in this box. The file is read on this device and never uploaded. Limit: 20 MB.

Facts, not verdicts — what this page cannot tell you

Metadata is testimony, not proof. An Author field says what a program wrote into the file, and any of these values can be edited, copied from another document or left over from a template — so a familiar name in the metadata does not prove that person created this file, and an unfamiliar tool name does not prove anything about how the content was made. In particular, structural evidence cannot prove authorship, and this page makes no claim about whether any content was produced by a person or by software: it reports the values that are present, the revisions that survive, and the timestamps that disagree, and leaves the interpretation to you. Treat every finding as a lead to verify, not a conclusion.

What this tool reports

  • PDF information-dictionary fields — title, author, creator, producer and both dates — quoted verbatim as evidence.
  • The XMP metadata packet, when present, with its title, producer and create/modify dates extracted.
  • Incremental-update structure: how many %%EOF markers and startxref sections the file carries, and the depth of the /Prev trailer chain.
  • Embedded-file indicators, hidden text painted with rendering mode 3, and the encryption flag.
  • PNG chunk inventory with decoded text chunks and the tIME timestamp; JPEG segment inventory with JFIF, Exif and XMP fields and comment text — plus any bytes trailing after the end marker in either format.

What a document carries besides its content

Every document format in scope here is a container, not just a picture of content. A PDF carries an information dictionary — title, author, creator, producer and two dates — written by whatever application exported it, usually without the author of the document ever seeing it. Alongside it, most modern producers embed an XMP packet: an XML metadata block that may repeat the same fields, add a creator tool, or quietly disagree with the information dictionary. PNG images carry named chunks, some of which hold free text — software names, comments, copyright lines, sometimes whole XML documents — and JPEG photographs carry Exif blocks written by the camera: make, model, the date the shutter fired, and the software that last touched the file. None of this is visible when the document is opened normally, and all of it travels with the file when it is published, emailed or filed in court.

PDFs have a second, deeper layer: incremental updates. The PDF format was designed so an editor can save a change by appending a new revision to the end of the file instead of rewriting it, leaving the earlier bytes — including the earlier version of a paragraph — physically present and readable. A file with several %%EOF markers has been saved that way several times, and anything that was “deleted” in a later revision may still be recoverable from an earlier one. That mechanism is legitimate and useful for signatures and fast saves, but it is also why naive redaction fails: covering a paragraph with a black rectangle, or even deleting the text in an editor that then saves incrementally, can leave the original words in the file for anyone who looks. This page counts the end-of-file markers and the trailer chain so you can see whether the file in front of you has a past.

The same container logic explains the other checks. A PDF can carry embedded files — complete attachments stored inside the document, listed in its embedded-files name tree — which a reader may never notice but a recipient can extract. It can also carry hidden text: PDF text is painted with a rendering mode, and mode 3 paints nothing at all while leaving the characters in the content stream, copyable and searchable but invisible on the page — a classic place for text that was meant to be removed, and occasionally for text that was never meant to be seen. PNG and JPEG files have their own version of the same story: bytes appended after the end marker are ignored by every viewer yet remain in the file, and text chunks and comment segments routinely outlive the editing session that wrote them.

Timestamps are where documents contradict themselves. A PDF holds at least two dates in its information dictionary and often two more in its XMP packet, written by different tools at different moments — the exporter, the editor, the optimiser that recompressed it on upload. When the creation date sits after the modification date, when the XMP dates disagree with the information dictionary, or when a date falls in the future, something in the chain did not tell a consistent story: a clock was wrong, a field was edited, or the file was assembled from pieces with different histories. None of those explanations is automatically sinister, and this page does not choose between them — it shows both values side by side so the inconsistency is visible instead of buried. The same applies to a camera’s Exif date and a PNG’s last-modification chunk: a timestamp is a claim the file makes, and cross-checking claims is the whole of this tool.

Use the results before you publish, not after someone else does. Run internal reports, screenshots and photographs through a check like this one and read what would leak with them: author names and usernames, internal tool names, the original dates, the attachments you forgot, the revision that still holds the paragraph Legal removed. Scrubbing is then a deliberate step — re-export from the source with metadata stripped, flatten and rewrite the file completely rather than saving incrementally, and re-check the copy you actually ship. And keep the honesty limit in view throughout: a clean result means no structural surprises were found in the places this page looks; it does not certify a document’s origin, and a surprising result is a question to ask, not an accusation to make.

Frequently asked questions

Is my file uploaded anywhere?

No. The file is opened and parsed in this page, on your device, and nothing is uploaded, transmitted or stored. Analysing a file makes no network request, so the page works offline once loaded — which matters, because the documents most worth checking are exactly the ones you should not send to a stranger’s server.

Can this tool tell me who created a file, or whether AI made it?

No — and be wary of any tool that claims otherwise. Metadata fields are text a program wrote into the file; they can be edited, inherited from a template or copied from another document, so they are testimony, not proof. Structural evidence cannot establish authorship. This page reports the values that are present and the places where a file contradicts itself, and leaves authorship questions to evidence that can actually answer them.

What is an incremental update, and why does it matter?

PDF editors can save changes by appending a new revision instead of rewriting the file. Each save leaves an %%EOF marker, so several markers mean several appended revisions — and earlier revisions remain readable in the bytes, including content that later revisions appear to delete. That is why covering text with a rectangle or deleting it in an incremental save does not remove it from the file. A full rewrite or re-export is what actually drops the old bytes.

I found hidden text in a PDF. Does that mean someone cheated?

Not by itself. Text painted with rendering mode 3 is invisible but present, and there are legitimate reasons for it: OCR layers sit behind scanned page images so the page can be searched and copied, and some producers emit invisible text for indexing. It becomes a problem when the invisible text was supposed to be gone — a redacted name that is still copyable is a leak, whatever the intention was. Read the finding as “look here”, not as a verdict.

How do I remove this metadata before publishing?

Work at the source where you can: clear document properties in the authoring tool, export with metadata options off, and for PDFs prefer a full rewrite — printing to PDF or a dedicated scrubber — over an incremental save. For images, re-export through a tool that strips Exif and text chunks rather than editing them in place. Then run the scrubbed copy through this page again and confirm the findings you cared about are actually gone.