"Compress this PDF" sounds like one operation, but a PDF compressor is usually doing up to four structurally different things at once, and which ones actually apply to your file determines whether you get a 90% size reduction or almost none at all.
Image downsampling and recompression — where almost all the savings come from
Most of a PDF's file size, when it's large, comes from embedded images: scanned pages, photos, or high-resolution graphics. Compression tools typically reduce these in two ways — downsampling (reducing the pixel resolution/DPI, since print-quality 300 DPI is far more than a screen or most portal uploads need) and recompressing the image data at a lower JPEG quality setting. This is why a scanned document — which is essentially one large image per page — can often shrink by 80-95%, while a document exported directly from Word (mostly text and vector graphics, with little or no embedded image data) barely shrinks at all, because there's very little image data to compress in the first place.
Font subsetting and deduplication
PDFs often embed entire font files even when a document only uses a handful of characters from them, and multiple pages can end up with redundant duplicate copies of the same embedded font. Subsetting keeps only the glyphs actually used; deduplication merges redundant copies into one. This saves real space on text-heavy, multi-font documents, though usually far less dramatically than image compression does.
Removing redundant objects and metadata
PDFs accumulate cruft over their editing history — old revision data, unused embedded objects, redundant metadata, sometimes even hidden layers from previous edits. A good compressor strips this out. It's rarely the biggest contributor to file size, but it's essentially free savings with no quality tradeoff.
Stream compression
The underlying content streams (the text and drawing instructions that make up each page) are typically compressed with a lossless algorithm (commonly Flate/zlib, the same family used by ZIP). This is usually already applied by whatever tool created the PDF in the first place, so a compressor re-applying it often finds little left to save here — but it matters for PDFs generated by older or less careful tools that skipped this step.
Why compression can quietly ruin a scanned document
This is the failure mode that matters most for exam applications, ID uploads, and government portal submissions: pushing image compression too aggressively on a scanned document can degrade small text, signatures, and official stamps/seals below a legible threshold, even though the file "looks fine" at a glance on a large screen. A compressed scan of a certificate might look acceptable when you preview it, but fail a portal's manual review because a signature or seal has become blurry. When compressing documents that need to remain officially legible — not just visually browsable — it's worth compressing conservatively and specifically checking the small print, signatures, and stamps at full zoom before submitting, not just the overall page appearance.
Other things that can go wrong
- Color profile shifts — aggressive recompression can occasionally shift color rendering, which matters if a document uses color-coding (like a colored official seal) that needs to remain visually distinct.
- Form field data loss — some compression tools flatten or strip interactive form fields; if you need a fillable PDF to stay fillable, check this specifically.
- Password-protected PDFs generally need to be unlocked before compression, since a compressor can't read (and therefore can't optimize) an encrypted document's internal streams.
The privacy angle that matters more than people realize
A meaningful share of PDFs people compress are sensitive: government ID scans, certificates, signed contracts, financial documents. A compressor that uploads your file to a remote server to process it means that document — and everything in it — passes through and is at least briefly stored on infrastructure you don't control. Client-side compression, where the entire process runs in your browser and the file never leaves your device, avoids that exposure entirely, which is worth specifically checking for before uploading anything sensitive to an online compression tool.
The practical target
Match the compression level to the actual requirement: email attachment limits are typically far more generous (often 20-25MB) than most people assume; government portal uploads are often the tightest constraint (commonly 200KB-2MB for a single scanned document); and anything meant for print should stay closer to the original resolution rather than being aggressively compressed. Compress to the specific limit you actually need, not to "as small as possible" — the same lesson that applies to exam photo file sizes applies here too.