utilime

Your file never leaves this tab.

Compress a PDF

Shrink a PDF by re-encoding the images inside it — and hear it plainly when there is nothing to gain.

Drop a file hereor click to choose · it stays on your device

How it works

A PDF is a container, and what makes one large is almost always the raster images inside it. Text is cheap: a few thousand characters a page, plus one subset of each font used. Font subsets are the second-largest cost in a text document, commonly tens of kilobytes for a Latin face and considerably more for anything carrying CJK coverage. Images are not cheap, and quite how expensive depends on how they were stored.

Where the bytes actually sit

Two real documents measured here: a 4-page colour scan came to 2.6 MB, about 655 KB a page, while a 500-page book scanned to JPEG 2000 came to 17 MB, about 35 KB a page. That is nearly nineteen times the cost per page for the same kind of content.

Duplicated resources are a third contributor, since assembling a file page by page in some tools embeds the same logo, or the same font, once per page instead of once per document. So the useful first question is not how to compress your PDF but what is taking up the room, and the answer usually follows from where the file came from: if it was scanned or photographed there is a great deal to win here, and if you typed it there is very little.

Repacking structure is a coin flip

Rewriting a PDF's structure (repacking the object table, storing objects in compressed streams, rebuilding the cross-reference table) is not where compression lives, and it is not even reliably in your favour. Measured across fourteen real documents pulled from a downloads folder rather than generated for the test, an unmodified load-and-save ranged from 35.7% smaller to 87.0% larger, with most files landing inside a single percent either way. A 2-page state tax filing lost a third of its bytes; a 127-page typeset document of 441 KB came back at 824 KB.

Gzipping both ends of every case moved the numbers far less, between 2.2% smaller and 5.5% larger, which says the swing is redundancy being written differently rather than compression being lost. The files that inflate badly all use compressed object streams, but having them does not predict inflation: one document with four of them shrank by 14.9%. There is no rule here that a tool could apply in advance. That is exactly why this one measures its own output against your original and gives you back whichever is smaller, and why a structural rewrite is never presented as the point.

What a 90% claim really means

When a site advertises 90% off a text PDF it is not repacking anything: it is rasterising the document, replacing every page with a JPEG and discarding the text layer. That is a legitimate operation with a large and specific cost, so it is a named mode here rather than the default.

After rasterising, text cannot be selected, searched, copied or read aloud by a screen reader, links and bookmarks are gone, form fields flatten to a picture of whatever they contained, and each page becomes the size of its visible area, so a print-ready sheet carrying trim and bleed outside its crop box comes back cropped to what a reader actually sees.

Quality against pixel count

In the default mode the lever is the images, and there are two ways to pull it. Reducing JPEG quality keeps every pixel and stores each one less precisely. Downsampling keeps the precision and stores fewer pixels. That is usually the bigger win, because pixel count falls with the square of the dimension: halving the width halves the height with it, so three quarters of the samples are gone before the encoder does any work at all.

A 4000-pixel-wide scan reduced to 1600 pixels has 84% fewer samples, and 1600 pixels across a Letter or A4 page is still roughly 190 dots per inch, finer than a screen can show and adequate for ordinary office printing. Reach for width first and quality second. Below about 50 on the quality scale, blocking becomes visible around the edges of text in a scan, which is exactly where a reader is looking.

Greyscale is the third lever and it applies to documents that were never in colour: converting a scan of black text on white paper drops the two chroma channels, which takes a useful bite out of typical scanner output at no cost to anything you were using.

What is skipped or refused

Not every image can be re-encoded, and this tool reports what it left alone instead of counting it quietly as success. It re-encodes JPEG image objects: the `DCTDecode` filter, which is what colour and greyscale scanners emit and what phones and cameras produce. Everything else it names and skips. Bilevel scans stored as `CCITTFaxDecode` or `JBIG2Decode` are already near optimal for black-and-white line work.

JPEG 2000 (`JPXDecode`) has no browser decoder, and it is not a rare case: in a real 500-page scanned book measured here, 129 of the 140 images were JPEG 2000, so that document reports nothing re-encodable rather than a saving it did not make. Four-component CMYK JPEGs cannot be round-tripped through a browser decoder without shifting colour. Soft masks carry an image's transparency and are required to stay greyscale. And any image whose samples are remapped by a `/Decode` array or a colour-key mask is left alone, because re-encoding changes what the mask matches.

Encryption deserves a note of its own, because two unlike things get the same name. A file locked only against printing or editing opens without anyone being asked for anything and is compressed normally, while one that needs a password to open is refused, and you are never asked for a password.

In one real downloads folder of 516 PDFs, every one of the 8 that carried encryption was the first kind, which is a sample rather than a statistic but matches what the two kinds are for. Rewriting a permissions-locked file can drop those restrictions from the copy you download.

Documents to leave uncompressed

Finally, there are documents that should not be compressed at all: anything going to a commercial printer should go at its original resolution, anything about to be run through OCR should be compressed afterwards rather than before, since artefacts around character edges measurably reduce recognition accuracy, and anything that has to stay accessible rules out rasterising outright. A screen reader cannot read a picture of a sentence.

Questions

Is my PDF uploaded?

No. Open developer tools, switch to the Network tab, and compress a document: you will see the code and codec chunks download once, and no request carrying your file. The PDF is read into memory by this tab, re-encoded by WebAssembly running in a Web Worker on your own machine, and written back out as a download. There is nothing to delete afterwards because nothing was ever received.

Why did my file come back exactly the same size?

Because nothing this tool could do to it made it smaller, so you got your own file back rather than a worse one. That happens when a document holds no raster images, when its images are already compressed harder than the settings you chose, or when rewriting its structure inflates it, which on real files ranges from a third smaller to nearly twice the size and cannot be predicted from the file in advance, only measured. Individual images are treated the same way: one is replaced only when its re-encoded version is genuinely smaller. The result note says which of these happened.

Will my text still be selectable and searchable?

In the default mode, yes. Text, fonts, vector graphics, annotations and page geometry are not touched at all; only the pixels inside embedded photographs change. In the rasterising mode, no: each page becomes a single JPEG, so there is no text layer left to select, search, copy or read aloud, and no bookmarks or working form fields. That mode exists because it is the only way to get a large reduction from a text-heavy PDF, and it is never chosen for you.

Is the output good enough to print, or to run through OCR?

For ordinary office printing, yes: 1600 pixels across a page is about 190 dpi and prints acceptably. For commercial printing, send the original; a print shop wants full resolution and will usually specify what it needs. For OCR, recognise the text first and compress afterwards: compression artefacts around character edges cost accuracy, and a page you have already flattened cannot be un-flattened.