tags: [productivity, howto, tools, technology, career]
At some point almost everyone hits the same wall: you try to attach a PDF to an email, and it bounces back with some version of "attachment exceeds the maximum size." Gmail caps attachments at 25MB, Outlook is often lower depending on your organization's policy, and plenty of application portals and ATS systems cap uploads even smaller than that — sometimes 5MB or 10MB. A 40-page scanned document or a PDF full of high-res images can blow past that limit without feeling like it should.
The instinct is to search "compress pdf for email" and click whatever comes up first, which usually works fine — but it's worth understanding what compression is actually doing, because "compress" isn't one operation, and the wrong setting can either barely shrink the file or wreck the readability of the document.
What's actually taking up the space
In the overwhelming majority of oversized PDFs, the file size isn't coming from the text — text is essentially free, size-wise. It's coming from:
- Embedded images, especially scanned pages saved at print resolution (300 DPI) when the document is only ever going to be viewed on a screen
- Uncompressed or lightly-compressed image formats embedded as-is rather than re-encoded efficiently
- Duplicate embedded fonts across pages, or full font sets embedded when only a handful of glyphs are actually used
- Leftover data from edits — earlier versions of images or content that got replaced but not actually removed from the file, similar to how deleted text can linger in metadata
This is why a 20-page text-only contract might be 400KB, while a 20-page scanned form is 30MB — the second one is functionally a folder of large photos wearing a PDF's file extension.
The three settings that actually matter
Most compression tools present some version of Light / Medium / Heavy or Low / Medium / High. Here's what's actually happening at each level, so you can pick the right one instead of guessing:
Light compression — recompresses embedded images at a high quality factor and strips unnecessary metadata, but doesn't downsample resolution. Good for documents where visual fidelity matters (photography portfolios, design proofs) and you just need to trim excess.
Medium compression — this is the one that matters most for the "won't fit in an email" problem. It downsamples images to a screen-appropriate resolution (roughly 150 DPI) rather than print resolution (300 DPI), which is the single biggest lever for scanned documents, since most recipients are reading on a screen where 300 DPI is imperceptible anyway.
Heavy compression — aggressively downsamples (often to ~72–96 DPI) and increases lossy compression on images. This gets you the smallest possible file, but on documents with small text embedded inside images (a scanned handwritten form, a photographed receipt) it can start to visibly degrade legibility. Worth previewing before you send, not just trusting blind.
The mistake I see most often is people reaching straight for "Heavy" because they assume more compression is strictly better — when Medium usually solves the actual email-size problem while keeping the document genuinely readable.
A quick example
A 15MB scanned 20-page PDF, run through ihatepdf.cv's compressor:
- Light: ~11MB — still might not clear a 10MB portal limit
- Medium: ~2–3MB — comfortably under most email and upload limits, image quality still fine for on-screen reading
- Heavy: ~800KB–1MB — useful if you're near a very tight cap (some application portals cap at 2MB), but check the output before sending if the scan has small text
One thing worth checking before you compress at all
If you're compressing specifically to get under an upload portal's limit — job applications and government portals are the most common case — check whether the portal's limit is on the original file or explicitly says it accepts compressed PDFs; a few oddly-configured ones reject files that don't look like a "normal" scan output. Rare, but worth a second look if a compressed file gets rejected for reasons other than size.
Compression itself is quick, free, and — if it's running client-side rather than through an upload-based tool — doesn't require sending the document (which might be the thing you're trying to email in the first place) to a third party just to shrink it.
The compressor at ihatepdf.cv runs all three levels locally in-browser, free, no watermark, no size limit imposed by a server queue. Worth testing against whatever's currently bouncing out of your outbox.
Top comments (0)