Compressing a PDF without losing its text
Most PDF compressors flatten your pages into images, which silently ends search, copy-paste and screen reader access. A lossless pass should come first.
Updated 6 min read
There are two fundamentally different ways to make a PDF smaller, and the difference between them is permanent.
Most tools do the destructive one without telling you, because it always works. It is worth understanding what you lose, because for a lot of documents the loss matters more than the saving.
The two methods
Lossless rewrite
A PDF is a collection of objects: fonts, images, page descriptions, metadata. Many files — especially those produced by Word, by scanners, or by automated report generators — are built carelessly. They contain duplicated fonts, uncompressed object streams, orphaned resources from deleted pages, and sometimes entire embedded thumbnails nobody asked for.
Rewriting the file with object streams enabled and the duplicates dropped reclaims that space without touching a single pixel or glyph. Typical saving is 5–20%, occasionally far more on a badly generated file.
Everything survives. Text stays selectable, search works, copy-paste works, screen readers work, and the glyphs stay sharp at any zoom level. The catch is that the saving is whatever it is — there is no dial, so lossless cannot be aimed at a target size.
Rasterising
Render each page to a bitmap, then build a new PDF containing those images. Render scale and JPEG quality are both adjustable, so any target size is reachable.
The cost is severe and irreversible:
- Ctrl+F finds nothing. The text is no longer text, it is a picture of text.
- Nothing can be copied. Quoting a paragraph means retyping it.
- Screen readers see blank pages. For a document going to anyone who uses assistive technology, this is a serious accessibility regression.
- Zooming shows pixels instead of letters. Fine at 100%, bad at 200%.
- Form fields, links and bookmarks stop working.
None of that can be undone — there is no way back to text from a picture of text short of OCR, which introduces its own errors.
So the order is forced
Always try lossless first, measure the result, and rasterise only when that genuinely was not enough.
This matters because the two cases are very different in practice. A 14MB Word export of a text report frequently drops to 2MB losslessly, because it was simply built badly. A 14MB scan of twelve pages is already images — there is nothing structural to reclaim, and rasterising at a lower scale is the only lever that exists.
A tool that goes straight to rasterising has, in the first case, permanently destroyed searchable text in exchange for a saving it could have had for free. That is the behaviour to watch for, and it is the default in a lot of popular converters.
Compressing a PDF here tries the lossless rewrite first and measures it. If that lands under your target, it is what you get, with the text intact. Only if it does not does the tool rasterise — and it says so before it does, not after.
What makes a PDF large in the first place
Worth diagnosing, because it determines what will help:
Scanned pages. Each page is a photograph. A 300 DPI colour scan of A4 is roughly 25 megapixels per page — typically 1–3MB each, so twelve pages is 20MB+. Nothing structural to reclaim; scale is the only lever.
Embedded images at full resolution. A report with a dozen photos pasted straight from a phone carries a dozen 4MB images, scaled down for display but stored at full size. Huge savings available here.
Embedded fonts. A full font subset is 50–500KB. Several weights of several families, embedded twice because the generator was careless, adds up.
Flattened transparency and vector artwork. A chart exported from some design tools expands into tens of thousands of individual vector objects.
If it is a scan, expect to rasterise. If it is a generated document, try lossless first and you may be finished.
When you must rasterise, what the settings mean
Render scale is usually expressed relative to the PDF point grid, where 1.0 is 72 DPI:
| Scale | DPI | What it is good for |
|---|---|---|
| 2.0 | 144 | Looks crisp on a retina screen; print-acceptable |
| 1.6 | 115 | Comfortable screen reading |
| 1.2 | 86 | Legible, visibly soft on small text |
| 0.6 | 43 | Floor — body text starts to break down |
Search scale before quality. This is a real distinction: too few pixels reads as "a small scan", which people accept, while heavy JPEG artefacts on sharp text edges read as "something is broken". So reduce the render scale first and keep JPEG quality reasonably high, rather than rendering large and compressing hard.
Also worth knowing: the budget is per page. A 100-page document into 1MB gives each page 10KB, which is below what a readable page needs at any scale. As with video, length dominates — splitting the document is often the better answer than compressing it further.
Before you compress at all
Two things that are faster than compressing, and sometimes sufficient:
Check whether it is actually too large. Email limits are measured on the base64-encoded message, not the file: Gmail's published 25MB corresponds to about 18MB of actual file, and Outlook's 20MB to about 15MB. See sending large files by email for the arithmetic.
Re-export rather than compress. If you still have the source document, exporting again with image downsampling enabled — Word, Pages and most design tools offer this — usually produces a better result than compressing the PDF afterwards, because the original full-resolution images are still available to downsample from.
Privacy, since PDFs are usually the sensitive ones
The documents people compress to fit portal limits are bank statements, tax returns, scanned passports, medical records and signed contracts. Those are the files least suited to being uploaded to an unknown server for processing.
Compression here runs entirely in your browser — the document is opened, rewritten or rendered, and saved locally, with no network request carrying it anywhere. You can confirm this in your browser's Network tab, or by disconnecting from the internet and compressing anyway.
FAQ
Can I compress a PDF without losing quality?
Yes, if the file has structural waste to reclaim — rewriting it with object streams and dropping duplicated resources typically saves 5–20% with nothing lost at all. What you cannot do is aim a lossless pass at a specific target, because there is no dial to turn. If lossless does not reach your number, reaching it requires rasterising, which ends selectable text permanently.
Why can't I search my PDF after compressing it?
Because the tool rasterised it: each page was rendered to an image and the text became a picture of text. This is irreversible without OCR. Any compressor that reaches an arbitrary target on a scanned document has done this — the thing to look for is whether it tried lossless first and whether it told you before rasterising.
How do I compress a scanned PDF?
Scans are already images, so there is little structural waste to reclaim and reducing the render scale is the main lever. Scan or render in greyscale if the document is black and white, and reduce scale before reducing JPEG quality — softness from fewer pixels is more acceptable than JPEG artefacts around text. If the document is long, splitting it is often better than compressing further, since the budget is divided per page.
What is the smallest a PDF can get?
It depends almost entirely on page count, because each page needs a minimum number of bytes to stay readable. Below roughly 25KB per page, a rasterised page starts to become difficult to read regardless of the scale and quality chosen. A 4-page document into 100KB is comfortable; a 100-page document into 100KB is not achievable in any useful form.
Do it now, in this tab
Each of these opens the tool with the target already set. It runs on your own machine — nothing is uploaded, there is no watermark and no signup, and the output is measured before you get it.
Reference
The limits this guide refers to
Each number carries the date it was last checked against the platform's own documentation.
- Gmail18MBGmail's attachment limit is 25MB for sending and 50MB for receiving, but it measures the base64-encoded message. Keep the file itself under about 18MB.Verified 26 Sep 2026
- Outlook15MBOutlook.com caps attachments at 20MB. Exchange and Microsoft 365 limits are set per organisation and are often lower, so 15MB is the safe target.Verified 26 Sep 2026
Next
Keep reading
- Compressing a photo for an online formExam, visa and job portals demand photos under 50KB, 100KB or 200KB with fixed dimensions. Here is how to hit the number without the photo becoming unusable.
- How to send a large video by emailGmail says 25MB and means about 18MB. Outlook says 20MB and often means less. Here is why, and the four ways to actually get a video sent.
- How to compress a video without uploading itBrowsers can now encode video with your machine's own hardware. No upload, no queue, no copy on someone else's server — and usually faster than the alternative.