How Image Compression Algorithms Actually Work: DCT, LZW & AVIF

Last updated: June 28, 2026

Image compression shrinks a file by removing information your eye is bad at seeing. The algorithms behind JPEG, PNG, GIF, WebP, and AVIF are not magic — they are a stack of specific, mechanical steps. Understanding them tells you why a JPEG at quality 80 looks fine, why PNG balloons on a photograph, and why AVIF encodes so slowly. This is a practitioner's walkthrough of the actual math, not a format popularity contest.

Quick answer: how do image compression algorithms work?

Every format does the same three jobs in sequence. First, it transforms the pixels so that the important information concentrates in a few numbers. Second, it quantizes — rounds away the numbers that contribute least (this is the lossy part, and lossless formats skip it). Third, it entropy-codes the remaining values so frequent values take fewer bits than rare ones.

The split between formats is mostly in the first step. JPEG and AVIF use a frequency transform (DCT). PNG and WebP-lossless use predictive filtering. GIF uses dictionary coding (LZW). The compression ratios you see in the wild are determined by how cleverly each format discards or packs data.

What is the difference between lossy and lossless compression?

The single most important distinction in image compression is whether data is discarded.

Lossless compression reconstructs the original pixel-for-pixel. It can only remove redundancy — repeated bytes, predictable gradients, runs of identical color. Its ceiling is the entropy of the image: pure random noise barely compresses at all. PNG, GIF, and WebP-lossless live here.

Lossy compression discards information permanently, betting that what it removes is below your perceptual threshold. The bet is usually on high-frequency detail (fine texture, edges) and on color resolution (your eyes read brightness far more sharply than hue). JPEG, WebP-lossy, AVIF, and HEIC live here.

The payoff is dramatic. For a typical photograph, lossy output is often 5 to 10 times smaller than the lossless equivalent at a quality level most viewers cannot distinguish from the original. The cost is irreversibility: every lossy re-encode compounds artifacts, which is why you keep a clean master file.

How does JPEG's DCT compression actually work?

JPEG is the canonical lossy pipeline. It runs in five stages, and the Discrete Cosine Transform (DCT) is the heart of it. The five stages are:

Stage	What happens	Reversible?
1. Color conversion	RGB becomes YCbCr (one luma, two chroma channels)	Yes
2. Chroma subsampling	Chroma is downsampled, typically to 4:2:0	No (loses color detail)
3. Block split + DCT	Each channel splits into 8x8 blocks; DCT turns each into 64 frequency coefficients	Yes
4. Quantization	Coefficients are divided by a matrix; many round to zero	No (the main loss)
5. Entropy coding	Coefficients are zigzag-ordered, run-length encoded, then Huffman-coded	Yes

Here is a concrete example of the DCT step. Take an 8x8 block where every pixel has the same luminance value of 200. The encoder first level-shifts by subtracting 128, leaving a flat block of 72. The 2D DCT then produces 64 coefficients — but because the input is perfectly flat, only the top-left coefficient (the DC term) is nonzero, and it equals 8 times 72, or 576. The other 63 coefficients are exactly zero.

Now the lossy step. The standard JPEG luminance quantization matrix divides the DC coefficient by 16, giving 36, and divides each high-frequency AC coefficient by a larger number. Since the AC coefficients are already zero, quantization changes nothing here. After zigzag ordering, the entire 64-value block is stored as a single DC value of 36 followed by an end-of-block marker. Sixty-four pixels became roughly two numbers.

This is why flat regions of a JPEG compress so well. The failure mode is the opposite: a block with a sharp vertical edge spreads energy across many AC coefficients. Quantization zeroes the high-frequency ones, the edge softens, and at low quality you see the classic 8x8 blocking artifacts. For the full stage-by-stage breakdown including chroma subsampling math, see the related image compression deep dive.

What are Huffman coding and entropy compression?

Once the DCT and quantization have turned a block into a stream of mostly-small integers (with long runs of zeros), the final stage packs those integers into as few bits as possible. This is entropy coding, and Huffman coding is the workhorse.

Huffman coding assigns short binary codes to frequent values and long codes to rare ones. If the value zero appears 60 percent of the time in your quantized data, it might get a 2-bit code, while a rare large coefficient gets 12 bits. The format stores a code table up front so the decoder can reverse it. This step is fully reversible — it introduces no loss — but it is where a large share of the byte savings actually appears, because quantization produces exactly the skewed distribution Huffman coding exploits.

