Compress PDF

About PDF Compressor

This tool compresses PDF files to reduce their file size. You can choose from different compression levels to balance between file size and quality. All processing happens in your browser for complete privacy. See also our Merge PDFs and Password Protect PDF.

What's the best way to shrink a PDF without losing quality?

The single highest-impact move is to recompress embedded images, because for most PDFs they dominate the byte count. Choose the High quality preset to keep visible quality near-original while still cutting size by 30–60% on photographic content; pick Medium for screen reading (good for email attachments at 150 DPI); pick Low only when readability of small text is not critical. The tool also subsets embedded fonts, strips duplicate objects, and removes editing history left behind by authoring apps — all lossless wins that typically add another 5–15% saving. For text-only or vector-heavy PDFs the gains are modest because there are no images to shrink; in those cases run Linearize PDF instead, which deduplicates the object stream without re-encoding anything visible.

How small can a PDF realistically get and what determines the floor?

The floor is set by the information content of the file: every embedded font subset costs roughly 30–100 KB depending on glyph coverage, every page adds a few hundred bytes of structural overhead, and every image is bounded by its perceptual entropy at the target DPI. A pure-text 10-page report can compress to under 50 KB; a 10-page brochure with photos rarely drops below 500 KB without ugly artefacts; a 100-page scanned document at 300 DPI is bounded by JBIG2 efficiency for monochrome (about 5–10 KB per page) or JPEG 2000 for colour (50–200 KB per page). If your file is already mostly compressed images, expect single-digit-percent gains from a second pass; if it was exported from Word with full-resolution PNGs, expect 80%+ reductions.

Does the tool support JBIG2 for scanned documents and JPEG 2000 for colour images?

The browser-based engine uses JPEG (DCT) for colour and grayscale images and Deflate/Flate for text and line art — the same algorithms specified in ISO 32000 part 7 and supported by every PDF reader since 1.4. JBIG2 (efficient for monochrome scanned text, common in PDF/A archives) and JPEG 2000 (lossy or lossless wavelet coding for photographs) are part of PDF 1.5+ but require native binary encoders not yet available in pure WebAssembly. For black-and-white scanned books where JBIG2 typically beats Deflate by 3–5×, run the file through Ghostscript or mutool offline with `mutool clean -giffs` to get those formats. We are tracking a WASM port of OpenJPEG and JBIG2enc for a future browser release.

Will compression damage the searchable text layer in an OCR'd PDF?

No — the invisible text layer added by OCR is stored as Tj/TJ text-showing operators in the content stream, encoded as Flate-compressed UTF-16 strings. Compress PDF re-encodes images and removes redundant objects but leaves text operators alone. After compression, Ctrl+F search, copy-paste, and screen-reader access continue to work exactly as before. The associated font subsets used by the invisible text are kept (otherwise the text positions would shift), even though the glyphs themselves are never drawn. If you find search has broken after compression, it usually means the OCR text was stored as raster overlay rather than as a proper text layer — re-run OCR PDF on the compressed output to fix it.

Can the compressed output still meet PDF/A archival or PDF/X print standards?

Compress PDF aims for size reduction, not standards conformance. Some standard-required elements may survive (embedded fonts, structure trees) while others may be stripped (XMP metadata blocks marked as optional, the PDF/A identification flag, ICC output intents required by PDF/X). After compression, run the output through veraPDF for PDF/A or a Callas check for PDF/X to verify; if it fails, convert again with an explicit standards converter such as Ghostscript with `-dPDFA=2 -sProcessColorModel=DeviceRGB -dPDFACompatibilityPolicy=1`. The cleanest archival workflow is: compress first for size, then convert once at the end to lock in the conformance flag, the OutputIntent, and the DocumentID that long-term preservation systems use to deduplicate.

Why doesn't compressing the same file twice keep shrinking it?

After one pass, images are already encoded at the chosen quality level and Flate streams are already deflated near their entropy limit. A second pass cannot legitimately shrink data further without lowering visual quality — and most compressors won't lower it because the quality slider is set per-pass, not cumulative. You may see a tiny extra 1–2% saving from removing newly orphaned objects, or zero saving if the tool is idempotent. If you really need more shrinkage, lower the quality preset for the second pass (Medium → Low) or downsample image DPI explicitly. Repeated re-encoding of JPEGs visibly degrades them — each generation introduces ringing and colour banding — so prefer a single aggressive pass over many gentle ones.

Should I linearize the compressed PDF for fast web viewing?

Yes if you serve the file over HTTP and your viewer supports byte-range requests — which all modern browsers do. Linearization, defined in ISO 32000-2 section 7.5.4, reorders objects so the first page's content sits at the front of the file, letting a viewer render page one while the rest streams in. For a 50 MB textbook on a 5 Mbps connection, that turns a 80-second wait into a 1-second wait before users see something. Compress PDF does not linearize by default because it adds 1–2% to the file size; run the output through the Linearize PDF tool as a final step. For files served from cold storage or downloaded in full before viewing (e.g., email attachments), skip linearization and keep the smaller non-linear layout.

How does the tool handle ICC colour profiles and CMYK in compressed images?

Embedded ICC profiles (used for colour-managed workflows in print and high-end photo PDFs) are preserved through compression — they sit in the resource dictionary, not the image stream, so they survive a re-encode unchanged. CMYK images are kept in CMYK (re-encoded with JPEG-CMYK if the source was CMYK JPEG), which matters because converting CMYK to RGB and back is a lossy round-trip that shifts blacks and saturated greens. If you need to convert to sRGB for web display, do it explicitly with a colour-management tool before compression, not as a side effect. PDF/X-4 requires the output intent ICC profile to remain present and unmodified, so for press-ready files verify with Adobe Acrobat's preflight or a callas profile after compression to confirm the OutputIntent dictionary survived.