A target-aware PDF compressor offers a download only when the saved file's actual byte count is at or below the MB value you typed in. That distinction — comparing the real saved bytes to your target rather than estimating from the source — is what separates a verified result from an approximate one. Compress PDF to Size is built around that rule: it loads your file in the browser, runs a bounded sequence of recompression attempts on eligible JPG streams, saves each candidate, and measures the saved bytes against the target. If none of the bounded profiles produce a file at or below the target, the tool does not show a download at all. There is no "approximate" success message, no download that misses by a few hundred kilobytes, and no silent fallback to a smaller-than-asked result. For readers who have watched other "compress to X MB" tools quietly deliver something else, that gate is the entire point of the tool.
Why "compress to X MB" tools often miss the target
Most PDF compressors that advertise a target MB output rely on rough estimates instead of actual byte counts. The most common shortcuts: dividing the source size by an arbitrary ratio, declaring success based on a quality setting rather than the real output, or simply delivering the best the engine could manage and labeling it "target met." The reader searching for whether a download always meets the target has almost certainly been burned by one of these shortcuts — a file arrives labeled 5 MB but opens at 5.4 MB, or the slider stops early and the result is left vague.
The gap between the requested target and the actual delivery comes down to how success is measured. A tool that checks the saved file's real byte length against the target behaves very differently from one that compares a derived estimate to the source. Only the first produces a verifiable answer, and only the first can honestly refuse to show a download when the target is unreachable inside safe bounds. The same logic is why Compress PDF to Size was built around a single rule: no download link appears unless the actual saved file is at or below the requested MB.
What happens before the download button appears
The verification is the whole story. When you load a PDF and pick a target, Compress PDF to Size reads the file inside your browser using the PDF.js reader documented in the Mozilla PDF.js API, identifies the JPG streams it can safely rewrite, and runs a bounded sequence of recompression profiles. Each profile re-encodes eligible images at a fixed JPEG quality and longest-side setting, saves the resulting PDF, and compares that candidate's actual byte length to your target.
Four profiles are tried in order: 0.70/1400, 0.55/1000, 0.40/800, and 0.30/600. As soon as one of these produces a saved file whose byte count is at or below your MB target, the tool reopens that file and verifies the page count matches the original. If both checks pass, the download link appears. If none of the four profiles crosses the target, no download is offered and the tool tells you that the target cannot be reached safely. There is no fallback to the closest attempt, no "approximate" label, and no silently oversized result.
How to compress a PDF to an exact target size
- Open Compress PDF to Size and choose one local PDF up to 25 MB. Files larger than 25 MB are out of scope, so split or trim the source first if you need to work with a larger document.
- Type a target between 0.1 and 25 MB. The target must be smaller than the source file — the tool never grows a PDF. A 12 MB report with embedded JPGs might aim for 4 MB; a 6 MB scanned contract might aim for 1.5 MB.
- Select "Compress to target size" and wait while the bounded profile sequence runs. Each profile encodes eligible JPGs through the browser canvas pipeline described in the WHATWG canvas toBlob specification, saves a candidate PDF, and measures its real byte length against the target you typed.
- Watch for the download link. It appears only when a candidate passes both checks: saved bytes at or below the target, and a reopened PDF whose page count matches the original.
- If no download appears, the tool explains that the target cannot be reached safely inside the bounded profiles. You can then either raise the target slightly, retry with a different source, or read the limitations section below to understand why.
All processing happens in your browser, so the file is never uploaded. The only network activity is loading the tool page itself.
When the tool will not produce a download
Three situations will produce no download even when the request is valid. First, the PDF is text-only or vector-heavy with no eligible JPG streams to rewrite. The tool has nothing to compress, and the file size cannot move toward the target. Second, the source is dominated by image objects the tool does not touch — masked DCTDecode streams, images with decode parameters, CMYK JPEGs, or non-DCT formats such as PNG, JBIG2, or CCITT-encoded scans. Third, the required reduction exceeds what safe JPG recompression can deliver; even at the most aggressive bounded profile of 0.30/600, the eligible streams cannot shrink far enough to reach the MB you entered.
A scanned PDF — where every page is essentially one large JPG produced by a flatbed — usually has plenty of eligible streams and can often reach a much lower target than a hybrid PDF with mixed text and images. A textbook with vector diagrams, font subsets, and a handful of inline JPGs will usually reach only a modest reduction before the tool stops trying. The tool's design treats that "stops trying" outcome as a feature rather than a failure, because guessing at success would defeat the verification promise.
Which images the tool rewrites and which it preserves
| Image object in the source PDF | What the tool does | Why |
|---|---|---|
| Unmasked DCTDecode DeviceRGB JPG, no decode parameters | Rewrites with the current profile's quality and longest-side | Safe to re-encode; visual change stays predictable |
| Unmasked DCTDecode DeviceGray JPG, no decode parameters | Rewrites with the current profile's quality and longest-side | Safe to re-encode; visual change stays predictable |
| DCTDecode JPG with an explicit mask or SMask | Skipped | Masks define transparency the encoder cannot preserve safely |
| DCTDecode JPG with decode parameters | Skipped | Decode parameters invert or remap color; re-encoding would change appearance |
| CMYK DCTDecode JPG | Skipped | Tool targets DeviceRGB and DeviceGray only |
| PNG, JBIG2, CCITT, Flate-encoded image streams | Skipped | Not DCTDecode, so not handled by this recompression path |
| Candidate JPG that would be larger than its original stream | Left untouched in that image | Tool never enlarges an individual image stream |
The cap of 80 eligible images and 100 megapixels across all decoded images is the practical ceiling on a single run. A PDF where every page is a single huge scan counts as many images but can use up most of the megapixel budget on the first few pages. Page structure, selectable text, links, forms, vectors, and unsupported objects remain untouched throughout, so what is changed is only the JPG payloads listed in the table above.
Local-only processing and what that means for verification
PDF reading, JPG decoding, JPEG re-encoding, candidate saving, and page-count verification all stay in your browser. Nothing is uploaded, which means the byte count the tool measures is the same byte count the download will contain. A cloud-based tool that uploads the file, compresses it on a remote server, and returns a result cannot guarantee the local download matches the same byte length the server measured, because intermediate recompression for transit can shift the size in either direction.
For readers comparing this tool to other "compress to size" options, the practical checklist is short: does the tool measure the real saved bytes against the target, does it refuse to offer a download when the target is unreachable inside safe bounds, and does the verification happen against the same file the user will actually download? Compress PDF to Size satisfies all three, which is why the answer to the original question — does the download always meet the target — is yes, by construction.
How the bounded profiles keep results predictable
Four profiles sounds like a small number, but each one corresponds to a real engineering tradeoff. The 0.70/1400 profile keeps large JPGs readable on screen and works well when the target is only slightly smaller than the source. The 0.55/1000 profile catches the middle range, where a 30 to 50 percent reduction is needed. The 0.40/800 and 0.30/600 profiles take over for aggressive reductions and for scanned documents where detail loss is acceptable.
Because the tool stops at the first profile that meets the target, a near-target compression often succeeds early with very little visible degradation, while an aggressive compression runs all four profiles before either passing or refusing. That step-by-step behavior is what makes the result verifiable rather than approximate: each profile produces a measurable saved file, and the tool only stops when one of those files is at or below the target you asked for. Keep your original and review the result when document fidelity matters, especially for PDFs that mix text with photos or contain fine line art.