This is the single most consequential fork in PDF forensics, and almost nobody outside the format knows it exists. The same visible edit — a changed total, a covered name — leaves a complete audit trail under one save mode and almost nothing under the other. Neither mode is suspicious. Both are what ordinary software does every day.
Incremental update: append the change, keep the original
PDF was designed so a file can be modified without being rewritten.
The editor leaves every existing byte where it is, appends the objects
that changed, and writes a new cross-reference table at the end
pointing back at the previous one with /Prev. The result
is one file containing two documents: the original, intact, followed
by the delta that supersedes part of it.
A reader opens it and sees the newest version, because the last cross-reference table wins. A parser that walks backwards sees both. The earlier version is not damaged, hidden or encrypted — it is simply further up the file.
What the tail of an incrementally updated file looks like
…original document, byte for byte…
%%EOF ← the file "ended" here once
6 0 obj ← the appended change
<< /Length 84 >>
stream … endstream
endobj
xref ← a second cross-reference table
trailer
<< /Prev 1024 … >> ← pointing back at the first one
startxref
14394
%%EOFThis is the mode a digital signature depends on. A signature covers a byte range; appending after that range leaves the signed bytes untouched and independently verifiable, which is how a signed document can later be countersigned, stamped or annotated without voiding the first signature.
Full rewrite: one pass, no history
The other mode writes a new file from scratch. The tool parses the
document into memory, then serialises it out: fresh object numbers,
one cross-reference table, no /Prev, nothing appended.
What comes out is a file with no past — not because anything was
erased, but because nothing was carried over.
Ghostscript does this. So does qpdf --linearize, most
"compress PDF" services, every print-to-PDF driver, and the export
path of most design tools. It is the normal way to produce a PDF from
something that was not already a PDF.
Side by side
| Incremental update | Full rewrite | |
|---|---|---|
| Earlier version of the page | Still in the file, recoverable | Gone |
| Cross-reference tables | One per save, chained by /Prev |
Exactly one |
| Object numbers | Original numbering preserved; changed objects reused | Renumbered from scratch |
| Existing digital signature | Survives, and still covers what it signed | Destroyed — the signed bytes no longer exist |
| File size after an edit | Grows | Often shrinks |
| Typical producers | Acrobat's Save, form fills, signing and stamping tools | Ghostscript, qpdf, print-to-PDF, compressors, design exports |
| What it tells a reviewer | What changed, and what it used to say | That the file was written once, by this tool |
The difference, measured
We built 1,006 forgeries from genuine documents by applying known edits, every source scoring low beforehand so a false positive could not be mistaken for a catch, then ran the engine over all of them. The save mode dominates the result:
| How the forgery was saved | Caught |
|---|---|
| Edited and saved as an incremental update | 100% |
| Composited through a Form XObject | 89.4% |
Edited, then rewritten by qpdf | 71.1% |
| Edited, then re-distilled by Ghostscript | 65.5% |
A forgery that was appended is caught every time. Push the same forgery through a whole-file rewrite and roughly a third of the evidence is gone — not because the rewrite hid anything deliberately, but because the traces lived in structure the rewrite did not carry over. What survives a rewrite best is covered text, because the covering shape and the text under it are both page content and get serialised together.
Measured on engine 1.23.0, against the eight edit operations we thought of. It is a recall figure for known forgery shapes, not a claim about forgeries nobody has invented yet.
Neither mode is evidence of anything on its own
A rewritten PDF is not a laundered PDF, and a multi-revision PDF is not a tampered one. This is the mistake the distinction most often produces, and it runs in both directions.
Every PDF that began life as something else — a Word document, a web page, a spreadsheet, a scan — arrives as a full rewrite. That is simply how it was made. Treating "one revision, renumbered objects" as concealment would flag most of the documents on the internet.
And an incremental update is what signing produces, what filling in a form produces, what a payroll system's stamping step produces. In a sample of published Brazilian public contracts, the country's signature infrastructure produced multi-revision documents by design. The count means nothing; what a revision changed is the question, and the revision history tool answers exactly that.
Telling which one you are holding
Count the cross-reference tables. One means the file was written in a
single pass; more than one means it was appended to, once per extra
table. You can see this without any tool by searching a PDF for
%%EOF — a file with three of them has been saved three
times.
Drop a PDF into the revision history and it will draw the chain: how many saves, which objects each one replaced, and whether the change touched what the page displays. If the answer is one revision, the page says so plainly rather than leaving you to wonder whether it found nothing or checked nothing.
Related
- The signal families field guide — every structural signal the engine reports, with the benign cause of each.
- How to detect an edited PDF — the practical version, with and without tooling.
- What a producer string means — which tool wrote the file, and whether it created the document or consumed one that already existed.
- Everything Tamperlens detects, and exactly what defeats each one — the whole matrix, including the operations above.