Compress PDF

Shrink PDFs by downsampling images and merging duplicates

1Choose file2Settings3Process4Save

Choose a PDF and its contents will be analyzed and shown here.

Files are processed only in this browser. Nothing is uploaded to a server.

Shrink a PDF by downsampling and recompressing images and cleaning up duplicate resources

Continue in another tool
Task settings
Compression settings
For screen and print. Images above 150 DPI are reduced and JPEGs are recompressed at quality 75.

Remove the password from an encrypted PDF first. The whole file is rewritten, so any existing digital signature becomes invalid. Keep the original and check the result.

About Compress PDF

This tool doesn't re-render your PDF. It opens the objects inside the file one by one and swaps in smaller versions. The PDF structure is read and written with pdf-lib, Flate compression is done with fflate, and JPEG decoding and re-encoding go through the browser's canvas. There's no bundled WASM engine such as Ghostscript, so jobs that need one, like font subsetting or JBIG2 re-encoding, aren't attempted.

Most of the savings come from images. The tool walks each page's content stream, tracks the transformation matrix, and works out how many inches each image actually occupies on the page. That gives the placed DPI. Only images above 1.15 times the target DPI are downsampled, and a new stream replaces the old one only if it is smaller. If the finished file comes out larger than the input, you get the original back unchanged.

That last rule matters more than it sounds. Plenty of PDFs are already well optimized, and naive re-saving can make them bigger. The tool would rather give you nothing than a worse file.

What each stage actually removes

The work happens in five passes. Each pass targets something different, so the images / fonts / other breakdown in the analysis tells you in advance where the savings will come from.

  • Extras: XMP metadata, page thumbnails and editor-private /PieceInfo data. PDFs saved from Illustrator with editing capabilities carry a full copy of the native artwork in /PieceInfo, and removing it alone can cut the file by half or more.
  • Images: anything above the target DPI is reduced with a box filter (pixel averaging). Color JPEGs are decoded and saved as JPEG again. Lossless 8-bit gray or RGB images (Flate or uncompressed) are re-deflated at level 9 with a PNG row predictor (Predictor 15). On Recommended and Strong, lossless color images are also tried as JPEG, and JPEG wins only if it is less than half the lossless size. Grayscale stays grayscale: the browser's JPEG encoder only writes color (RGB) JPEGs, so a gray JPEG is tried as 1-channel lossless (Flate) and replaced only when that is smaller, and lossless gray images are never turned into JPEG.
  • Other streams: page content and font streams that are uncompressed or plain Flate are recompressed at level 9.
  • Deduplication: byte-identical streams and identical Font, FontDescriptor and ExtGState dictionaries are merged. This pays off on files glued together from many PDFs, where the same logo and fonts appear once per source file.
  • Cleanup and save: unreachable objects are dropped and the file is written with object streams, a PDF 1.5 feature that packs many small objects into one compressed stream.

Why placed DPI matters more than pixel count

The same 4000×3000 photo is about 340 DPI when it fills a letter or A4 page, and well over 1000 DPI when it's squeezed into a business-card-sized box. Even commercial print rarely needs more than 300 DPI, so in the second case most of those pixels are thrown away by the printer anyway. That's why the tool judges images by how big they're drawn, not how many pixels they have. If the same image is used in several places, it takes the lowest DPI, meaning the largest placement, so the image doesn't turn soft where it's shown biggest.

An image that is never actually drawn on a page has no placed DPI, so it is left out of JPEG recompression. Soft masks, which carry transparency, are scaled by the same factor as their parent image so edges stay aligned, and they are never turned into JPEG.

PDFs that barely shrink

When a file refuses to get smaller there is almost always a structural reason. The per-component table in the result shows which part stayed the same.

  • JPEGs already at a sensible resolution. Re-encoding a photo stored near 150 DPI at quality 75 saves only a few percent, and the tool won't swap it unless the new JPEG is under 90% of the old one. Repeated JPEG saves only cost quality.
  • Font-heavy documents. A CJK font embedded in full instead of as a subset can be several megabytes on its own. This tool doesn't subset fonts, so the fix is to re-export from the source app with embedding limited to the characters used.
  • Vector-heavy drawings and maps. Hundreds of thousands of path segments show up as content stream bytes. If they're already Flate-compressed, pushing to level 9 gains a few percent at most.
  • Image types the tool leaves alone: JPEG 2000 (JPX), JBIG2, CCITT fax, CMYK images, 16-bit images and indexed-color images. A black-and-white scan that the scanner already saved as JBIG2 is tiny to begin with, so there's little left to gain.

