An upload form rejects your file. An email bounces. A portal insists on 2 MB and your document is 14 MB. The immediate question is how to make it smaller — but the more useful question is why it got so large, because that determines whether compression will help at all.
A text-based PDF is small. A page of ordinary typed text is typically tens of kilobytes, because the file stores character codes and font data rather than pixels. Two hundred such pages can still fit comfortably under a megabyte.
A scanned PDF is a different animal. Every page is a photograph, and the size depends on capture resolution, colour depth and how hard the image was already compressed. A colour scan at high resolution can easily be 3–8 MB per page. Ten pages and you are past every ordinary attachment limit.
So the first thing to establish is which kind you have. Try to select a word on the page: if you get a clean text highlight, it is text-based and probably already small. If the whole page highlights as one block, it is a scan, and that is where your megabytes are.
Limits vary and change, so check the specific service, but the general picture is stable:
| Destination | Typical ceiling | Notes |
|---|---|---|
| Ordinary email attachment | ~20–25 MB | Both ends have limits — the receiving server may be stricter than yours |
| Government and institutional upload portals | 1–5 MB, sometimes per file | The tightest limits you will meet, and usually non-negotiable |
| Job and application forms | 2–10 MB | Often also restrict page count or dimensions |
| Messaging apps | 100 MB and up | Rarely the constraint |
| Cloud link instead of attachment | No practical limit | The correct answer for genuinely large files |
Note the asymmetry: attachments are usually encoded for transport, which inflates them somewhat in transit. A file sitting just under a stated limit can still be refused. Leave yourself headroom rather than aiming exactly at the number.
For a scanned PDF, compression re-encodes the page images: reducing pixel dimensions, lowering colour depth, or applying stronger image compression. Every one of those discards information permanently. You are trading legibility for size, and the trade is one-way — the discarded detail cannot be recovered from the smaller file.
This is why the sensible approach is to compress from the original, not repeatedly. Compressing an already-compressed file stacks the losses and produces a noticeably worse page than a single pass would have.
Sometimes the file genuinely cannot fit. Reasonable options, in order:
| Symptom | Cause | What to do |
|---|---|---|
| Barely got smaller | Already a text PDF — no images to compress | Split the file instead; there is nothing to squeeze |
| Text now blurry or smeared | Compressed too aggressively, or compressed twice | Start again from the original with a lighter setting |
| Signature or stamp faded out | Converted to pure black and white, losing mid-tones | Use greyscale rather than bilevel for anything hand-marked |
| Under the limit but still rejected | Transport encoding inflates attachments; or a per-page or dimension rule | Aim comfortably under; re-read the portal's stated requirements |
| Result larger than the original | Source was already efficiently compressed | Keep the original and split it |
| OCR much worse after compressing | Artefacts around characters | Recognise first, compress second |
Compression in Pennary happens in your browser. The document is not uploaded to a server to be processed and returned. Worth knowing, given that the files people most often need to shrink for a portal — identity documents, financial statements, medical reports, official correspondence — are precisely the ones you would least want sitting on someone else's machine.