How Browser File Compression Works
Learn how quality, dimensions, formats, and PDF rasterization affect file size when compression runs locally in a browser.
Browser compression uses the same basic building blocks as a desktop utility: decoders read the source, an in-memory representation is changed, and an encoder writes a new file. The important difference is location. The work runs in the browser process on your device instead of on an upload server.
The three main size levers
Encoding quality
Lossy formats discard visual information that is less noticeable to human vision. Lower JPEG or WebP quality usually means a smaller file, but fine texture, sharp edges, and gradients can develop artifacts. Quality numbers are encoder-specific and are not universal percentages of visual fidelity.
Pixel dimensions
Width multiplied by height determines how many pixels an image contains. Halving both dimensions leaves one quarter of the pixels, which can create a much larger reduction than another small quality adjustment. The tradeoff is lower resolution when zooming, printing, or cropping later.
File format
JPEG is effective for photographs but does not support transparency. PNG preserves pixels exactly and handles flat graphics and transparency well, but it can be large for photographs. WebP supports both lossy and lossless modes and often produces smaller photographic files than JPEG at comparable visual quality.
Why target-size compression needs several attempts
An encoder cannot know the final byte count from a quality setting alone. A detailed photograph and a plain background can produce very different sizes at the same dimensions and quality. To approach a target, the compressor encodes several candidates, compares their sizes, and adjusts quality. If quality reaches a practical floor, it may reduce dimensions and repeat the search.
This process is why a target is best understood as a goal rather than a guarantee. Some files contain information that cannot be preserved within an extremely small byte budget.
PDF compression is different
A PDF is a container, not a single image format. It can combine text, fonts, vector drawings, photographs, scanned pages, form fields, scripts, and attachments. A simple rewrite may remove redundant metadata, but large reductions often require changing embedded images or rendering complete pages into new compressed images.
Page rendering makes output size more predictable, but it can remove semantic features. Text may no longer be selectable, links may stop working, and accessibility structure can be lost. Compression modes should communicate their tradeoffs instead of promising lossless results at any size.
What local processing does and does not mean
The browser File API can read a file selected by the user without uploading it. Canvas and WebAssembly codecs can decode, resize, and encode data in memory. A Blob then becomes a downloadable result. This allows a complete compression workflow without a file-receiving server.
Local processing still consumes your device's memory and CPU. Large images and long PDFs can be slow on mobile hardware. Closing the tab interrupts the work, while installing the PWA makes the application code available offline.
Choosing a sensible mode
The right result is not simply the smallest file. It is the smallest file that remains suitable for its destination.
- Balanced: Start here when readability and dimensions matter.
- Strong: Use it for a hard limit after inspecting a Balanced result.
- Maximum: Reserve it for cases where reaching the limit matters more than fidelity or document semantics.