A smaller file can cost you a text layer. These measured examples show both sides: a large synthetic PDF becomes smaller and image-only, while an already-small document comes back unchanged.
Two cases, not a promise for every PDF
These results come from actual local browser exports recorded on 7 September 2026 on Linux. Each browser processed the same two files with a maximum output setting of 200 KB and an upper raster-quality setting of 150 DPI. In this tool, 200 KB means 204,800 bytes. A ceiling is not a request for an exact output size.
- The large sample is one A4 page with a deterministic 900 × 1260 pixel grey texture and two lines of selectable text. It is deliberately noisy, not a photograph, a representative scan collection or a typical office PDF.
- The small sample has five A4 pages, selectable text, an illustration and one filled text field. Its original 50,317 bytes already fit below the requested ceiling.
There are no timing scores, repeated-run averages or competitor rankings here. The comparison explains the supplied files; it does not estimate average savings, visual quality or performance on your device.
Large texture sample: fewer bytes, no selectable text
Both outputs reopened as one A4 page with the original page dimensions. Rendered content remained visible, but the original selectable text was no longer extractable. That is a structural change, even when the heading still looks readable on screen.
| Browser | Input bytes | Output bytes | Reduction |
|---|---|---|---|
| Chromium 151.0.7922.34 | 1,174,106 | 198,161 | 83.12% |
| Firefox 153.0 | 1,174,106 | 198,262 | 83.11% |
The target was met in both saved outputs. Although 150 DPI was requested as the maximum, the reported result was Chromium: Up to 120 DPI · 63% JPEG; Firefox: Up to 120 DPI · 59% JPEG. These are the tool’s reported settings, not an independently measured quality score. Different browser encoders can produce different bytes; the small difference between these files does not establish a better browser.
- Download the original texture PDF (1,174,106 bytes).
- Download the measured Chromium output (198,161 bytes).
- Download the measured Firefox output (198,262 bytes).
- Download the measurement record and SHA-256 hashes (JSON).
Small document: a genuine zero-reduction result
The tool returned the five-page file byte for byte in both browsers. Its text and filled form field were therefore preserved. This is the already-fits branch, not a lossless PDF optimizer and not evidence that the file could never be made smaller by another method.
| Browser | Input bytes | Output bytes | Reduction |
|---|---|---|---|
| Chromium 151.0.7922.34 | 50,317 | 50,317 | 0.00% |
| Firefox 153.0 | 50,317 | 50,317 | 0.00% |
Download the five-page input and unchanged result. One file represents both because the verified download had exactly the same bytes and SHA-256 hash. It is not a separately generated example.
Repeat the examples in your browser
- Save the original texture sample above. Open Compress PDF to target size and choose that PDF, without editing or resaving it first.
- Set Maximum output (KB) to 200 and Maximum raster quality to “Up to 150 DPI · clearer”. Read the image-only trade-off, then tick the confirmation and select “Compress PDF to target”.
- Download the result. Check its actual byte size, Target status, page count and reported Raster quality. Open the PDF in a viewer and compare the heading, smaller sentence and texture with the original at the same zoom.
- Try selecting or searching for “COMPRESSION SAMPLE” in the original and output. The recorded raster outputs lost the selectable text layer; visual readability alone does not check that property.
- Start again with the five-page sample and the same 200 KB ceiling. The recorded result is unchanged: compare the byte size, text selection and the first-page field containing “Reviewed locally”.
Compare actual bytes rather than a rounded file-manager KB label. Reduction
is calculated as 100 × (input bytes − output bytes) ÷ input bytes.
For Chromium’s texture result, this is
100 × (1,174,106 − 198,161) ÷ 1,174,106,
rounded to 83.12% in the table.
Zero means no reduction; a negative result would mean the output grew.
A rerun need not have an identical hash: browser encoders, versions and PDF metadata can affect the generated bytes. The supplied hashes identify these saved artifacts. If your file differs, check its contents and limits rather than treating a hash mismatch alone as a processing failure.
What the byte saving leaves out
This tool rebuilds oversized pages as images. The large example verifies a smaller file and a lost text layer; it does not prove faithful preservation of tiny print, signatures, barcodes, colour or fine linework. A noisy grey background is especially poor evidence for judging a real document’s quality.
- Check small text and important values side by side before sharing. A page-count match means pages remain, not that every meaningful detail or interactive feature survived.
- Forms, links and accessibility structure can be removed during raster rebuilding. Keep the original if those features matter. The unchanged example preserves them by preserving the complete file, not by reconstructing them.
- A lower ceiling can require lower DPI or JPEG quality. Some requests may remain above the target and are labelled “Not met”. A smaller candidate may be offered above the ceiling; if no reduction is possible, the original is preserved. These two cases do not measure how often that happens.
- Do not keep a converted file merely because it is called compressed. Compare the actual bytes and usefulness; an already-compact PDF may offer little benefit. The current tool keeps the original when conversion would produce an equal-sized or larger file.
If searchability is required, prefer the original text PDF. Searchable PDF OCR is a separate option for image-only pages, but its recognition needs review and it does not restore the original form fields, links or document structure.
Where the measurements come from
The browser runs used normal file selection, confirmation and native download flows. The verifier reopened the generated PDFs with PDF.js and pdf-lib, checked page dimensions and count, tested extracted text and rendered the raster result. The small-file case asserted byte equality between the native download and input. Those checks support the specific observations above, not a complete visual-quality or accessibility audit.
This page reuses those recorded exports; it does not present a fresh rerun as a new measurement. The benchmark verifier independently checks input and output hashes, reopens the PDFs and recomputes the reduction arithmetic. It exposes the saved Firefox output alongside the existing Chromium file. The downloadable JSON contains the original browser versions, timestamps, source-evidence hash, settings and artifact hashes.
Reproduce the checks from the project source
In a checkout containing these resources, the sample generators are
scripts/generate-guide-samples.mjs and
scripts/generate-guide-samples-iteration5.mjs. The latter
creates the seeded grey texture rather than using a real photograph.
scripts/verify-guide-examples-iteration5.mjs records real
Chromium and Firefox workflows against the locally served production
build. It also verifies other tools in that batch. Its compression
section is the source of the existing measurements, not a speed test.
Run node scripts/verify-compression-benchmark.mjs to check
the committed inputs and public results against the original recorded
hashes without opening a browser or changing files. The optional
--publish flag regenerates this comparison from the original
output/playwright/guide-examples-iteration5/ native artifacts
and copies the verified Firefox download; it does not create new
compression measurements. That publish step requires those artifacts,
while the default read-only check works from the committed sample files.
Use the project’s Node 22 toolchain.
No statement here establishes that every network request is harmless or that the whole site is accessible. For a separate, repeatable inspection of network activity, follow Verify local processing. For the tool’s practical instructions and troubleshooting, read the compression worked example.