Why Compressing a PDF Online Can Be Riskier Than You'd Think
Published 9 July 2026 · 5 min read
The email bounces back: "attachment too large." So you go find a compressor, upload the 18MB PDF, and get back a 2MB version that opens fine. Job done. Nobody stops to ask why the file was 18MB in the first place — and the answer is usually the same one: it's a scanned document, and scans are basically just photographs of paper.
A scanned bank statement, a scanned lease, a scanned passport page — these are large because they're images, and compressing them means a tool has to actually decode those images, resample them, and re-encode them smaller. That's not a metadata trick. It requires genuinely processing the picture of your document.
Why compression specifically needs the real content
Some PDF tasks can get away with barely looking at what's inside a file. Compression can't. To meaningfully shrink a scanned PDF, a tool has to open every embedded image, figure out how much detail can be thrown away without the result looking obviously bad, and rebuild the image at a lower quality. There's no way to do that blind. The tool has to be able to see the image clearly enough to know what to cut.
Which means if that compression happens on someone else's server, so does the decoding of every scanned page — in full, uncompressed, readable form, if only for the seconds it takes to process.
What FormatDog does differently
FormatDog's Compress PDF tool pulls each embedded image out using pdf-lib, re-encodes it at a lower quality using your browser's own built-in Canvas image APIs (the same rendering pipeline your browser already uses to draw every image on every website you visit), and rebuilds the PDF with the smaller versions swapped in. Every step of that — decode, resample, re-encode, reassemble — happens on your device. The text and layout are left completely untouched; only the embedded images get recompressed.
A practical note: because your device is doing the actual image work instead of a shared server juggling everyone else's uploads at the same time, compression tends to be noticeably fast for typical file sizes, and there's no queue to wait behind.
How to verify this on any site
Open your browser's developer tools, go to the Network tab, then upload a file and run the compression. If your document's data is being sent to a server, you'll see it as an outgoing request in that list while the tool works. If the list stays empty of anything resembling your file, the compression genuinely happened on your device and never left it.
A fair caveat
Plenty of compression tools handle this responsibly and delete uploads promptly. The issue isn't that they're careless — it's that a scanned bank statement or passport page is exactly the kind of document where "briefly readable on a server somewhere" is a real, specific trade-off, and it's one you don't have to make when a tool that skips the upload step entirely is free and just as fast.