PDF Incremental Updates Explained

When you save a PDF after editing, the writer can either rewrite the whole file or append a small update at the end. The second option, called an incremental update, is faster, preserves history, and is essential for digital signatures. Understanding incremental updates illuminates a lot of PDF behavior that otherwise looks like magic.

What an incremental update is

A PDF file structure (see PDF internals: objects and streams):

[header]
[body]
[xref]
[trailer]

After an edit, an incremental update appends:

[header]
[body]            <- original
[xref]
[trailer]
[body 2]          <- the new or modified objects
[xref 2]
[trailer 2]

The new trailer has a /Prev pointer to the old xref. A reader starts at the last trailer, reads the latest xref, and reuses references to older content for objects unchanged.

Why it matters

Three reasons incremental updates exist:

Speed. Saving a 1,000-page PDF after annotating one paragraph: writing 30 KB of new content beats rewriting 200 MB.
Signatures. A signed PDF's signature covers specific bytes. If you rewrite the file, the byte positions change and the signature breaks. Incremental updates keep the original bytes intact and add new content at the end.
History. The original file is preserved inside; tools can show the change history.

The mechanics

After incremental update, a PDF looks like:

%PDF-1.7
1 0 obj
<<
  /Type /Catalog
  /Pages 2 0 R
>>
endobj

2 0 obj
<<
  /Type /Pages
  /Kids [3 0 R]
  /Count 1
>>
endobj

3 0 obj
<<
  /Type /Page
  /Contents 4 0 R
  /Parent 2 0 R
  /MediaBox [0 0 612 792]
>>
endobj

4 0 obj
<<
  /Length 50
>>
stream
... original page content ...
endstream
endobj

xref
0 5
0000000000 65535 f
0000000015 00000 n
...

trailer
<<
  /Size 5
  /Root 1 0 R
>>
startxref
500
%%EOF

5 0 obj      <- new annotation, added incrementally
<<
  /Type /Annot
  /Subtype /Highlight
  /Rect [100 700 300 720]
>>
endobj

3 1 obj      <- modified page (generation 1)
<<
  /Type /Page
  /Contents 4 0 R
  /Parent 2 0 R
  /MediaBox [0 0 612 792]
  /Annots [5 0 R]
>>
endobj

xref
0 1
0000000000 65535 f
3 1
0000001000 00001 n
5 1
0000001100 00000 n

trailer
<<
  /Size 6
  /Root 1 0 R
  /Prev 500
>>
startxref
1200
%%EOF

The original objects remain at their original byte positions. New objects (and modified versions of old objects, with new generation numbers) come after.

Modern PDFs typically use cross-reference streams instead of plain xref tables, but the principle is identical.

Reader behavior

A reader processes incremental updates as follows:

Read the last trailer (the most recent one).
Walk the most recent xref for object positions.
If an object is missing from the recent xref, walk back via /Prev to the previous xref.
The "latest" version of each object is what the user sees.

Tools that use incremental updates

Adobe Acrobat: by default, "Save" performs an incremental update; "Save As" rewrites.
PDF.js, Foxit, PDF-XChange: usually rewrite by default on Save.
Form fillers: typically incremental.
Digital signature tools: must use incremental to preserve byte positions.

For users, the visible effect: an Acrobat-saved PDF often has multiple "versions" inside, growing the file slightly with each save.

Linearization

A separate but related concept: linearization (also called "Fast Web View"). A linearized PDF reorders content so the first page can render before the rest of the file downloads.

Linearization is incompatible with incremental updates: each save would re-linearize the entire file. Most PDFs you sign or edit are not linearized.

For more, see linearized PDF fast web view.

File-size growth

Repeated saves grow the PDF. A modest PDF that's been saved 50 times can be much larger than its content needs. To "compact":

Acrobat: File > Save As > Optimized PDF. Rewrites without history.
qpdf: qpdf --linearize input.pdf output.pdf (or --no-warn --object-streams=generate input.pdf output.pdf).
Ghostscript: re-rendering effectively rebuilds.

Caveat: rewriting destroys incremental history; previous signatures become invalid.

Signature interaction

For signed PDFs, this is the core constraint:

The signature's /ByteRange references specific bytes.
Incremental updates append after those bytes; the signed content is untouched.
The signature remains valid.

If a user "Saves As" a signed PDF, the file is rewritten; the signed bytes move; the signature breaks.

For multi-signature workflows (signer 1, then signer 2), each signature is an incremental update:

File state after signing 1: original content + signature 1.
File state after signing 2: original content + signature 1 + signature 2.
Both signatures verify; each covers progressively more of the file.

See digital signature internals deep dive.

Form filling

Form fields are usually filled with incremental updates:

Each field value change appends an updated form-field dictionary.
The original "blank" form is preserved inside.
The visible state is the latest.

For deeper form internals, see PDF form field types explained.

Annotations

Adding a highlight, sticky note, or drawing is typically an incremental update:

The annotation object is appended.
The page's /Annots array is replaced (a new version of the page object is written).
Older versions persist inside the file.

For users: annotating doesn't change the original page content; it adds a layer.

Detection

Tools to spot incremental updates:

qpdf --json-output input.pdf: shows the file structure including multiple xrefs.
pdfinfo: reports PDF version, sometimes notes multiple xrefs.
Open in a text editor: search for %%EOF. More than one means incremental updates.

Forensically interesting: counting and inspecting prior versions can reveal what changed when.

Recovering older versions

The original content is still inside an incrementally-updated PDF:

Strip the latest update: remove everything after the original %%EOF. With careful editing, you can recover the original.
Tools: forensic tools (qpdf, mutool) can do this systematically.

This recovery can expose information you thought you'd hidden:

A redacted version (the redactions added incrementally; the underlying text still there).
An edited document (the original wording inside, replaced version on top).
Filled forms (the form-creation time content inside).

For PDF authors who care about cleanliness: rewrite (don't incremental-update) before publishing sensitive content. See PDF redaction failures and how to avoid them.

Common gotchas

Signature broken by Save As. Always Save (not Save As) signed PDFs.

Bloated file size. Many incremental updates accumulate. Periodically rewrite (Optimize PDF in Acrobat).

Hidden history. Sensitive earlier versions persist in the file. Rewrite before publication for privacy.

Cross-reference stream variants. Modern PDFs use compressed cross-reference streams; the principle is the same as classic xrefs but the storage is different.

Multiple %%EOF markers. Some tools mistakenly assume only one. Real PDFs may have many.

Re-saving creates new generations. The same object number can have multiple generations as it's modified. Visible in xref tables.

Practical recipe

For working with incremental updates:

Save (not Save As) for signed and form-filled PDFs.
Rewrite periodically for documents that have been saved many times.
Before publishing, rewrite to remove history.
For sensitive content, always rewrite after redaction.
For forensic analysis, examine the entire file including older xrefs.

For browser-based PDF cleanup that produces a single-pass output (not incremental), Docento.app handles common operations locally.

Takeaway

Incremental updates are how PDFs evolve over time without breaking signatures or rewriting everything. They are essential for signing workflows and convenient for form filling and annotation. They are also a hiding place for history that should be cleaned before sensitive publication. Knowing when to incremental-update and when to rewrite is one of those subtle PDF skills that prevents costly mistakes. See also PDF internals: objects and streams, digital signature internals deep dive, and linearized PDF fast web view.