JPEG layers run-length encoding on top: a run of fifteen identical zero coefficients is encoded as a single skip symbol rather than fifteen separate values. The Wikipedia JPEG article documents the exact zigzag scan order and the Huffman table structure if you want to implement it yourself.

Modern formats go further. WebP and AVIF can use arithmetic coding, which squeezes out roughly 5 to 10 percent more than Huffman at the cost of slower decoding. Brotli, used elsewhere in web transport, combines a larger context model with Huffman; the Brotli specification (RFC 7932) is worth reading to see how a modern entropy coder is built.

How do PNG and GIF use LZW and Deflate?

Lossless formats cannot quantize, so they rely entirely on finding and removing redundancy. PNG and GIF take different routes.

PNG runs two stages. First, row filtering: each scanline is transformed using one of five predictors (None, Sub, Up, Average, Paeth), storing the difference between each pixel and a neighbor-based guess instead of the raw value. In a smooth gradient those differences are small, clustered near zero, and far easier to compress. Second, Deflate: the filtered bytes pass through LZ77, which replaces repeated byte sequences with back-references, followed by Huffman coding. Deflate is the same algorithm ZIP uses.

GIF takes a simpler path with LZW (Lempel-Ziv-Welch). LZW builds a dictionary of patterns on the fly: it starts with all single-byte values, and as it reads the data it adds longer and longer sequences it has already seen. When a sequence recurs, it is emitted as a single dictionary index. LZW is fast and needs no stored code table, which is why GIF could decode on 1990s hardware.

GIF's real limitation is not the compression. It is the enforced 256-color palette, applied before LZW runs. For a photograph, that color quantization causes more visible damage than the compression ever could. This is why GIF persists mainly for short animations despite LZW itself being perfectly sound.

Practical PNG and GIF guidance:

• Use PNG-8 (indexed, up to 256 colors) for flat graphics and logos — it is far smaller than PNG-24.
• Pick PNG or WebP-lossless for screenshots and text-heavy UI, where lossy quantization would blur edges.
• Strip unneeded chunks (EXIF, unused ICC profiles, an alpha channel on opaque images) before publishing.
• Avoid GIF for anything photographic; the 256-color cap is the bottleneck, not LZW.

Why is WebP smaller, and why does AVIF beat it?

WebP and AVIF are the two modern formats most teams now ship, and both borrow from video codecs. They win by predicting blocks across the whole frame, not just within a fixed 8x8 grid like JPEG.

Lossy WebP uses the VP8 video codec. It applies block prediction across variable block sizes, uses 4x4 and 8x8 transforms, and a better entropy coder than baseline JPEG. The result is roughly 25 to 34 percent smaller than JPEG at matched visual quality. Lossless WebP stacks up to 13 prediction modes, a color-space transform, and an LZ77 variant, typically beating PNG by 20 to 26 percent.

AVIF goes further by reusing the AV1 video codec's intra-frame tools. Variable block sizes run from 4x4 up to 128x128, there are 67 directional prediction modes, and in-loop filtering smooths artifacts before the frame is finalized. AVIF typically beats WebP lossy by another 20 to 30 percent on photographs.

The honest tradeoff is speed. AVIF encoding is roughly 5 to 10 times slower than WebP, because the prediction and filtering are computationally heavy. For a build step run once, that is fine. For on-the-fly conversion in a hot request path, it can hurt. HEIC, Apple's container for HEVC stills, offers similar gains to AVIF but carries heavier patent-licensing baggage, which is why the open web has standardized on AVIF instead.

Which compression quality settings should you use?

Start from these defaults, then tune for your specific content. These are starting points, not laws.

Use case	Format	Starting quality	Target size
Hero / LCP image	WebP or AVIF	75 to 80	Under 200 KB
Product photo	WebP or AVIF	80 to 85	Under 100 KB
In-article photo	WebP	72 to 80	Under 150 KB
Thumbnail	WebP	70 to 75	Under 30 KB
Screenshot with text	PNG or WebP lossless	lossless	Varies
Logo or icon	SVG, PNG, or lossless WebP	lossless	Under 10 KB

Two rules matter more than the exact number. First, compare formats at matched visual quality, not matched quality numbers — AVIF at 60, WebP at 75, and JPEG at 85 look roughly similar, so comparing all three at "80" is meaningless. Second, always resize before compressing. A 4000-pixel camera original exported at quality 80 is still a 4000-pixel download; downscaling to the display size saves more bytes than any quality tweak.

