← All posts

Can you compress a password-protected PDF?

The file is 14 MB and the portal wants 10. It also has a password on it, which you have, and which you did not think was going to be part of this.

So you dropped it into a compressor and it refused — "this PDF is password-protected, remove the password and upload it again". Or worse, it accepted the file, thought about it for a few seconds and then failed with something unhelpful about an error on their side.

The answer to the question is no: nothing compresses a PDF while the encryption is still on it. But what you do next depends entirely on which of two very different things your file means by "password-protected", and one of them takes about a minute.

Which of the two you have, in five seconds

Open it in your usual reader.

Both are encryption; only the first is a wall. Why a PDF asks for its password every time sets the two apart properly, including how to tell from the file rather than from its behaviour: our PDF inspector reports whether a document is encrypted, in your browser, with no upload.

If the restrictions are somebody else's and you are wondering whether lifting them is your call to make, that is its own question and worth reading before you do it.

Why no compressor can work through the encryption

This is the part nobody writes down, and it explains the whole ordering problem.

PDF encryption is not applied to the file as a whole. It is applied stream by stream and string by string, inside a structure that stays in the clear. The page tree, the object numbers, the dictionary entries that say a picture is 3000 by 2000 pixels and encoded as JPEG — all readable without any password at all. That is why a reader can show you a page count for a document it cannot render.

So a compressor looking at your locked file can see there are forty images in it and how big each one claims to be. What it cannot do is decode a single pixel. To make a picture smaller you have to decode it to pixels and re-encode it, and the bytes it would decode are ciphertext keyed on the file encryption key, which is wrapped by the password. There is no partial route, no clever trick, no setting. It is not that tools refuse to try; there is nothing there to try on.

The same fact kills the other idea people have, which is zipping it. Ciphertext is designed to be statistically indistinguishable from random noise, and random noise does not compress. Zipping an encrypted PDF reliably saves you nothing at all.

Which means every tool anywhere that claims to compress a protected PDF is doing the same three things in the same order behind the scenes: decrypt with the password you gave it, re-encode the images, encrypt again. You may as well do the steps yourself, where you can see what happens to each one.

The order that works

  1. Take the security off with Unlock PDF. On the restrictions-only file there is nothing to type: run it with the password box empty and the flags come off anyway. The notes list what came off, in the form "restrictions lifted: printing, copying text", so you can see what the file was actually carrying.
  2. Compress the unlocked copy. Compress PDF re-saves the photographs and scans above your dpi ceiling and leaves the text as text. Read the notes rather than only the number — if the file barely moves, it is telling you where its size actually is, and no amount of unlocking changes that.
  3. Put the protection back with Password protect PDF, if the file is going anywhere it needs it. Set both passwords, and check the permission boxes, because they do not survive the round trip — see below.
  4. Check the size of the finished, re-protected file, not the compressed one, before you upload it to whatever has the ceiling.

If the file has a real opening password, do it on your machine

Here is the honest limit of the browser route: our upload check refuses any file it cannot open without a password, and that applies to every tool on the site, unlock included. A document with a genuine opening password is turned away at the door with "remove the password and upload it again", which is not much help when removing the password is what you came to do.

That case is a local job, and it is two free commands. qpdf does the decryption and the re-encryption; Ghostscript does the shrinking in between:

qpdf --password=SECRET --decrypt big.pdf clear.pdf
gs -sDEVICE=pdfwrite -dPDFSETTINGS=/ebook -o small.pdf clear.pdf
qpdf --encrypt --user-password=SECRET --owner-password=OTHER --bits=256 -- small.pdf out.pdf
rm clear.pdf

Ghostscript will also read the encrypted file directly, if you would rather skip the first step entirely: gs -sPDFPassword=SECRET -sDEVICE=pdfwrite -dPDFSETTINGS=/ebook -o small.pdf big.pdf. It writes an unencrypted result either way, so the final qpdf line still applies.

Two things to keep in mind. clear.pdf is your whole document with nothing on it, sitting on your disk, which is the real cost of any round trip like this — delete it when you are done rather than next month. And older qpdf builds want the positional form, qpdf --encrypt SECRET OTHER 256 -- small.pdf out.pdf, so check qpdf --version if it complains.

Putting the password back costs almost nothing

Worth knowing if you compressed to just under a ceiling and are now nervous about the last step.

Encryption adds a fixed amount to every stream it touches: an initialisation vector, plus padding up to the next block boundary. On a document whose size is a few large images that is invisible — on a 2.2 MB test file here it added 737 bytes, which is three hundredths of a per cent. On a 50-page text document made of hundreds of tiny streams the same fixed overhead came to about 10%, because the streams themselves are only a few hundred bytes each.

So the file that needs watching is the text-heavy one, which is also the file compression could not help much anyway. Measure the protected copy. That is the file the portal will weigh.

What the round trip takes with it

The permission flags do not come back on their own. Unlocking removes them; protecting sets fresh ones from whatever the boxes say, and the defaults are printing allowed, copying, editing and commenting refused. If the original allowed copying and you do not tick the box, you have handed back a more restricted document than you were given, and nobody will thank you for it.

A digital signature will not survive — three steps, three new files, and none of them is the document that was signed. So if the file is signed, send the signed original and argue with the size limit some other way. What unlocking does to a signature is the longer version.

Leaving the permissions password blank makes it fall back to your opening one, so anyone you send the finished file to can undo the restrictions you have just set. Fill in both boxes when the two audiences differ; putting the protection back on covers the rest of that step.

And the unlocked middle copy has no security at all, on your disk or on ours. Keep it long enough to compress it, then get rid of it.

One last thing, if the reason you are here is that a statement arrives encrypted every single month: compressing it is not really the problem you have. That prompt has its own fix, and it ends the typing rather than working around it.

Tools this post uses: