Every kilobyte counts. Whether you are shipping a production website, attaching photos to an email, or posting to social media, oversized images slow everything down, consume bandwidth, and frustrate users. Image compression is the single most effective optimization you can perform – a well-compressed image can drop to 10% of its original size while looking nearly identical to the human eye.
This guide explains how compression actually works, the tradeoffs involved, and the practical steps you can take to get the best results.
Lossy vs Lossless Compression
Image compression falls into two fundamental categories.
Lossless compression reduces file size without removing any pixel data. You can compress and decompress a lossless image an infinite number of times and it will remain pixel-perfect identical to the original. Formats like PNG and GIF use lossless compression. The tradeoff: file sizes stay relatively large.
Lossy compression reduces file size by permanently discarding data that the algorithm considers less noticeable. JPEG is the classic lossy format. The degree of loss is controlled by a quality parameter – lower quality means more data is thrown away and the file gets smaller, but artifacts appear.
Think of lossless as folding a piece of paper neatly into a smaller shape (you can unfold it perfectly). Lossy is like sketching the paper’s contents onto a smaller sheet – you lose some detail, but the essentials remain.
| Feature | Lossless | Lossy |
|---|---|---|
| Data preservation | Every pixel preserved | Data permanently discarded |
| Typical reduction | 10-60% | 60-95% |
| Repeated saves | No degradation | Accumulates artifacts |
| Best for | Logos, text, diagrams, editing masters | Photos, web images, thumbnails |
| Example formats | PNG, GIF, BMP | JPEG, WebP (lossy) |
Format Deep Dive: What Actually Happens Inside Each Format
JPEG Compression
JPEG works by converting the image into frequency components and discarding high-frequency detail that human eyes are less sensitive to. It splits the image into 8x8 pixel blocks and applies a mathematical transform (DCT) to each block. The quality slider directly controls how aggressively the algorithm rounds off the frequency coefficients.
Here is what the quality slider actually does at different levels:
| Quality Setting | Visual Result | File Size | Best Use |
|---|---|---|---|
| 100% | Indistinguishable from original | Largest JPEG | Archival, print masters |
| 80-90% | Near lossless to most viewers | ~40-60% reduction | High-quality web photos |
| 60-75% | Minor artifacts in gradients, fine text | ~60-80% reduction | Website content images |
| 30-50% | Visible blocking, banding, color shifts | ~80-90% reduction | Thumbnails, low priority images |
| 10-20% | Heavy artifacts, posterized colors | ~90-95% reduction | Placeholder images only |
The sweet spot for most web photography is 75-85% quality. The visual difference from 100% is negligible, but the file size drops dramatically.
PNG Compression
PNG uses the DEFLATE compression algorithm (the same one behind ZIP files). It works losslessly by finding repeated patterns in the pixel data and encoding them more efficiently. PNG first applies a “filter” that transforms pixel values to make them more compressible – for example, storing the difference between adjacent pixels instead of absolute values.
Because PNG is lossless, you cannot adjust a “quality” setting. However, you can influence PNG file size by reducing the color depth. A PNG-8 (256 colors) is much smaller than a PNG-24 (16.7 million colors). For simple graphics with limited colors, always choose 8-bit PNG.
WebP Compression
WebP, developed by Google, can operate in both lossy and lossless modes. Its lossy mode uses a compression technique derived from the VP8 video codec, which predicts pixel values within blocks and encodes only the prediction error. This generally produces files 25-35% smaller than equivalent-quality JPEGs.
WebP lossless mode uses advanced techniques like color cache, local palette, and backward reference matching that make it 26% smaller than equivalent PNGs on average.
Practical File Size Comparison
To give you a concrete sense of the differences, here is a real-world example using a 1920x1080 photograph:
| Format | Quality / Mode | File Size | Visual Quality |
|---|---|---|---|
| Original (RAW) | – | 6.2 MB | Perfect |
| PNG-24 | Lossless | 4.8 MB | Perfect |
| JPEG | 95% | 1.2 MB | Excellent |
| JPEG | 80% | 320 KB | Very good |
| JPEG | 60% | 140 KB | Acceptable |
| WebP | Lossless | 2.9 MB | Perfect |
| WebP | 90% | 180 KB | Excellent |
| WebP | 75% | 85 KB | Very good |
The WebP at 75% quality achieves roughly the same visual result as a JPEG at 80%, but at roughly one-quarter the file size.
When to Use Each Format
Photos and photographs – Use JPEG or WebP. JPEG has universal compatibility and works well at 75-85% quality. WebP gives you better compression but check that your target platform supports it (most modern browsers and apps do in 2026).
Screenshots of UI, text, or code – Use PNG. The sharp edges and uniform regions of screenshots compress beautifully with PNG’s lossless algorithm. JPEG will introduce visible fringing around text.
Logos, icons, and illustrations with flat colors – Use PNG-8 or SVG. These images have few colors and sharp edges; a 256-color PNG-8 is tiny and crisp. SVG is ideal if you need infinite scalability.
Images requiring transparency – Use PNG or WebP (JPEG does not support transparency).
Images for print – Use high-quality JPEG (90-100%) or TIFF. Avoid compression artifacts in printed output where they become more visible than on screen.
How Browser-Based Compression Works
When you use a browser-based tool like the TUXIA Image Compressor, the compression happens entirely on your device using the Canvas API and the browser’s built-in image codecs. No image data leaves your computer.
The process works in three steps:
- Decode: The browser reads your uploaded image file and decodes it into a raw pixel buffer using its internal codec (libjpeg, libpng, etc.).
- Render to canvas: The pixel buffer is drawn onto an HTML5 Canvas element, giving JavaScript programmatic access to the image data.
- Re-encode: The canvas calls
toBlob()ortoDataURL()with your chosen format and quality setting, triggering the browser’s encoder to produce the compressed output.
This means the actual compression quality depends on the browser’s codec implementation. Chromium-based browsers, Firefox, and Safari all implement JPEG and WebP encoding, but their compilers may produce slightly different file sizes at the same quality level. Chromium’s JPEG encoder (derived from libjpeg-turbo) is generally the most efficient.
Limitations of Browser Compression vs Server Tools
Browser-based compression is fast, private, and convenient, but it has boundaries.
Chunked/Progressive encoding: The Canvas API produces baseline JPEGs, not progressive ones. You cannot create progressively loading JPEGs in the browser. Server tools like ImageMagick or sharp can produce progressive JPEGs, which appear to load faster because they render at low resolution first.
Advanced PNG optimization: The browser’s PNG encoder applies basic DEFLATE compression but does not perform the aggressive optimization that dedicated tools like pngquant (color quantization) or optipng (trial-based filter selection) can achieve. A browser-produced PNG may be 20-40% larger than an optimized one.
Metadata handling: Canvas strips almost all metadata – EXIF, IPTC, XMP – by default. This is good for privacy but bad if you need to preserve copyright info or camera settings.
Memory constraints: Very large images (e.g., 50+ megapixels) may exhaust browser memory or hit canvas size limits, which vary by browser. For extremely high-resolution photos, a server-side tool is more reliable.
Batch processing: You can compress one image at a time in the browser. For hundreds of images, a command-line tool or build pipeline is more practical.
Combining Resize and Compression for Best Results
The most dramatic file size reductions come from combining resizing with compression. If you are displaying an image at 800 pixels wide on your website, there is no reason to upload a 4000-pixel-wide photo. Resize first, then compress. The workflow:
- Determine the maximum display size (e.g., 1200px wide for a hero image).
- Resize the image to that exact width.
- Compress at 75-85% JPEG quality or equivalent WebP quality.
- Compare the result against the original at actual display size, not zoomed in.
This two-step approach typically reduces file size by 90-98% from the original, with no perceptible quality difference at normal viewing distances.
Common Compression Mistakes
Compressing too aggressively: Crank the quality slider to 10% and you will get a tiny file that looks terrible. The goal is the smallest file that still looks good, not the smallest file possible.
Re-compressing JPEGs: Every time you open and re-save a JPEG, you compound the compression artifacts. Always keep an uncompressed master copy and export from that.
Using JPEG for text or line art: The 8x8 block-based compression creates visible ringing and fringing around sharp edges. Use PNG for anything with text, lines, or flat color regions.
Compressing already-small images: If your image is already under 20 KB, further compression may actually increase file size due to codec overhead. Check before and after; sometimes the best compression is none at all.
Ignoring next-gen formats: If your audience uses modern browsers (which over 95% do in 2026), WebP and AVIF offer substantial savings over JPEG and PNG. Use them unless you specifically need legacy browser support.
Summary
Effective image compression is a balancing act between file size and visual quality. Start with the right format for your content (JPEG for photos, PNG for graphics, WebP for the web), choose a quality level appropriate for your use case, and always compare the compressed result against the original at actual viewing size. The TUXIA Image Compressor handles this workflow entirely in your browser, with live before-and-after previews so you can find the optimal compression level in real time.