Blog › Why Rotating a PDF Doesn't Change Its Size
While building a PDF page editor, I rotated all 20 pages of a document by 90°. The file was 1,064,740 bytes before, and 1,064,740 bytes after. Not a single byte changed.
Then I kept just 3 of those 20 pages, and the same document went from 1,039.8KB to 156.5KB — an 85% cut. If it feels strange that rotation is free while deletion is that dramatic, it is because you are picturing a PDF as an image.
A JPEG or a PNG is ultimately an array of pixels: open the file and you get "this position is this colour", over and over. A PDF is nothing like that. What lives inside a PDF file is a graph of objects that point at one another.
A page is not itself a picture. It is a bundle of references and properties: it points at a content stream describing what to draw and in what order, and at a resource dictionary holding the fonts and images those instructions call for. A handful of properties — paper size, rotation angle — hang off it.
Once you see that structure, both numbers above explain themselves.
PDF pages carry a property called /Rotate. It records how many degrees the page should be turned when displayed, and it accepts exactly four values: 0, 90, 180 and 270.
Rotating therefore does not turn the page content around. It changes one number from 0 to 90. The content stream is untouched and no image is recompressed. That is also why the measurement came out exactly even — a single digit was swapped for another single digit, so there was nothing to make the file longer.
The contrast makes it clearer. Rotate a JPEG in a photo app and it will usually turn the pixels for real and recompress them, shaving off a little quality each time. In a PDF, you can rotate as many times as you like and the data is still bit-for-bit the original. Turn a page the wrong way and press three more times to get back — nothing is lost.
Merging PDFs copies page objects into a new document. You cannot take a page on its own, though: the fonts and images it pointed at have to exist in the new document too, or it will not look the same. So the resources come along.
The catch is that this copying cannot recognise duplicates. If three files use the identical logo image, the merger sees three separate resources and all three go in.
I measured the gap. On one side, three one-page PDFs each embedding the same 53KB image, merged together. On the other, a single document with three pages reusing one copy of that image.
One thing is easy to misread here, so let me be precise. In this measurement merging did not inflate anything. The three originals came to 157.7KB and the merged result was 156.5KB — very slightly smaller, because the per-file headers and cross-reference tables collapsed into one.
So the accurate statement is not "merging makes files bigger" but "merging does not reduce duplication." Combine ten company documents built from the same template and you get a file carrying ten copies of the same logo and the same font. That is correct behaviour: collapsing two resources into one means proving byte for byte that they really are identical, and getting that judgement slightly wrong breaks how the document looks.
Deleting pages is not a matter of removing something from the original either. Only the pages you keep are copied into a new document — which means resources the kept pages do not point at never come along in the first place.
From a 20-page document with a different photo on each page, I kept three.
The photos the other 17 pages used dropped out entirely, so this is exactly what you would expect. There is a practical takeaway in it: the surest way to shrink a PDF is not compression but deleting pages you do not need. Recompressing images costs quality; dropping unused pages costs nothing at all.
If you have ever merged or split a PDF, you have probably watched its table of contents vanish. Same structure, same explanation. Bookmarks are not attached to pages — they are attached to the document. A separate document-level list says "chapter 1 is that page object, chapter 2 is this one". Move the pages alone and the list stays behind; drag it across anyway and it points at things that are no longer there.
Digital signatures are even starker. A signature is a hash over a specific byte range of the file. Change one byte inside that range and the signature is void. Moving pages renumbers and relocates every object, so of course it breaks.
This is less a limitation than something that must not survive. The whole point of a signature is to prove the document has not changed since it was signed. If you could edit the contents and the signature still checked out, that signature would be guaranteeing nothing.
The most unexpected part of building the editor came last. To edit a PDF in a browser, you need two libraries. One can change a PDF but cannot show it to you; the other can show it but cannot change it.
Everything described so far — flipping a rotation value, copying page objects, dragging their resources along — is object-graph work, and it is comparatively simple. Actually drawing that page is a different problem entirely. You have to interpret every command in the content stream, read font files and turn glyphs into pixels, convert colour spaces, and composite transparency. It amounts to writing a small browser.
That weight shows up directly in the bundle. Here is what the page editor actually downloads:
That split has a practical consequence. The previews in the editor are rough screen-sized renders from pdf.js, while saving copies pages straight out of the original with pdf-lib. In other words, a blurry preview says nothing about the quality of the file you save. The previews exist only so you can decide which pages to keep.
It all follows from one sentence. A PDF is not a bundle of pixels but a collection of objects pointing at each other. That is why some edits are astonishingly cheap and others are impossible by design.
See it for yourself
Deleting and rotating pages happens entirely inside your browser. Files are never uploaded.