Two documents, both thirty pages, both A4. One goes from 38 MB to 2 MB. The other gives back four kilobytes. Most people conclude the tool is broken, try four more, get the same answer, and give up. The tool is usually fine. The two files differ in a way no PDF reader shows you on screen.
The word compression is doing at least four jobs here, and they operate on different parts of the file. Some are available to code running in a browser tab and some are not. Once you can tell which job a tool is doing, the surprising results stop being surprising.
So this is the mechanical version. What the file is made of, what a save rewrites, why a text document has nothing left to give, and why a compressor sometimes hands back something larger.
A PDF is a bag of numbered objects
Open a PDF in a text editor and most of it is noise, but the skeleton shows through. A header line with a version number. Then a long run of numbered objects. Then a cross-reference table giving the byte offset of each one, and a trailer pointing at the root of the document. A stream is a dictionary followed by a block of raw bytes, and the dictionary says how those bytes were encoded.
That encoding is called the filter, and it is the part people miss. Page drawing instructions, embedded font programs and most other non-image data are stored under FlateDecode, which is the deflate algorithm a ZIP file uses. Photographs are usually stored under DCTDecode, meaning the bytes sitting in the file are a JPEG. Bitonal scans out of an office copier often arrive as CCITTFaxDecode or JBIG2Decode.
The consequence is that a PDF arrives already compressed. Every stream in it was encoded by whatever produced the file. A compressor you run afterwards is not finding untouched data to squeeze. It is reorganising the container around streams that are, in most cases, already about as small as their filter will make them.
What a rebuild can genuinely remove
When a tool opens a document and writes a new one out, the saving comes from a short list of places. None of them involve looking at the picture on the page.
- Objects nothing points at any more. Delete a page in some editors and the image it used stays in the file, orphaned. A rebuild walks out from the document root, copies what it reaches, and leaves the rest behind.
- Incremental save history. A PDF can be updated by appending to the end of the file: new objects, a new cross-reference section, a new trailer, with the previous version left underneath. That is why a contract through eleven rounds of edits may still carry all eleven, including paragraphs somebody believes they deleted.
- The cross-reference table itself. Written the old way it is a line of ASCII per object, twenty bytes each, uncompressed. A cross-reference stream stores the same thing as compressed binary, worth a few hundred kilobytes on a file with 40,000 objects.
- Small objects, through object streams. Rather than writing every little dictionary as its own top-level object, a modern writer packs hundreds into one Flate-compressed stream. Dictionaries are repetitive text and they deflate well side by side. This is the main structural win.
- Metadata. The info dictionary holds title, author, subject, creator and producer, usually with an XMP packet repeating them in XML. A few kilobytes at most, so this is a privacy operation rather than a size one, but those fields carry your name, your software version and sometimes the path you saved from.
Why two files of the same length behave nothing alike
Everything above works on the container. If that is where your megabytes are, the result is dramatic. If they sit inside image streams, the container is a rounding error and the result is close to nothing. That one fact explains most of the variance between files.
File size per page is a clue, not a diagnosis. A large average can come from scanned images, fonts, attachments or other resources. Inspect a few pages and the document properties before choosing a compression method.
| What the file is mostly made of | Result from a structural rebuild | Why |
|---|---|---|
| Text and vector graphics from Word, Docs or LaTeX | 0 to 5 percent | Each page is already a Flate-compressed content stream. Only the container is left to tidy. |
| A document with a long history of incremental saves | 10 to 40 percent | Every superseded revision is still in the file and can be dropped in one go. |
| Thousands of small annotations, comments or form fields | 10 to 25 percent | Lots of small dictionaries, which is exactly what object streams were designed for. |
| Four full Unicode font families embedded whole | Almost nothing, though this is why the file is large | Re-subsetting means rewriting the font programs. A copy-based rebuild does not do that. |
| A scan: one 300 dpi colour image per page | Under 2 percent | The bytes are JPEG already. Nothing outside the images is big enough to matter. |
| Slides with a full-bleed photograph behind every one | Under 2 percent | Structurally this is a scan wearing a suit. |
| A file already saved with object streams by a careful producer | 0 percent, sometimes slightly negative | The work has been done. A second pass has nothing to find. |
Compressing and downsampling are not the same operation
This is the distinction the whole subject turns on. Compression makes the same data smaller. Deflate finds repetition and encodes it more efficiently, and what comes out is bit for bit what went in. Downsampling means having less data: fewer pixels, fewer colour channels, coarser detail. It cannot be undone, and it is where the large savings live.
The arithmetic is blunt. An A4 page at 600 dpi is about 35 million pixels. Resample to 150 dpi and you keep one sixteenth, because you halve in both directions twice. Convert a colour scan of black text on white to grayscale and two channels of three go with it. Re-encode what survives at JPEG quality 60 rather than 95 and it drops again. That chain, usually Ghostscript behind a preset, explains 40 MB becoming 4 MB.
UtilByte’s structural PDF mode uses pdf-lib to rewrite document structure without intentionally resampling page images. That limits potential savings on image-heavy scans. A rewrite can still affect document features, metadata or signatures; inspect the output and keep the original.
A browser can reduce a scan locally by re-encoding images or rasterizing pages; a large reduction does not prove an upload. UtilByte’s PDF-to-size raster mode produces page images and loses features such as selectable text, links and forms. Check the processing disclosure and inspect the result.
Fonts, and the tag that tells you which kind you have
Fonts are the second most common reason a document is unexpectedly heavy, and the only one you can diagnose in ten seconds. Open the document properties in any reader and find the fonts list. A name like ABCDEE+Calibri is a subset: the six-letter prefix and plus sign mean only the glyphs the document actually uses were embedded, typically 20 to 60 KB. A name with no prefix is usually the whole font program.
Whole is expensive. A large Unicode family carries several thousand glyphs, and four weights of one can be a few megabytes before anyone types a word. CJK families are worse again. It happens when someone ticks embed all characters, or exports a file for further editing rather than for distribution.
A structural compressor cannot fix this. Re-subsetting means parsing the font program, working out which glyphs the pages use, and writing a new font, which is a different class of work from copying an object. The fix is upstream: export again with subsetting on and the editing option off.
Why compressing sometimes gives you a bigger file
It happens more often than you would expect, and it is not a bug. A rebuild is a rewrite, and a rewrite can land in a worse spot than where it started.
- The file was already optimised. If the producer wrote compact cross-reference streams and packed its objects sensibly, a second pass has nothing to remove and adds a few hundred bytes of its own overhead.
- Streams get decompressed and recompressed. Two deflate implementations tuned differently will not produce byte-identical output, and sometimes the new one is marginally worse.
- Shared resources can multiply. If pages 1 and 40 both pointed at one image object, a copy that treats pages independently can embed it twice. On a document with a logo on every page that is not a small mistake.
- Linearisation is lost. A file arranged for fast web viewing keeps the first page and a hint table at the front, and re-saving usually drops that arrangement.
- Encrypted files never get that far. Password-protected PDFs will not open in pdf-lib at all, so remove the protection in whatever application owns the document first.
Reading the result honestly
A tool reporting a saving of zero percent is often clamping a negative number, so a flat zero can mean the rebuild grew your file. Keep the original either way. Then spend fifteen seconds on the output: confirm the page count matches, and try to select a line of text on a page that had text before. If the text has turned into a picture, something rasterised your document, and you should decide whether you are happy with that before it reaches a portal expecting a searchable file.
Common questions
Why did my PDF not get smaller at all?
The PDF may already be optimized, or it may contain large images that a structural rewrite does not resize. Other resources can also account for the size. Compare the original and result rather than diagnosing the document from a bytes-per-page threshold alone.
Why is my compressed PDF larger than the original?
Because a rebuild is a rewrite. If the original was already written with compact cross-reference streams and packed objects, the new copy adds a little overhead and removes nothing. Recompressing streams with a different deflate implementation can land a few bytes worse, and copying pages independently can duplicate a resource that was shared. It is not a sign of damage, but keep the original.
What is the difference between compressing and downsampling a PDF?
Lossless compression preserves the encoded data, while lossy image re-encoding discards information. Downsampling specifically reduces spatial resolution. PDF tools may combine these operations; inspect which mode you chose before assuming that a smaller file preserves every feature.
Can a browser-based tool compress a scanned PDF properly?
Yes, with an implementation that re-encodes images or rasterizes pages locally. UtilByte’s structural mode does not downsample images; its PDF-to-size raster mode can reduce scans but loses selectable text and other document features. Results depend on the input, settings and device memory.
Does compressing a PDF affect quality?
A structural rewrite is intended to retain page appearance, but can change metadata and invalidate digital signatures; document features still need checking. Rasterization turns pages into images and can reduce visual quality while removing text, links or form behavior. Retain the original and review the exported copy.
Tools for this
Repack the object graph and clear metadata in the browser, with the ceiling stated plainly rather than hidden behind a progress bar.
Split into separate files only if the receiving application permits it. Keep every required page and check whether the size limit applies per file or to the whole submission.
Combine documents once each one is already the size it needs to be, rather than before.
Build a document from images. They are embedded at the size they arrive at, so compress them first.
The step that actually matters for a photo-heavy PDF, done before the pages are assembled.
Pull the words out of a scan when what you needed was the text rather than a picture of it.