Reverse-Engineering "How Small Will It Get?" From the Content
The first thing you want to know before compressing a PDF is "how much will the file size actually shrink?" Email attachment limits at 25 MB, Slack's 100 MB cap, Google Drive sharing thresholds — without a target reduction in mind, you can't pick a strategy.
The honest answer: the compression ratio is already decided by what's inside the PDF. Scanned documents will drop 70%; text-heavy PDFs cap out around 30%. Identifying which type your PDF is before clicking compress eliminates 80% of the "this didn't work like I expected" frustration.
TL;DR: Compression is dramatic for PDFs heavy in images, scans, and photos (60–80% reduction). Text-heavy and vector-heavy PDFs hit a ceiling at 20–35%. When compression "barely does anything," the cause is almost always one of these five: (1) the PDF had little room to compress in the first place / (2) it was already optimized / (3) high-resolution images stayed embedded / (4) unused pages, comments, edit history were left in / (5) you over-compressed and trashed quality.
The Five Patterns Behind Disappointing Compression
Pattern 1: Expecting Big Results From a Text-Heavy PDF
The most common letdown. PDFs exported from Word — contracts, meeting notes, reports — store text and fonts using already-efficient compression (Flate). The most you can squeeze out is 20–35%, never 50%.
When someone asks "make this 10 MB PDF fit under 2 MB" and the document is text-heavy, the request is mathematically out of reach. Open the PDF, check the image-to-text ratio, and if it's text-dominant, redirect the conversation to deleting unnecessary pages or splitting the file instead of compressing harder.
Pattern 2: Re-Compressing an Already-Compressed PDF
You compress once, the result still feels too big, so you compress again. The second pass barely does anything (single-digit percent at best). Once an image has been downsampled, there's no information left to throw away.
The tell is the starting size. A 10-page PDF under 1 MB is essentially already optimized — there's nothing left for a compression tool to remove. Further reductions mean page deletion or manually swapping out images, full stop. That's why running PDFnite on a PDF that already went through another cloud PDF service or Adobe Acrobat barely moves the needle.
Pattern 3: High-Resolution Images Embedded as-is
Surprisingly common: a 4032×3024 px phone photo dropped into a PDF and then run through a compressor. Compression tools assume downsampling is on the table, so a PDF with screen-overkill image resolution can drop massively — but the same setup risks murdering legibility if you push compression too hard.
Two options. (1) Resize images on the source side before adding them to the PDF (long edge ~2480 px is enough for full A4 at 300 dpi). (2) Use a "medium" compression level and inspect text and image sharpness to dial it in. If you regularly PDF-ize phone photos of receipts and business cards, switching to "resize first, PDF second" alone will kill recurring storage problems.
Pattern 4: Compressing Without First Removing Unused Pages, Comments, History
PDFs accumulate invisible weight: review comments, edit history, thumbnail images, JavaScript, XMP metadata, and stale object versions. Anything that's been re-exported from Word repeatedly or heavily edited in Acrobat tends to be bigger than its visible page count suggests.
The right order is edit pages first, then compress. Use the Page Editor to remove dead pages and clear comments in the source app, then run Compress PDF. You routinely get an extra 10–20% reduction with no quality loss. For projects like consolidating scanned survey responses, dropping blank pages and bleed-through pages first is a huge multiplier.
Pattern 5: Over-Compressing and Ruining Print Output
You pick "maximum compression" to get under the email limit, then send the same PDF to print and the text turns into mush. "High" or "maximum" levels often downsample below 150 dpi, which is fine on screen but obviously degraded on A4 print.
The fix is to pick the use case first (see the cheat sheet below). 150 dpi for email and screen sharing, 200 dpi for office printing, 300 dpi+ for vendor delivery and print shop submission. After compressing, always open the result in the actual target use case (test print if it's going to print) before distribution. The most dangerous mistake is feeling relieved that the file got small and shipping it without verification.
Compression Results by File Type
The content mix decides the ceiling. Classify your PDF first, then set expectations.
| File Type | Content Mix | Before | After | Reduction | Effect |
|---|---|---|---|---|---|
| Scanned PDF (document) | 300 dpi color / grayscale | 10 MB | 2–4 MB | 60–80% | ◎ Maximum |
| Photo / catalog book | High-resolution raster images | 20 MB | 5–8 MB | 60–75% | ◎ Strong |
| Presentation slides | Charts, screenshots, mixed visuals | 5 MB | 1–2 MB | 60–80% | ◎ Strong |
| Mixed PDF | Text + charts + a few images | 3 MB | 1–1.5 MB | 50–65% | ◯ Moderate |
| Text-heavy | Word export, contracts | 1 MB | 0.5–0.8 MB | 20–35% | △ Limited |
| Vector-heavy | CAD drawings, Illustrator export | 3 MB | 2–2.5 MB | 15–35% | △ Limited |
| Already compressed | Previously optimized PDF | 2 MB | 1.9–2 MB | 0–5% | × Effectively none |
How to read it: The top three (scans, photos, presentations) are the compression sweet spot. The rest is the "don't expect miracles" zone. Sort your PDF into the right bucket in 30 seconds before you click compress.
Recommended DPI / Quality Level by Use Case
The ideal resolution and quality differ depending on why you're compressing. Pick the use case first, then the compression level — that's how you avoid trashing print output to fit an email limit.
| Use Case | Recommended DPI | Compression Level | Expected Size (10-page A4) | Notes |
|---|---|---|---|---|
| Email / chat sharing | 100–150 dpi | High | 0.5–1.5 MB | Screen-readable text is enough |
| Slack / Teams sharing | 150 dpi | Medium–High | 1–2 MB | "High" if hitting the 100 MB cap |
| Web download / blog post | 150 dpi | Medium | 1–2 MB | Sufficient for search indexing |
| Office print (B/W) | 200 dpi | Medium | 2–4 MB | A4 grayscale standard |
| Office print (color) | 200–300 dpi | Low–Medium | 3–6 MB | Lean higher for photos / charts |
| Vendor / print shop submission | 300 dpi+ | Low or none | Near original size | Don't compress for print delivery |
| Long-term archive (PDF/A) | 300 dpi | Low | Near original size | Edit lock + font embed required |
Key idea: Sending an email is the opposite goal of submitting to a print vendor. Don't reuse one PDF for both. Maintain a "distribution copy" and a "master copy" separately and life gets simpler.
PDF Compression Tool Comparison
Sort by price, local-only privacy, and batch capability and the right tool is obvious.
| Tool | Price | Install | Privacy | Compression Method | Batch | Best for |
|---|---|---|---|---|---|---|
| PDFnite Compress PDF | Free | None (browser) | ◎ Local | Image downsampling | ◯ One file at a time | Everyday docs, office use |
| Adobe Acrobat Pro | Paid (from $19.99/mo) | Required | ◯ Local possible | Profile-based (PDF/X etc.) | ◎ Action wizard | Heavy professional use |
| macOS Preview | Free (built-in) | None (Mac only) | ◎ Local | Quartz filter | △ One file at a time | Quick Mac compressions |
| Other cloud PDF services | Freemium with caps | None | △ Server-side | Cloud-side | △ Capped on free tier | One-off small jobs |
| Ghostscript (CLI) | Free (OSS) | Install required | ◎ Local | -dPDFSETTINGS profiles |
◎ Shell scripting | Server-side batch jobs |
| qpdf (CLI) | Free (OSS) | Install required | ◎ Local | Object stream optimization | ◎ | Structural compression for non-image PDFs |
Practical rule: For sensitive documents, always use a local-processing tool (PDFnite, Acrobat, Preview, or CLI). For batch processing dozens to hundreds of files with the same settings, Ghostscript wins, though there's a CLI learning curve. PDFnite for "compress and visually verify each file," CLI for "same settings, many files" is the rule of thumb.
How to Compress with PDFnite
PDFnite's compression tool runs entirely in your browser — no server upload.
- Decide the use case first (email / print / archive)
- Use the Page Editor to drop unnecessary pages first if any
- Open the Compress PDF page
- Drag and drop your PDF or click to select
- Pick a compression level (refer to the use case cheat sheet)
- Click "Compress"
- Before and after sizes are shown side-by-side — verify the reduction
- Open the downloaded PDF in the actual target use case (test print if it's going to print)
- If reduction is below expectation, cross-reference the 5 failure patterns and replan
For multiple files, process each one in turn. There's a daily usage limit but no charge — try as many configurations as you need.
Need to merge or split after compressing? Use Merge PDF or Split PDF. For sensitive docs, set a password with Lock PDF.
Pre-Compress Checklist
A 30-second review before clicking compress prevents the "this didn't work" outcome.
- Use case is decided (email / print / archive)
- Content type classified (scan / photo / charts / text / vector)
- Unnecessary pages removed first (Page Editor)
- Comments / edit history cleared in the source app
- Original file size checked (already optimized?)
- DPI / compression level matches the use case
- For sensitive docs, a local-processing tool is selected
- For print output, compression level is "low" or none
- After compressing, the PDF is opened in the actual target use case
- For email, the result is under the recipient's attachment limit (25 MB / 100 MB)
- If distribution requires it, merge or password-protect (Merge PDF / Lock PDF)
The four-step rhythm — classify content → decide use case → pick level → verify — eliminates almost all compression accidents.
Frequently Asked Questions
My PDF barely got smaller after compression. Why?
Three usual suspects. (1) It's a text-heavy PDF with little room to compress, (2) it's already been optimized, or (3) it's a vector-heavy PDF (CAD, Illustrator export). If your 10-page PDF is already under 1 MB, there's almost nothing structurally left to remove. Switch to page deletion or manual image replacement instead.
How much does compression hurt image quality?
"Low" compression is usually indistinguishable from the original, "medium" looks fine on screen, and "high" or "maximum" often downsamples below 150 dpi which can mush text in print. Rule of thumb: "high" for email, "medium" for office printing, "low" or none for vendor submission.
Will compressing the same PDF multiple times keep shrinking it?
Almost never. The first pass captures the maximum reduction; subsequent passes deliver only single-digit percent changes (or none). Once images have been downsampled, there's no further information to remove. Page deletion or manual image replacement are the only paths forward.
How much can I expect to compress a scanned PDF?
For 300 dpi color scans, 60–80% reduction is typical — a 10 MB scan drops to 2–4 MB. If the scanner originally output at 150 dpi or below, the file is already small and compression is limited. Scanner profiles set to "OCR" or "high quality" pump up file size; revert to standard if you don't need them.
My email attachment exceeds the 25 MB limit
Three escalating moves. (1) Compress PDF at "high" → (2) Page Editor to drop unused pages → (3) Split PDF to send the document as chapter chunks. If compression alone isn't enough, the right answer is splitting. If the recipient needs to reassemble, include a quick "merge using a free tool like PDFnite" note in the email.
Can I make one PDF that works for both print and screen viewing?
Technically yes, but size and quality are a tradeoff so something gives. If you genuinely need both, maintain two files: a lightweight distribution copy (150 dpi) and a high-quality master (300 dpi). Keep the uncompressed master archived; you can always compress later. You can't reconstruct a high-quality version from a compressed one — the information is gone.
Can I compress a PDF/A (long-term archive) file?
PDF/A allows image downsampling but prohibits removing embedded fonts or applying encryption. If a compression tool does either, the file loses PDF/A compliance. For preservation use, compress with Acrobat's "preserve PDF/A" mode specifically. Generic compression tools don't guarantee PDF/A compatibility.
After compressing, the password protection is gone
Some tools strip existing password protection during compression. Re-apply protection with Lock PDF afterward. Conversely, password-protected PDFs sometimes can't be ingested by compression tools at all — in that case, run Unlock PDF → compress → re-lock as a three-step process.
Summary
PDF compression results are decided by the content of the file before you click anything — image-heavy PDFs drop 60–80%, text-heavy hit a 20–35% ceiling. When the result feels disappointing, the cause is almost always one of: (1) limited compression headroom / (2) already optimized / (3) high-resolution images left embedded / (4) unused pages or invisible cruft retained / (5) over-compression destroying quality.
The biggest single move is deciding the use case first. The optimal DPI and compression level differ between email, print, and archive — don't try to make one file serve all three.
PDFnite's Compress PDF runs locally in the browser, with no server upload, so you can compress sensitive documents safely. Combined with Page Editor for pre-compression cleanup, you typically pick up an extra 10–20% reduction. Classify the file, decide the use case, then click compress.