Why Won't My PDF Get Any Smaller?
Most of a PDF's size lives in three places — images, fonts, and structure — and each one has a hard floor that no compressor can push past.
Run a 40MB PDF through a compressor and get back 38MB, and it feels like the tool didn't work. Usually it did — the file just doesn't have the kind of bloat compression can remove. PDF size comes from three sources, and each has a different, hard floor.
1. Images (usually 80%+ of the file)
Scanned documents and photo-heavy PDFs are mostly embedded images. Compression here means re-encoding each image at a lower quality or resolution — the same tradeoff as saving a JPEG at 60% instead of 95%.
- Big wins: a phone-scanned document at 300 DPI dropped to 150 DPI — the resolution is overkill for text, since you don't need to zoom into a receipt.
- No wins: the images are already compressed JPEGs at a reasonable quality. Re-compressing an already-lossy image loses more quality for a small size reduction (re-encoding JPEG-in-JPEG compounds artifacts), which is why a compressor set to "high quality" barely shrinks a file that's already been through this once.
2. Fonts (small, but not always compressible)
PDFs usually embed the fonts they use, so the file renders identically on any device. A full font file is 50–200KB; PDF generators can subset it down to only the characters actually used in the document, which can save real space in short documents.
- If your PDF has full fonts embedded (common from Word/Google Docs exports) and used only a handful of characters, subsetting can cut a meaningful chunk. But once a font's already subsetted (common in PDFs exported from design tools), there's nothing left to trim.
3. Structure and duplication
Every edit-save cycle in some PDF editors appends new object data rather than rewriting the file, so a PDF that's been edited ten times can carry ten generations of now-unused objects. A "linearize and clean" pass — removing orphaned objects, deduplicating identical embedded resources — can shrink a heavily-edited file with zero visible quality loss. This is the one kind of compression that's genuinely free: nothing visible changes.
Why "compress to 100KB" sometimes isn't possible
A target file size only works if there's something left to cut. A PDF that's mostly vector text (no images) is usually already near its floor — vector paths and font references are compact by nature, and there's no image quality dial left to turn. Compressing it further means literally rasterizing pages into low-resolution images, which is a worse result than the "uncompressed" original. Spellkit's PDF Compress tool won't do that trade silently — it optimizes what's genuinely compressible (images, structure) and stops there rather than degrading text into blurry pixels to hit an arbitrary number.
The fast way to check what's actually taking the space
Before assuming a compressor is broken, it's worth knowing what's inside the file. If a 10-page PDF is 30MB, that's almost certainly high-resolution images — a 10-page text document with no images is rarely more than a few hundred KB regardless of formatting. Once you know the culprit is images, resolution/quality settings will move the needle; if it's already lean vector content, no compressor will make it much smaller without deleting content.
