Shrink a PDF losslessly, resample its pictures, or rasterise it
Initializing in your browser…
Compress to a quality or to a file size, with the size shown being the encoded file to the byte and the cost measured on the pixels: SSIM, PSNR, the worst channel and the share of pixels changed.
Re-encode a video smaller with H.264 CRF, a speed preset that really reaches the encoder, and a downscale that keeps the shape. Measures a sample to predict the size, then shows what the file actually came out as.
Draw, type or upload a signature and place it on the page a reader sees, at a width you can state in inches, on one page or every page. Transparent, so it does not hide the line you are signing on.
An eight page report exported from a word processor is 28 KB per page and will not go through a size-capped portal.
Input
report.pdf 28,950 bytes · 8 pages, text on all 8, 0 pictures · lossless
Output
report.pdf 4,345 bytes (15% of the original) · text on all 8 pages, still selectable
The tool read the file and found 26,576 bytes of content streams stored with no compression at all, which is what a lot of PDF writers emit. Deflating them is the whole saving, and it cannot lose anything because nothing is decoded: the bytes that were there are re-encoded. Rasterising the same file would have made it larger, which is why that is a mode you pick rather than the only path.
There is no single way to make a PDF smaller, because there is no single reason a PDF is large. This compressor reads your file first and says what is in it: how many pages, how many of them carry real text, how many pictures there are and how much of the file they account for. Then it recommends one of three modes and tells you what each one costs. Lossless is the default and the right answer for most documents. It deflates whatever the file stores uncompressed and packs the objects together. Nothing is redrawn and nothing is resampled, so the text stays selectable, the fonts stay fonts and the vector graphics stay sharp at any zoom. On an eight page text document written with uncompressed content streams it produced a file 15 percent of the original size with every one of its characters still extractable. Resample pictures is for a report or a brochure where the photographs are most of the weight. It reduces the resolution of the embedded JPEGs to a target you choose in dots per inch, measured against the size each picture is actually drawn at on the page, and leaves the text and the vectors completely alone. Rasterise pages renders every page and stores it as a picture. That is the right answer for a scan, which is already pictures, and the wrong answer for everything else. The tool says so before you run it, tells you how many pages carry text you would be losing, and warns you afterwards if the result came out larger than what you started with, which is what happens when you rasterise a document of type.
Shrink a PDF below a size limit. Try lossless first: a document exported from a word processor is often mostly uncompressed streams, and deflating them alone can cut it to a fraction with nothing lost.
Resample the pictures to 150 dpi and leave the text alone, so the document is still searchable and the type is still sharp while the file is a fraction of the size.
Rasterise at a lower resolution, in grey, which is where most of the saving on a scan of a printed page comes from.
The analysis is structural and instant: no rendering and no worker. The tool walks the object graph with pdf-lib, sums the streams the file stores with a filter and without one, finds every image XObject with its stored pixel dimensions, and inflates each page content stream to look for a text-showing operator (Tj, TJ or the two quote forms). A page with no such operator has no text, whatever it looks like, and that is the fact that separates a scan from a document.
The lossless pass deflates every raw stream with CompressionStream in the zlib wrapping that /FlateDecode means, and saves with object streams on. It cannot change a pixel or lose a character, because it never decodes anything: it only re-encodes bytes that were already there.
The picture pass reads the placement matrix in each page content stream to find out how many points across each image is actually drawn, which is what makes a dots-per-inch target mean anything: a 1200 pixel picture is 216 dpi across 400 points and 2000 dpi in a thumbnail. It only touches JPEGs of one or three components, because a four component CMYK JPEG through a browser canvas comes out RGB and every colour on the page changes; anything skipped is counted and reported rather than passed over in silence. A picture already below the target resolution keeps its pixels.
The rasterise pass renders with PDF.js at the resolution you choose and places each picture on a page of the ORIGINAL size in points. Those are two different numbers and confusing them is a real failure mode: rendering US Letter at 150 dpi gives 1275 by 1650 pixels on a page that is still 612 by 792 points, and building the new page at the pixel count would turn an 8.5 by 11 inch sheet into a 15.3 by 19.8 inch one.
After any mode the tool reads its own output back with the same analysis it ran on the input, and shows you the page count and how many pages still carry text. That line is a measurement of the bytes that came out, not a promise about the mode. And a lossless or picture pass that would produce a file larger than the original returns the original instead and says why, because a compressor that hands back something bigger has not compressed anything.
In the lossless and picture modes, yes: neither one touches the text at all. In the rasterise mode, no, and the tool says so before you run it and shows how many pages carry text you would be losing. After any mode it reads its own output back and tells you how many pages still carry text, so you can see the answer rather than take it on trust.
Take the recommendation. It comes from the file itself: a document whose streams are mostly uncompressed gets lossless, a file where pictures are more than about a third of the bytes gets the picture mode, and a file with a picture on every page and no text at all gets rasterise.
It depends entirely on why it is large, which is why the tool tells you what is in it before you choose. A text document with uncompressed streams can drop to well under a fifth of its size losslessly. A file that is already fully compressed cannot be made smaller at all, and the tool will tell you that rather than producing something bigger.
Because a page of type is a few kilobytes of drawing instructions and a few hundred kilobytes of pixels. Rasterising is for scans. On a text document it will grow the file, and the tool warns you before and after.
No. Every mode keeps each page at its own size in points, including the rasterise mode, where the render resolution and the paper size are deliberately kept as two separate numbers.
PDF parsing and editing happen in your browser. Documents, and everything inside them, are never uploaded or stored remotely.