Comparing PDF compression approaches comes down to four measurable differences: whether a method targets a specific byte size or only promises "smaller," whether it processes the file locally or uploads it to a remote server, which PDF objects it can safely change, and how it verifies the saved file. The approaches that produce the smallest output on a given PDF are not always the same as the approaches that reliably hit an exact MB target, and the approaches that hit a target are not always the ones that keep text, forms, and vector content untouched. A useful comparison treats the same source file as the only fair input, picks a target in megabytes, and judges each method by the actual byte length of the file it saves — not by an estimate derived from the source. The rest of this article walks through those criteria, applies them to common approaches, and then shows a hands-on test using a target-aware local approach that only offers a download after the saved PDF is at or below the requested MB value.
What separates one compression approach from another
Most people compare PDF compression tools by their marketing copy: "shrinks by up to 90%," "lossless," "best quality." Those claims are not comparable because they are measured against different sources, different targets, and different definitions of "lossless." To compare approaches fairly, you need to fix four dimensions in advance and hold them constant across every method you test.
The first dimension is whether the approach is target-aware. A target-aware approach accepts an MB value from the user and treats "saved file is at or below that value" as the success criterion. An unaware approach only promises a reduction relative to the source and never commits to a specific output size. Target-aware approaches can fail honestly — they tell you the target cannot be reached safely — while unaware approaches always produce a download and leave you to decide whether the result meets your real constraint.
The second dimension is processing location. Some approaches read and rewrite the PDF inside your browser using libraries such as Mozilla PDF.js; others upload the file to a server, run a backend optimizer, and return the result. Local processing keeps the source on your device and removes one variable (network bandwidth, server load, retention policy) from the comparison.
The third dimension is which PDF objects the method is allowed to change. A method that only re-encodes embedded JPG streams leaves text, vectors, links, form fields, and metadata untouched. A method that rasterizes whole pages replaces all of those objects with pixels. A method that strips metadata and flattens forms changes document behavior in ways a "compress" label does not announce. Two tools that both say "lossless" can mean very different things on the same PDF.
The fourth dimension is verification. Does the tool compare the actual saved file's bytes against the target, or does it estimate what the saved file would weigh based on the source? The latter is faster but wrong whenever the encoder's output size differs from the prediction. A verified check opens the candidate output, reads its byte length, and only then exposes a download link.
Common PDF compression approaches compared
The table below compares five approaches you are likely to encounter. It does not list test numbers because those depend on the source file; it lists the structural properties that determine how each approach behaves on any input.
| Approach | Target-aware | Local | What it changes | Verification |
|---|---|---|---|---|
| Generic online "compress PDF" | Usually no | No (uploaded) | Depends on backend | Estimate or no check |
| Lossless object-stream re-flush (e.g., qpdf) | No | Yes | Cross-reference tables, object streams, metadata | Saved bytes only |
| Local JPG recompression to a target | Yes | Yes | Only unmasked DCTDecode DeviceRGB or DeviceGray JPG payloads | Saved bytes compared to target |
| Rasterize each page to a JPG image | Indirectly | Sometimes | Entire page content | Saved bytes |
| Server-side optimization suite | No | No | Depends on backend | Estimate or no check |
Two rows stand out for anyone comparing by a real MB limit. The local JPG recompression row is target-aware and verified; the lossless re-flush row is local and verified but not target-aware — it can only do as well as the size already encoded in the JPG streams allows. Generic online tools and server-side suites are the most variable because they hide their object-selection rules behind a single "compress" button, which makes a fair comparison difficult without inspecting the output yourself.
Match the approach to your PDF type
An approach that excels on one PDF can stall on another. Before you compare tools, classify the source file into one of these buckets, because the right method depends on what is actually inside the file.
- Scan-heavy PDF — every page is mostly a single JPEG image. JPG recompression and page rasterization both work here; lossless re-flush alone will barely shrink the file.
- Text-only PDF — pages are font references and small vector glyphs. No image recompression will help because there are no images to compress. This is the bucket where "no result" is the honest answer.
- Vector-heavy PDF — CAD drawings, maps, engineering diagrams. Image streams are small relative to the page geometry, so no JPG-focused approach will reach an aggressive target.
- Mixed PDF — narrative text with embedded photos, charts, and logos. JPG recompression can shrink the photo portion significantly; the text portion will not change.
- Form-heavy PDF — interactive widgets, signature fields, fillable form data. Any approach that flattens or rasterizes pages will break form behavior. Pick a method that promises to leave form widgets and links intact.
Once you know your bucket, the comparison becomes a question of which approach can change the right objects without disturbing the ones you need. For mixed and scan-heavy files, a target-aware local JPG recompression approach such as Compress PDF to Size is built specifically for the byte-target case, so it is the natural reference point against which to measure other methods on those file types.
How to test a target-aware approach on your own file
The clearest comparison you can run is a single-file, single-target test: pick one PDF, one MB target, one tool, and judge by whether the saved file is at or below the target. The operating steps for Compress PDF to Size are intentionally short so the comparison stays about the result, not about the workflow.
- Choose one local PDF up to 25 MB.
- Enter a target from 0.1 to 25 MB that is smaller than the source file.
- Select Compress to target size; download only when the verified output meets the exact target.
The tool tries a bounded sequence of JPG quality and longest-side profiles — roughly 0.70/1400, 0.55/1000, 0.40/800, and 0.30/600 — and after each profile saves the actual PDF and compares its byte length to your target. The first profile whose saved file is at or below the target, with the page count still matching the source, is the one offered for download. The local job is also bounded to 80 eligible images and 100 megapixels across decoded images. The encoder uses the browser's canvas toBlob path to write each candidate, so the comparison is over real bytes, not a prediction.
If you want a fair head-to-head with another tool, run the same source file through both, with the same target, and record three numbers for each: the byte length of the saved file, the page count of the saved file, and whether text selection and links still work in the saved one. If a tool cannot tell you its byte result against your target, it is not making a comparable claim and should be noted as such in the comparison.
When the target cannot be reached safely
An honest target-aware approach will sometimes show no download link at all. That is not a failure of the comparison — it is a meaningful data point. It means the bounded sequence of JPG profiles could not produce a saved file at or below the target, so the tool creates no download and explains that the target cannot be reached safely.
If Compress PDF to Size returns no result for your file, the practical next steps are: raise the target by the smallest amount that lets a profile pass; split the PDF and compress each half separately with its own target; or, for a scan-heavy file, move to a downstream page-rasterization step only after you have decided the text layer is no longer needed. The opposite — picking a smaller target than the document can survive — is what the bounded sequence is designed to prevent. For a fuller walkthrough of why some files do not reach their target, see Will a Compressed PDF Always Meet Your Target Size?.
Verifying the saved file before you trust it
A download button is not the same as a verified result. Before you treat any comparison as final, reopen the saved file and check four things: the page count matches the source, the byte length is at or below the target, the text layer still selects and copies on a representative page, and any links, form fields, or annotations you needed still behave as expected. Confirming these on the saved output is what turns a comparison from a marketing claim into a reproducible measurement. The How Do I Check the Result After I Compress PDF to Size guide walks through these checks step by step.
Compare your notes across the tools you tested. The approach that wins is the one that hits your byte target, preserves the page count, and keeps the document properties you depend on — not the one with the most aggressive marketing claim or the smallest reported size on a different source file.