Shrink a PDF without uploading it

A PDF is mostly pictures. This reads your file on your own machine, re-encodes every image inside it, rebuilds the document's table of offsets, and hands you back a smaller file with your text still selectable. Measured on a four-photo document: 55% smaller.

How do I make a PDF smaller, or compress a PDF, without uploading it? The words inside a document were compressed long ago — the pictures were not, and they are where the bytes are. This reads your file on your own device, re-encodes the images in your browser, and hands you back a smaller file. A PDF too large to email, or one that keeps running into a file size limit or an attachment limit, is the common case here: the document never leaves your machine, and the whole job is done locally.

  • Nothing is uploaded
  • Text stays selectable
  • Works offline
  • Unlimited & free

Drop your PDF here

or paste from the clipboard

PDF — one file at a time, no size limit, nothing leaves your device

Compression settings

Applied when you run it
lower is smaller; 60 is the measured default
60

What we measured, and what it means

Three documents were printed to PDF by the same browser and then run through this tool — the same way you would shrink the PDF by hand, only without the upload. The images were re-encoded at quality 60 with no downscaling, which is the default on the form above.

  • Reduce the size of a PDF by re-encoding its pictures, and the rest of the file comes along untouched. That is what you want when you reduce the PDF size: the images are the only thing that has to change, and the words, the fonts and the page order do not. Here is what that actually looks like on measured files.
  • Four photos, four pages — 1,689,943 bytes → 761,064 bytes (−55%). The images inside were 99.3% of the file, so the rest of the document moved by almost nothing. Nothing but the picture bytes was touched.
  • One photo with body text around it — 299,733 bytes → 135,558 bytes (−54.8%). This is the ordinary case: a report or a deck where most of the bytes sit in one picture.
  • Text only, no pictures at all — 11,381 bytes, unchanged. The tool counted no image streams, so it returned the original file byte for byte instead of inventing work to do.
  • Same four photos, capped at 1000 px — 242,999 bytes (−85.6%). Downscaling buys far more than re-encoding when scans are printed much larger than the page.

The method, the fixtures and the per-image figures are kept with the rest of the project's measurements: three A4 documents generated by the browser's own print-to-PDF, seeded so a re-run lands on the same numbers, with every image re-encoded by this site's own encoder.

How it works

Whether you want to compress a PDF, shrink a PDF, or optimize the PDF before you send it, the job is the same: the size sits in the pictures — the same thing that happens when a scanner produces a PDF, or when you compress a PDF on a laptop someone lent you. Most of the services that promise to optimize a PDF start by uploading your file first; this one reads it on your device instead.

  1. The file is read on your machine. No upload step exists, so there is nothing to wait for and nothing to leak.
  2. The document's objects are walked. Every N 0 obj … endobj is read, and the tool picks out the image objects — the ones stored as a plain JPEG with no alpha channel attached.
  3. Each image is decoded and re-encoded. Through the same compression engine this site uses for photos, at the quality you chose.
  4. The document is written back out. Image streams are swapped in, the byte count in each dictionary is corrected, and the table of offsets at the end of the file is rebuilt from the offsets actually written — because a stream that changed length moves every object after it.

If the file turns out to be encrypted, or its images are packed inside compressed object streams where many objects share one stream, the tool says so and gives you the original back rather than guessing at a format it cannot see.

Frequently asked questions

Why does making a PDF smaller usually work so well?

Because a PDF from Word, Google Docs, Keynote, a scanner or a browser print has already compressed its text once, and pictures are what came back big. It is also why compressing a PDF a second time does nothing: the pictures have already been re-encoded once, and there is nothing left in them for a third pass to take. On a four-photo A4 document we measured, the images were 99.3% of the file. Re-encoding those images brought 1,689,943 bytes down to 761,064 — 55% smaller — while the text, the fonts and the page structure were copied through untouched. A document with one photo and body text around it went from 299,733 bytes to 135,558, which is the same 55% and the more everyday case.

Will my text still be selectable?

Yes. Only the image streams are replaced. You keep the text, the fonts and the page order exactly as they were, and every other object — the page tree, the outlines, the content streams that draw the words — is carried over the way it was, after which the file's cross-reference table is rebuilt from the offsets actually written. That table is exactly what a viewer uses to find each object, which is why it has to move when a stream changes length. The result still has selectable, searchable text and the same page count.

My PDF came back exactly the same size. What happened?

It means the file had nothing to re-encode, and the honest thing to do is say so rather than ship you a bigger file. A PDF made entirely of text — a form, a report, a contract — contains no image streams at all, so there is nothing to take bytes from and the original is handed back byte for byte. The same thing happens to individual images the tool cannot safely touch: ones with an alpha channel attached, ones that are one-bit masks, ones that the browser's decoder refuses. Those are counted in the result line.

Does it work on encrypted or password-protected PDFs?

No, and it refuses rather than guessing. If the document is password protected, or carries an encryption dictionary, the file is passed back exactly as it came in: the stream lengths and offsets are no longer readable in plain text, and any change would produce a document that will not open. Passwords that only open a file for viewing do not stop us — but a document that was encrypted is left alone, and the page says so instead of pretending.

Is my PDF uploaded to a server?

No. The file is read into the page with the browser's own file reader and every step — reading the structure, decoding each embedded image, re-encoding it, rebuilding the offsets — happens on your machine. There is no server-side component that accepts a PDF. The page does load a compression engine from this site's own assets, and optionally pulls optional WASM codec modules from a public CDN when they are reachable; neither ever sees your document.

Does it downscale my photos as well as re-encode them?

Only if you ask it to. The maximum edge setting is off by default, so images keep the pixel dimensions they have; only the quality changes. Setting a maximum edge is the way to squeeze a document where the photos are scanned far larger than the page needs — at a 1000 px cap on the four-photo test file the whole document came out at 242,999 bytes, which is 86% smaller. Images below the cap are never touched.

What happens to the document's metadata, like the title and author?

You choose. Keeping metadata leaves the file's XMP and document-information objects in place, which matters if the title, author or keywords have to survive the round trip. Unticking it drops those objects and the catalog's reference to them, which is worth a few hundred bytes on a large file. Either way the rest of the document is unaffected.