Sign X PDF · Guides
PDF compression: file size vs image quality
PDF compression is a trade-off, not a universal percentage. Text-heavy, scanned, photo-heavy, and mixed PDFs respond differently. Measure the original size, achieved size, target result, and visible quality for a fixed fixture set instead of promising that every PDF will shrink by the same amount.
Compression measurements are environment-dependent. Review the exported PDF for readability and keep the original file when quality matters.
Verification scope: the owner-managed repository source and open-source components were reviewed on 2026-08-08. The linked GitHub repository currently requires access for anonymous visitors; it is a source reference, not a public-audit guarantee. The test files used for browser checks stayed on the test device and were not uploaded to Sign X PDF application servers. This is scoped evidence, not a guarantee about a compromised device, browser extensions, OS services, or future code changes.
Why one compression number is misleading
A text-heavy PDF may already contain efficient vector and font data. A scan may contain large raster images that can be recompressed. A photo-heavy document may shrink substantially but show softness or blocking at lower quality. A mixed file can contain all three behaviours on different pages.
The meaningful result is not “compression is 70%”. It is a measured before/after pair with the fixture type, target setting, achieved size, and a visual inspection note.
A reproducible fixture set
Create four non-confidential fixtures: text-heavy, scanned-document, photo-heavy, and mixed-content. Keep the source files fixed and record their byte sizes and page counts. Use the same browser, device class, target setting, and date when comparing runs.
- Text-heavy: selectable text, simple vector shapes, and normal fonts.
- Scanned: raster page images with realistic document detail.
- Photo-heavy: several photographic images with varied detail.
- Mixed: text, diagrams, screenshots, and at least one image-heavy page.
What Sign X PDF’s compressor reports
The browser compressor first tries lossless assembly, then can rasterize pages and search JPEG quality settings when a target size requires it. The result reports original bytes, achieved bytes, whether the target was reached, and whether the lossless path was used.
That means a target such as 500 KB is a request, not a guarantee. A document may remain above the target, and stronger reduction can change image quality. Review the exported file before relying on it.
- Original size and achieved size are the primary measurements.
- Target reached is a result flag, not a promise.
- Lossless output and raster/JPEG output have different quality implications.
- Visual inspection is required for scans, photos, signatures, and small text.
Record the result honestly
A useful benchmark table contains fixture type, page count, input bytes, target bytes, output bytes, reduction percentage, elapsed time, and a short visual-effect note. Publish the raw conditions with the result so another person can repeat it.
Do not convert one local run into a universal maximum or minimum. Browser memory, CPU, canvas support, PDF structure, and source image content all affect the result.
Measured Windows desktop run — 2026-08-08
The following run used synthetic, non-confidential PDFs on Windows with Chromium 136.0.7103.25. The text fixture intentionally used a 50 KB target above its lossless size; the image fixtures used a target of approximately 60% of the input size. A negative reduction means the lossless PDF assembly was slightly larger than the generated source, not that the file was silently claimed to be smaller.
Visual notes are first-page preview signals. They identify when the output was rasterised or changed dimensions, but they are not an automated readability score. Keep the original and inspect text, scans, photos, and signatures before relying on the export.
| Fixture | Pages | Input | Target | Output | Reduction | Elapsed | Reached |
|---|---|---|---|---|---|---|---|
| Text-heavy | 8 | 15,788 B | 50 KB | 15,996 B | -1.32% | 252 ms | Yes |
| Scanned | 5 | 3,180,540 B | 1,863 KB | 1,863,750 B | 41.40% | 2,422 ms | Yes |
| Photo-heavy | 3 | 5,667,651 B | 3,320 KB | 3,235,768 B | 42.91% | 1,971 ms | Yes |
| Mixed | 4 | 3,782,484 B | 2,216 KB | 2,215,598 B | 41.42% | 2,073 ms | Yes |
How we verified this
Compression implementation review
Result: The current browser implementation records original/achieved sizes, target status, and lossless-vs-raster result paths.
Scope: Client-side compression workflow
Limits: Source review does not substitute for a device-specific quality benchmark.
Source: src/lib/pdf/PdfToolkit.ts
Compression UI review
Result: The tool exposes a target-size control and reports the achieved result to the user.
Scope: Current Compress panel
Limits: A target control cannot make every input reach the same output size.
Source: src/lib/components/CompressPanel.svelte
Repeatable browser fixture run
Result: Four synthetic fixtures completed compression and export under the recorded Windows desktop condition; the measured rows are published above.
Scope: Browser UI flow and downloaded output bytes
Limits: One desktop run does not prove mobile behaviour or universal visual quality.
Source: docs/geo/benchmarks/phase4-browser-benchmarks.json
FAQ
Will every PDF reach a 500 KB target?
No. The tool reports whether it reached the requested target. Content, page count, and browser resources determine what is achievable.
Does smaller always mean worse quality?
Not always, but stronger raster/JPEG compression can reduce image detail. Compare the exported file at normal reading size and at the zoom level your workflow needs.
Is the PDF uploaded for compression?
Sign X PDF’s compression workflow is designed to run locally in the browser; its public privacy test covers compression and checks for document-upload patterns.