Compress PDF

Is my file uploaded anywhere?

No. The PDF is read by JavaScript inside this browser tab, its images are recompressed with pdf-lib, a WebAssembly build of MozJPEG, and a WebAssembly build of oxipng, and the result comes back as a blob URL your browser creates locally. Nothing is sent to a server, so there is no upload to intercept and no copy left anywhere to delete. Open your browser's developer tools, switch to the Network tab, and run the tool — you will see no request carrying your file, and it keeps working with the network disconnected.

Why didn't my PDF get smaller?

Because a PDF that is mostly text was never big to begin with, and this tool cannot make text smaller — it only recompresses embedded images. We measured this directly before building the tool: running structural PDF compression (rewriting object streams, deduplicating fonts) on real files shaved 0.2% off a 924 KB text-heavy PDF and 1.8% off a 284 KB certificate. What actually makes a PDF large is a scanned page saved as a full-page photo, or a screenshot pasted into a report at its native resolution, and those are what is worth compressing. If your file has few or no qualifying images (see the next question for exactly what qualifies), expect little or no change — the tool says so honestly in the result rather than claim a saving that did not happen. Two real production files measured while building this: a signed contract's digitally-stamped signature image and a government tax form's scanned photo both recompressed, one file with 262 embedded images (mostly small logos and signature stamps) went from 2.2 MB to 1.9 MB, and a report full of full-resolution screenshots went from 9.2 MB to 817 KB — a 91% reduction, because every one of its 17 images was a screenshot far larger than the page needed.

What exactly does it recompress, and what does it leave alone?

Two kinds of embedded image, decoded two different ways. First, anything whose /Filter is DCTDecode — already a JPEG, decoded with the browser's own JPEG decoder. Second, anything whose /Filter is FlateDecode — raw, uncompressed pixel samples that were simply zlib-deflated, which this tool decodes itself: unpacking bit depths of 1, 2, 4, 8 or 16 bits per component, undoing a PNG-style row predictor when one was used (Predictor 10–15 — very common when the PDF was built from a PNG, as LibreOffice and many screenshot-to-PDF tools do), and interpreting DeviceGray, DeviceRGB, DeviceCMYK, CalGray, CalRGB, ICCBased (by its declared component count) and Indexed (palette) colour spaces. An image with its own alpha channel (/SMask) is combined into the result too, but only when that mask is itself a same-size FlateDecode DeviceGray image — an alpha channel encoded as a JPEG, or one whose pixel dimensions do not exactly match its base image, is a shape this tool has not verified it can combine correctly, so the entire image is left untouched rather than risk silently losing its transparency. Left untouched for the same reason: any TIFF-style predictor (value 2), any non-default /Decode array, any /Mask (a stencil or colour-key mask, as opposed to a soft /SMask), any filter chain like [/ASCII85Decode /FlateDecode] rather than a plain FlateDecode, and any image whose colour space cannot be classified into one of the kinds above (Separation, DeviceN, Lab, and any Indexed image built on a DeviceCMYK base). The result screen always says how many images were recompressed and how many were left as-is, so none of this is hidden.

Is this lossy? Will my scan look worse?

It depends on what kind of image it is. A continuous-tone photo or scan — DeviceGray, DeviceRGB or DeviceCMYK, no transparency — is re-encoded as a JPEG, which discards image data every time it runs; even at high quality, re-encoding a JPEG that was already compressed once loses a little more than the first pass did. The quality slider trades file size for fidelity directly, and text inside a scanned page is usually still legible well below the point where a photograph starts looking rough. A DeviceCMYK image is additionally converted to RGB using the same approximation every viewer without a full colour-management engine falls back to, which is not colour-accurate — printed-colour proofing is not what this tool is for. An image with an alpha channel, or one using a palette (Indexed) colour space — an icon, a logo, a flat-colour graphic — is instead re-encoded as an optimised, lossless PNG: no pixel data is discarded, only the compression itself gets smaller, which is also why those images sometimes barely shrink or occasionally don't shrink at all. Either way, this tool never trades a smaller resolution claim for a bigger file: if the recompressed version would be larger than the original bytes, the original is kept and the image counts as unchanged, not recompressed. If you need the original pixels preserved exactly, keep a copy of the source file before compressing.

What does the resolution cap do?

It downsamples an image's pixel dimensions to a target DPI, on the assumption that — as a scanned page or a full-page screenshot normally does — the image fills the page it sits on. For documents meant to be read on a screen rather than printed, 150 DPI is usually indistinguishable from the original and is by far the biggest lever for shrinking a scanned or screenshot-heavy document, larger than the quality slider alone. It applies to both JPEG- and PNG-encoded images alike. If an image is not directly referenced by any page's own resources (nested inside a form, for instance), the cap is skipped for that image and only the quality setting applies.

Will the page count or layout change?

No. This tool never touches a page's content stream — the instructions that place text, drawings and images on the page — so nothing about where things sit, how many pages exist, or what text says can change. Only the bytes of the qualifying images themselves are replaced, in place, at the same reference the rest of the file already points to. The one structural change this tool does make on purpose: when an image's transparency mask is folded into a single combined PNG, the old separate mask object it replaces is deleted from the file rather than left behind as dead weight — measured on a real 262-image PDF, skipping that cleanup step alone made the "compressed" output 7% larger than the input.