What downsampling can break

In a scanned document the text is part of the image too. Take a contract scanned at 300 DPI down to Strong (96 DPI) and 9-point type starts to smear, which can also break OCR or automated checks at the office receiving it. Grayscale scans that get re-encoded as JPEG come out as RGB JPEGs, because that's what the browser encoder produces. If your submission rules say black-and-white only, check the result in print preview.

The file is rewritten, so any digital signature becomes invalid. If a signed PDF is too large, compress the unsigned version first and sign afterwards.

Worked examples

Phone photos filling a page in an expense report

Input
A 4000×3000 photo fitted to the width of an A4 page (8.27×11.69 in), Recommended (150 DPI, quality 75)
Output
Placed DPI ≈ 342, reduced to about 1316×1754

Horizontally 3000/8.27 ≈ 363 and vertically 4000/11.69 ≈ 342. The lower value, 342, is the placed DPI. It's above 150 × 1.15 = 172.5, so the image is scaled by 150/342 ≈ 0.44 and keeps about 19% of its pixels. JPEG size roughly tracks pixel count, so expect the image to land near a fifth of its former size. On Strong (96 DPI) it becomes 842×1123, about 8% of the pixels.

A report that's already lean

Input
30-page report exported from Word, 2.1 MB; analysis: fonts 78%, images 12%
Output
A few percent saved, or the original returned

Even deleting every image would only save 12%. The weight is in fonts embedded without subsetting. Turning on Word's option to embed only the characters used in the document and exporting again will do far more than any compressor setting.

An image just over the target

Input
A photo placed at 170 DPI, Recommended
Output
Not downsampled; only a quality-75 re-encode is tried

170 is below the 172.5 threshold. Shrinking an image that is barely over the target saves little and still costs a resampling pass, which is why the margin exists. If the re-encoded JPEG isn't at least 10% smaller, the original JPEG stays.

How to use it

  1. Add the PDF and check the images / fonts / other split and how many images exceed the target DPI.
  2. Choose Light (220 DPI), Recommended (150 DPI) or Strong (96 DPI), or set DPI and quality yourself.
  3. After running, compare the per-component sizes and zoom into photos and small print in the preview.

Key terms

Placed DPI
An image's pixel count divided by the size in inches it's drawn at on the page. It's calculated from the actual placement, not from resolution metadata in the image.
Object stream (ObjStm)
A PDF 1.5 feature that groups many small objects into a single stream so they're compressed together. The cross-reference table is then stored as a stream too.
PNG predictor
A pre-pass that stores each row as differences from neighboring pixels so Flate compresses it better. PDF's FlateDecode supports it through Predictor values 10–15.

Frequently asked questions

Does compressing a PDF make the text blurry?

Real text is vector and isn't touched. Only text that lives inside an image, as in a scan, loses sharpness along with the image resolution.

Will running it twice make the file smaller?

With the same settings, hardly at all. The images are already at or below the target DPI, and re-encoding is only kept when it saves at least 10%.

Why won't my black-and-white scan shrink?

If the scanner saved 1-bit images as CCITT or JBIG2, the tool leaves them alone, and they're usually small already. Grayscale or color scans do shrink when you lower the DPI; watch the readability of small print while you adjust. Gray JPEGs are only re-saved losslessly so they stay gray, which means that without a lower DPI they are often left as they are.

Do bookmarks and links survive?

Page structure, bookmarks, links and form fields are kept. Metadata removal deletes the XMP packet, so a PDF/A conformance claim goes with it.

Why is the result sometimes identical to my original?

If the rewritten file isn't smaller than the input, the tool returns your original bytes rather than a larger or equal file.

Related guides

Sources

Last reviewed:

Privacy and how data is handled