← All posts

Why your repaired PDF is a different size

The repair worked. The file opens in the program that was refusing it, the pages are all there, and you were about to send it on. Then you noticed the size: the original was 14 MB and the rebuilt copy is 2.3 MB.

Nothing you can see has changed. Same pages, same pictures, same text. So either eleven megabytes of something were quietly thrown away, or they were never doing anything in the first place, and there is no way to tell which by looking at the document.

Search for it and every result answers a different question — how to make a PDF smaller, or why an edited one got bigger. Nobody addresses the size change that a repair itself causes, which is a shame, because it has a precise explanation and it is almost always good news.

A rebuild keeps what is reachable, and a file holds more than that

A repair does not patch your file. It reads every page it can, imports each one into a brand-new empty document, and writes that document out with a fresh index. Nothing is copied across because it happens to be sitting in the old file. Things are copied across because something still points at them.

That is the whole mechanism. A PDF is a graph of numbered objects hanging off a root catalogue — pages, fonts, images, annotations — and the file on disk is simply every object that has ever been written into it, in the order it was written. The index at the end says which ones are current. Objects that nothing refers to any more are still physically present, still occupying bytes, and no reader will ever look at them. (Why the index goes wrong in the first place, and why one program opens the file while another refuses it, is its own story.)

So the rebuilt file is smaller by exactly the amount of unreachable material the old one was carrying. Your document was never 14 MB. It was 2.3 MB of document inside a 14 MB container.

Where eleven megabytes of nothing comes from

Three sources, and the first one accounts for most large drops.

Incremental saves. A PDF can be updated without being rewritten: the changed objects are appended to the end of the file, followed by a new index that points back at the previous one. The old copies of those objects stay exactly where they were. Fill in a form and save, and you have appended a second copy of every field. Do it thirty times — a timesheet, a case bundle, an application form passed between four people — and the file contains thirty layers of itself. Every layer is complete and only the last one is reachable. This is also the reason such a file grows every time somebody tries to compress it.

Orphans from editing. Delete a page in an editor that saves incrementally and the page dictionary is removed from the page tree, which is a change to one small object. The page's content stream and its 4 MB scan are not deleted, because deleting them would mean rewriting the file. They are simply no longer pointed at. The same goes for a replaced image, a removed attachment, a stripped annotation layer.

The old indexes themselves. Every revision left its own cross-reference table behind, and on a document with a big page tree those are not trivial. A rebuild writes one.

None of this is content. A reader that opened the original showed you exactly what the rebuilt file shows you, because a reader also only follows what is reachable.

Confirming that nothing real went with it

Reassurance is cheap; checking takes about three minutes, and on a document that matters it is worth doing once so you know what the numbers look like.

  1. Read the notes before the download button. Repair PDF states how many pages were rebuilt out of how many, and names any it left out because nothing readable was there. That line is the only one that can indicate real loss. If it says all pages were readable and rebuilt, the size drop is not pages.
  2. Look for the percentage note. When the rebuilt file comes back at least 3% smaller, the notes say so and by how much, and call it what it is: wreckage left behind. Below that threshold nothing is said, because a couple of per cent is just a different library writing the same document.
  3. Compare the two files in the inspector. Our PDF inspector reads a file in your browser and uploads nothing. Run the original, then the rebuild, and put the two readouts side by side. Page count and form field count are the two numbers that must match. The rest of the readout answers a different question — whether the two programs were disagreeing about damage at all.
  4. Check the bookmark line. Bookmarks are re-pointed at the new pages rather than copied blind, so the notes say how many were kept and how many now point at nothing. A bookmark pointing nowhere means the page it named did not survive.
  5. Open the last page. A file that was truncated mid-download is short at the end, and the end is the part nobody scrolls to.

When the size goes the other way

A rebuilt file that comes back slightly larger is normal too, and it means nothing was added.

The likeliest cause is that the original was written by a more aggressive optimiser than the one writing the new copy. Ghostscript, mutool clean -z and Acrobat's own size reduction all spend considerably more effort on deflate settings and on packing small objects together than a general-purpose rebuild does. Re-writing that file at ordinary settings gives back a few per cent. Nothing is different about the document.

A second cause: the original was linearised or signed and the rebuild is neither — though both of those usually push the size down rather than up.

What should make you look twice is a rebuilt file that is much bigger, because there is no mechanism in a rebuild that invents megabytes. Nearly every time, the file being compared against is not the file that went in — the original in the folder is a compressed or downsampled copy somebody made earlier, and you are measuring the rebuild against that rather than against the document.

What a rebuild does drop on purpose

Distinct from wreckage, and worth knowing because these are things you might actually miss. The notes name each one when it happens.

A missing page also shifts the numbering of everything after it, which quietly breaks any page range you had written down. Organize PDF pages is where you rewrite those ranges against the new numbering, or pull out a run of pages to compare against the same run in the original.

Two free commands that settle it properly

If you want to know what the old file was carrying before you rebuild it, count its revisions. Each incremental save appends an end-of-file marker, so the markers count the layers:

grep -ac "%%EOF" yourfile.pdf

One is a file saved once. Eight is eight generations of the document stacked up, and it tells you the shrink is coming before you run anything.

And if you want proof that no text was lost, compare the text itself rather than the byte count. Poppler's pdftotext is free and on every Linux distribution, in Homebrew, and in the Windows poppler builds:

pdftotext -layout original.pdf - | md5sum
pdftotext -layout repaired.pdf - | md5sum

Two identical hashes mean every character in the document survived the rebuild in the same order and the same layout. That is a stronger answer than any file size, and it takes a second. qpdf --check on both files fills in the structural half — it will tell you the original's index had to be reconstructed and that the rebuilt one's does not.

If the file is still bigger than you need

Repair is not a compressor and does nothing to a healthy file; the shrink it produces is a side effect of building a clean one. Once the wreckage is gone, what remains is the actual document, and if that is still too large for the portal or the mailbox, it is the images inside it that are the weight. Compress PDF re-saves those at a sensible resolution and leaves the text as text.

Run it in that order, though. Compressing a file full of dead revisions compresses the dead revisions too.

Tools this post uses: