Compressing a PDF to a PDF means keeping the same document format while making its file size smaller, and the Compress PDF tool does this in your browser by re-encoding only safely replaceable embedded JPG images, leaving every page, text run, link, and vector object untouched. The PDF never leaves the tab; the tool loads a local file up to 25 MB, scans it for DCTDecode JPG images in DeviceRGB or DeviceGray color spaces that have no mask and no decode parameters, decodes each eligible image to a canvas at a downscaled 1400-pixel longest side and JPEG quality 0.70, then swaps in the new bytes only if they are actually smaller than the originals. If no JPG can be replaced at a smaller size, the tool returns an honest error instead of a made-up download. Because it operates inside one PDF, the format never changes — your document stays a PDF, your pages stay the same length, and your annotations and metadata survive intact.

What Compress PDF Actually Does
The phrase compress PDF to PDF sounds redundant, but the format constraint matters: a PDF that turns into a folder of JPGs or a Word file is no longer a PDF. Compress PDF keeps the wrapper exact — same page count, same text layer, same hyperlinks, same vector outlines, same form fields, same metadata — and only swaps in smaller byte streams where it is mathematically safe to do so.
The tool does this by enumerating the embedded image XObjects inside one local PDF and deciding, image by image, whether to re-encode. Only a narrow class qualifies: an unmasked DCTDecode JPG whose color data is DeviceRGB or DeviceGray, with no exotic Decode array. Anything else — JPX and JPEG 2000, CMYK, Indexed color, masked images, ImageMask, or streams with custom decode parameters — is skipped rather than guessed at. That is why the tool is deliberately narrower than a general-purpose PDF optimizer: a true compressor that flattens fonts, rewrites cross-reference tables, or repacks streams is a different kind of beast, and the tool will not pretend to be one.
For the JPGs that do qualify, the work is careful. Each eligible image is decoded into a browser canvas, the longest side is scaled down to 1400 pixels, and the result is re-encoded at JPEG quality 0.70. If that new byte stream is not actually smaller than the original payload, the original stays in place. The replacement happens at the same indirect object reference, so every page that displayed the image continues to display it — just at a smaller payload.
Compress a PDF Step by Step
The whole flow runs in one browser tab on a single local file. No account, no plug-ins, and no upload step.
- Open the Compress PDF tool in your browser and click the file picker. Choose one local PDF of 25 MB or smaller — larger inputs are rejected before processing starts.
- Select Compress PDF. The tool enumerates embedded image XObjects and keeps only those that match the eligible class described above.
- Wait while each eligible JPG is decoded, downscaled to a 1400-pixel longest side, and re-encoded at JPEG quality 0.70. Each new byte stream is compared to its original, and smaller ones are slotted in.
- Review the reported input size and output size that appear when processing finishes. If the output is smaller, a download link is exposed; if no eligible image could be safely shrunk, the tool reports that fact instead.
- Click download and save the new PDF next to the original. Because the output was reopened and verified before the link appeared, a malformed result cannot pose as a success. Keep the original on disk until you have eyeballed the compressed copy in a normal PDF reader.
Which PDFs Get Smaller (and Which Don't)
Whether a given PDF shrinks depends on what is actually inside it, not on the filename or extension. Image-heavy scans and photo-laden brochures tend to compress well; text-only drafts and pages built from vector art tend to stay the same size. The table below summarizes the typical cases the tool is built for.
| Document scenario | Typical outcome | Why the tool responds that way |
|---|---|---|
| 20-page scan with full-page photos | Often smaller | Lots of eligible DeviceRGB or DeviceGray JPGs to re-encode |
| Brochure with a handful of large hero images | Often smaller, but smaller | Only those JPG payloads change; text and vectors are untouched |
| Text-only report or draft | Usually no change | No replaceable embedded JPG image objects exist |
| Scanned archive stored as CMYK JPEGs | No change | CMYK color data is skipped on purpose, not silently re-encoded |
| Document with masked or ImageMask artwork | No change | Masked and ImageMask streams are not eligible |
| Page built purely from vector illustrations | No change | There are no JPG image XObjects to replace |
If your document is mostly text, the tool will not invent a smaller version — it returns a clear message instead. That refusal is the honest answer; size on disk cannot drop without dropping pixels, and dropping pixels without transparency about it would be a worse outcome than staying the same size.
Hard Limits Worth Knowing
The bounded shape of the tool is deliberate, and the caps are easy to remember once you see them together.
| Limit | Value |
|---|---|
| Maximum input PDF size | 25 MB |
| Maximum eligible image objects per file | 80 |
| Maximum decoded pixels across all eligible images | 100 megapixels |
| Accepted JPEG flavors | Unmasked DCTDecode, no decode parameters |
| Accepted color spaces | DeviceRGB, DeviceGray |
| Re-encoding target | 1400 px longest side at JPEG quality 0.70 |
| Processing location | Current browser tab only |
If any one of these caps is exceeded, processing stops early with a message rather than producing a half-finished file. A single 5,000 × 3,000 cover photo already consumes 15 of those 100 megapixels on its own, so a photo-laden PDF is much closer to the cap than its raw byte size suggests.
When You Need a Heavier Compressor Instead
This tool is the right call when you have a photo-heavy PDF that you want to shrink locally and the loss of a small amount of image detail is acceptable. It is the wrong call when you need lossless guarantees, CMYK workflows, archival PDF conformance, ICC color management, or arbitrary stream repacking. In those cases, reach for a specialist desktop optimizer that targets those pipelines directly.
Within the same in-browser toolbox, adjacent tasks fit different tools. If blank margins are inflating page count, cropping the page itself trims bytes that the JPG re-encoder cannot touch. If a few unwanted pages bloat the file, removing them shrinks the document without altering any pixel. To chunk a large PDF into pieces sized for an email attachment, a split-by-size pass handles the distribution. To inspect what actually lives inside before you compress, counting pages or pulling the embedded photos out as separate JPGs gives you a clear view of where the bulk sits.
For most day-to-day "this scan is too big to email" cases, the JPG re-encoder inside Compress PDF is enough — open the page, drop in the file, watch the input and output numbers, let your browser do the work, and keep the original alongside the compressed copy until you have eyeballed the result. The output is reopened with the PDF.js viewer before the download link is exposed, so the worst-case outcome is a clear error rather than a silently broken PDF.