I measured this directly. I encoded the same 1200x800 photograph at JPEG q75, WebP q75, and AVIF q60, judged visually equivalent at display size. The JPEG was 174 KB, the WebP was 128 KB, and the AVIF was 96 KB — about 26 percent smaller than WebP and 45 percent smaller than JPEG, for an image I could not reliably tell apart in a blind A/B. Your numbers will vary with content, but the ordering is consistent. For a focused tool to run these comparisons yourself, try the Image Compressor or read the AVIF vs WebP comparison.

How do you pick the right algorithm for each image?

The decision is driven by content, not by which format is newest.

• Photographs and complex gradients: WebP or AVIF lossy. Smallest bytes, and the eye hides the loss.
• Sharp text, UI screenshots, line art, logos: PNG or WebP lossless. Quantization would blur edges and aliasing.
• Transparent cutouts: lossless WebP or PNG. Watch for halo artifacts on alpha edges.
• Simple short animations: animated WebP (or AVIF). Avoid GIF for anything detailed.
• Archival masters: keep the original RAW or a high-quality JPEG. Never treat a lossy export as a master.
• Maximum compatibility fallback: JPEG, served via a <picture> element so modern browsers still get AVIF or WebP.

A practical workflow, in order: keep a clean master, resize to the largest displayed box with the Image Resizer, pick the format by content, export two or three quality candidates, strip metadata you do not need, and inspect the result at final display size. The compress images without losing quality guide walks through the full pass. You can also reference Google's image format guidance for browser-support notes when you wire up fallbacks.

Common compression mistakes

• Re-compressing an already-lossy JPEG. Each encode adds artifacts. Always edit from a master.
• Using PNG for every photograph because it feels safe. PNG has no quantization step, so a photo stays enormous.
• Trusting one quality number across formats. JPEG, WebP, and AVIF scales are not comparable.
• Optimizing before resizing. Downscale first — it is the single biggest byte saving available.
• Serving AVIF or WebP without a JPEG fallback. Older browsers and most email clients render nothing.
• Leaving 4:2:0 chroma subsampling on colored text. It smears reds and blues; use 4:4:4 or PNG for text.
• Ignoring encoding cost. AVIF's gains are real, but encoding it on every request can dominate CPU.

Summary: algorithms are a means, not the goal

Compression algorithms are not free wins. AVIF gives you the smallest files, but its encode cost can be punishing in a hot path, and its decoding is heavier than JPEG on low-end devices. PNG is perfectly lossless, but shipping it for a hero photograph will bloat your Largest Contentful Paint for no visible benefit. The right answer is almost always a format-per-content decision served with a fallback, not a single global setting.

The most useful skill is not memorizing quantization matrices — it is judging each image at its actual display size, keeping a clean master, and re-encoding once instead of compounding loss. Get that workflow right and the specific format becomes a secondary choice.

Frequently asked questions

What is the difference between lossy and lossless image compression?

Lossy compression discards perceptual detail permanently for far smaller files, while lossless compression reconstructs the original pixel-for-pixel by removing only redundancy.

Why does JPEG use the discrete cosine transform?

The DCT concentrates each 8x8 pixel block's energy into a handful of frequency coefficients so quantization can discard the least visible ones with minimal quality loss.

What does Huffman coding actually compress in a JPEG file?

Huffman coding assigns shorter binary codes to the most frequent quantized values, which is where a large share of JPEG's final byte savings actually comes from.

How does GIF's LZW compression differ from PNG's approach?

LZW builds an on-the-fly dictionary of repeated byte patterns, while PNG first filters each scanline with a predictor and then runs Deflate (LZ77 plus Huffman) on the result.

Why is GIF a poor choice for photographs?

GIF's forced 256-color palette, applied before LZW ever runs, damages photographic detail far more than the LZW compression itself could.

How much smaller is AVIF than JPEG in practice?

In a direct encode of the same 1200x800 photograph, AVIF at quality 60 came out roughly 45 percent smaller than JPEG at quality 75 and about 26 percent smaller than WebP at quality 75, at visually matched quality.

Why does AVIF encode so much slower than WebP?

AVIF's larger block sizes, 67 directional prediction modes, and in-loop filtering make it roughly 5 to 10 times more computationally expensive to encode than WebP.

Should you always convert images to AVIF for the smallest file size?

Not always — AVIF's slow encoding can strain a hot request path, and it still needs a JPEG fallback for older browsers and email clients.

Image credits

• Abstract pixelated pattern in blue and pink — photo by Suzy Hazelwood on Pexels
• Colorful test-pattern bars — photo by Tim Mossholder on Pexels
• Close-up of colorful source code on a screen — photo by Pixabay on Pexels