You can compress a PDF in your browser by running a local tool that re-encodes only the embedded JPG images inside the file and never offers a download unless the new bytes are smaller than what they swapped out. The file stays in your tab the whole time: there is no upload step, no server-side processing, and no account required. This is a narrower form of compression than a general-purpose PDF optimizer. Instead of guessing which stream to touch, the tool reads the PDF structure with the browser's PDF library, finds unmasked DCTDecode JPG image objects in DeviceRGB or DeviceGray color spaces, decodes each one through an in-browser image element, downsamples the longest side to 1400 pixels at JPEG quality 0.70, and only replaces the original when the new payload is genuinely smaller. Every other page element — text, fonts, links, forms, annotations, vector drawings, metadata, and unsupported image types — is preserved at the byte level. Because the change is bounded to eligible JPGs only, a text-only PDF usually cannot shrink at all, and the size of any reduction depends on what the source images and PDF overhead look like.
How browser PDF compression differs from online services
The phrase "compress a PDF in your browser" covers a specific technical setup: a tool whose read, transform, and write steps all execute inside the current browser tab using JavaScript libraries such as Mozilla's PDF.js for parsing and rendering, plus a low-level PDF library like pdf-lib for object manipulation. When a tool runs entirely client-side, the document you select never travels over the network, which removes the privacy and upload-time costs that come with most "online compressor" services. It also means the tool has hard limits tied to what fits in browser memory and the JavaScript runtime: a 25 MB ceiling on the source file, a cap of 80 eligible image objects, and roughly 100 megapixels of decoded image data across the run. Those ceilings are why the tool is positioned as a focused option for one image-heavy PDF at a time rather than a universal optimizer.
Browser-based compression in this sense is not the same as the heavyweight desktop PDF engines that can rewrite stream filters, recompress fonts, linearize objects, and target archival profiles. The browser method only knows how to change certain embedded image streams and verify that the rebuilt PDF still opens. Anything it cannot safely change — text streams, font subsets, vector operators, form widgets, annotations, encrypted payloads, JPX images, and the metadata dictionary — stays byte-identical. That narrower contract is also what makes it safe enough to run on a document you would rather not upload to a stranger's server.
How to compress a PDF in your browser
Open the Compress PDF tool in your browser tab. The whole flow runs locally in the tab you are looking at, and the only file the tool ever sees is the one you pick from your device.
- Click the file input and select one local PDF. The file must be at most 25 MB and must already exist on your computer; the tool does not pull anything from a URL.
- Choose Compress PDF. The tool loads the file with the browser PDF library, enumerates its image XObjects, and filters them down to unmasked DCTDecode JPG streams that use DeviceRGB or DeviceGray color data and have no decode parameters.
- For each eligible image, the tool decodes the JPG through a browser image element, draws it onto a canvas with the longest side capped at 1400 pixels, and exports a new JPG blob at quality 0.70.
- The tool compares the candidate blob's byte size to the original image stream. If the new bytes are not smaller, the original image stays in place. Nothing is force-replaced.
- The rebuilt PDF is reopened inside the same tab with the same PDF library plus PDF.js to verify the page count and confirm the structure parses cleanly. Only after that pass does a download surface.
- Read the reported input and output sizes. If the output is smaller, click Download. If the tool reports that nothing became smaller, no file is offered, which is the honest result for a PDF that has nothing eligible to shrink.
Which parts of a PDF this method touches and which it leaves alone
The boundary between "changed" and "preserved" is the central fact anyone using this tool needs to understand, because the output is not a wholesale rewrite of the document.
| Element in the source PDF | What the browser tool does |
|---|---|
| Unmasked DCTDecode JPG, DeviceRGB or DeviceGray, no decode parameters | Decoded, downsampled to a 1400 px longest side, re-exported at quality 0.70, replaced only when the new stream is genuinely smaller |
| DCTDecode JPG with a mask, CMYK, Indexed color, ImageMask, or any decode parameter | Left untouched |
| JPX (JPEG 2000) image streams | Left untouched |
| Page text, font references, links, vector drawings | Preserved at the byte level |
| Form widgets and page annotations | Preserved |
| PDF document metadata | Preserved |
| Page count | Preserved |
Because the tool replaces image streams at the same indirect object reference rather than rebuilding pages, the rebuilt PDF keeps the original layout, ordering, and references. The tradeoff is that any savings come entirely from the eligible image streams; nothing else in the file is reduced.
When this approach works and when it does not
The browser method is well suited to scanned PDFs and photo-heavy documents whose bulk comes from large embedded JPGs. A 25-page scan from a phone, a report full of embedded photos, or a slide deck exported with high-resolution JPG imagery are exactly the cases where a 1400 px longest side at quality 0.70 tends to beat the original, sometimes by a wide margin. The honest-error behavior — refusing to hand back a file when nothing shrank — is what you want in those cases, because it stops you from saving a "compressed" copy that is actually the same size or larger.
The approach is a poor match for text-only PDFs, contracts, forms without imagery, vector-only illustrations, and print-ready files. If a PDF is mostly text fonts and vector drawings, the tool has nothing eligible to touch and will return an error instead of a download. The same is true for PDFs whose imagery lives in CMYK color spaces, uses image masks, or is encoded as JPX. Those formats are deliberately out of scope because rewriting them safely is not something the tool can guarantee, and the tool prefers to skip them rather than guess. For documents where you need guaranteed lossless size reduction, archival conformance, or print color management, the browser method is the wrong choice.
When a desktop optimizer is still the right call
The browser tool is intentionally narrower than a full PDF optimizer. It does not linearize objects for streaming, recompress font subsets, deduplicate identical streams, convert color spaces, or target a specific archival profile such as PDF/A. It will not give you a guaranteed lossless result, because the JPG re-encoding step is by definition lossy even when the new payload is smaller. It also caps you at one file, 25 MB, 80 eligible image objects, and roughly 100 megapixels of decoded image data per run, so large manuals and image dumps need a different path.
For those jobs, install a specialist desktop optimizer such as Ghostscript or qpdf, or use a paid product that handles print color management and archival conformance. Keep the original file alongside the browser-compressed copy and inspect both before sharing the smaller version. Used that way, browser compression and desktop optimization are complementary rather than competing: the browser tool handles the daily case of an image-heavy PDF that just needs to drop below an email attachment cap, and the desktop tool handles the heavier, stricter jobs.
If you're weighing options, Plan the Steps Needed to Compress a PDF to Size covers this in detail.