A compressed PDF meets its target size only when the actual bytes of the saved file are at or below the MB value you entered, and Compress PDF to Size gates its download button on exactly that measurement. No estimate, no approximation, no "about this size" promise — the gate between you and the output is a byte-for-byte comparison against the target you typed. If the candidate file comes out over the target after the bounded recompression profiles have been tried, the tool returns no file and explains that the target cannot be reached safely.
This matters because most "compress PDF to size" promises on the web are not actually verifiable. They show you a smaller file and tell you it's "close enough" to your target, or they round down a 1.8 MB file and call it 1 MB. When your downstream workflow depends on a hard ceiling — an email attachment limit, a portal upload cap, a job-application file-size rule — you need a method that confirms the result instead of guessing at it. The download-only-on-success approach is the cleanest way to do that confirmation, because the same code that produces the file is the code that measures it.
What "checking the result" actually means after compressing
Checking the result of a PDF compression has three concrete parts: confirming the saved file is at or under your target size, confirming the page count is unchanged, and confirming the content is still usable. Most people only check the first one because that's what the limit requires. A method that only checks the first one is incomplete, though, because a compressed PDF that drops half its pages is technically smaller but useless for the task it was meant for.
Compress PDF to Size handles all three checks before it shows a download link. It saves a candidate, measures the actual byte length, and compares it to your target. If the bytes are at or below the target, it reopens the candidate in a PDF viewer (PDF.js) and confirms the page count matches the original. Only then does the Download button appear. The tool does not display a download link for a candidate that meets the byte target but has lost pages, and it does not display a download link for a candidate that is over the byte target.
How the tool verifies the result inside your browser
The verification happens entirely in your browser using two web standards. The PDF.js library reads the candidate file back as a PDF and reports its page count. The HTML canvas.toBlob method is what generates the candidate JPG payloads used during recompression — the same primitive the browser uses for image export, as described in the WHATWG Canvas toBlob specification. PDF.js itself is documented in the Mozilla PDF.js API reference.
What this means in practice is that the bytes you are being asked to download are bytes that were actually measured, not bytes that were estimated from your source file. The source PDF is opened, eligible JPG images are decoded, each is re-encoded at a fixed quality and longest-side profile, and the resulting PDF is rebuilt and saved. The saved file's length is then read directly — the same way your operating system would report it — and compared to your target. There is no separate "approximate size" step.
This is also why the tool can honestly say "no result" when the target cannot be met. It is not running an infinite loop trying random settings; it works through a bounded sequence of four quality/dimension profiles (0.70/1400, 0.55/1000, 0.40/800, 0.30/600) and stops when one candidate passes both checks. If none of them passes, the tool tells you the target is unreachable with this method, rather than handing you an oversized file and calling it compressed.
What changes and what stays the same in the checked result
The verification step matters more once you understand which parts of the PDF the tool is willing to modify, because that determines whether the checked file is still fit for purpose. The table below shows what gets touched during the bounded recompression and what the tool deliberately leaves alone.
| What changes | What stays the same |
|---|---|
| Eligible embedded JPG streams (unmasked DCTDecode DeviceRGB or DeviceGray with no decode parameters) are re-encoded at the active profile's quality | Page structure, page count, and page order |
| The maximum image dimension for eligible JPGs is downsized to the active profile's longest-side value when needed | Selectable text, links, forms, and vector content |
| Unsupported image objects are preserved unchanged | |
| Whole pages are not rasterized | |
| If a candidate JPG would be larger than its original stream, that image is left untouched |
The practical takeaway is that the page-count check at the end of the verification is not redundant with the byte check. A target met by losing pages would still pass the byte test, so PDF.js is reopened specifically to rule that out.
Compress PDF to a target size and verify the result
The verification is built into the three-step workflow of Compress PDF to Size, which means you do not need to run a separate "check" tool afterward — the download button itself is the check.
- Choose one local PDF up to 25 MB and load it into the tool. The file stays in your browser; nothing leaves your device during the check.
- Enter a target between 0.1 MB and 25 MB that is smaller than the source file. The target is the exact ceiling the saved file has to pass.
- Select Compress to target size. The tool runs its bounded profiles, saves candidates, measures actual bytes, and reopens each passing candidate with PDF.js to confirm the page count.
- Watch for the download link. If it appears, the saved file has passed both the byte check and the page-count check, and you can save it. If no link appears, the tool tells you the target cannot be reached safely — there is no oversized result to download by mistake.
Because verification happens during the same run that produces the file, you do not need to open a second tool, compare file sizes in Finder or Explorer, or guess at whether the result is good enough. The download button is, by construction, only visible when both checks have passed.
When the result will not pass the check
The verification step is honest about cases where the target cannot be reached, and these cases are worth knowing before you start so you do not waste a run on an unreachable goal.
- Text-only PDFs. If your file is mostly selectable text with no embedded JPG images, there are no eligible streams to recompress, and the bounded profiles cannot reduce the file size meaningfully.
- Vector-heavy documents. Drawings, CAD-style exports, and charts stored as vector objects are not affected by JPG recompression, so the target stays out of reach.
- PDFs dominated by unsupported images. Images with masks, CMYK color spaces, ICC profiles, decode parameters, or non-DCT compression formats are skipped by the tool and left untouched, which caps how much the file can shrink.
- Aggressive targets on small source files. Asking a 1.2 MB scan to compress to 0.1 MB is more reduction than bounded JPG recompression can safely deliver, and the tool will say so. The local job is also capped at 80 eligible images and 100 megapixels across the images it decodes, so sources that exceed those caps cannot complete the task either.
A scanned PDF made up of JPG photos, by contrast, is the case the tool handles best: a target much lower than the source is often reachable because every page's image is an eligible JPG that can be re-encoded at a lower quality and a smaller longest-side.
How to confirm the saved file on your own
Even with a download-only-on-success tool, it is worth doing your own final check, especially for documents where fidelity matters. Open the saved file in your usual PDF reader, glance at a few pages to confirm the images still look acceptable at their new quality, and check the file size in your operating system to confirm it matches what the tool reported. The tool reports the actual byte length of the saved file, so what you see in your file manager should match exactly.
Keep the original PDF until you have confirmed the result, and review the compressed version against the source for anything you specifically care about — a logo on the last page, fine print in a contract, color accuracy in a marketing piece. The tool preserves vectors, text, links, forms, and unsupported images, but it does not make a general lossless claim, so for documents where the visual difference matters, an extra look is cheap insurance.
For related guidance on the same workflow, the guide Will a Compressed PDF Always Meet Your Target Size? covers when a target is reachable, and How to Avoid Mistakes When You Compress PDF to Size covers common pitfalls in picking a target.