How Image Compression Works: JPEG, PNG, WebP and AVIF Explained

Store a 4000×3000 photo with no compression at all and you need 12 million pixels × 3 bytes (red, green, blue) — about 36 MB. The same photo sits in your phone’s camera roll at 3–5 MB. Image compression closes that gap of roughly 90%, and it does so in one of two fundamentally different ways.

Lossless vs lossy: can you get the original back?

Lossless compression must decode to exactly the same pixels, bit for bit. It works like a ZIP file: it finds repetition and structure and writes them down more compactly. How much it saves depends entirely on how predictable the image is. A diagram with a white background and a few shapes can shrink dozens of times; a noisy night shot barely shrinks at all. PNG, GIF and lossless WebP are in this camp.

Lossy compression throws information away for good. It targets detail the eye is unlikely to notice, and the “quality” setting controls how much gets discarded. JPEG, lossy WebP and AVIF work this way. Lossy codecs dominate for photos because most of a photo’s raw data describes tiny variations — sensor noise, fine texture — that nobody can see at normal viewing size.

A common misconception is that PNG means high quality and JPEG means low quality. Save a photo that has already been through JPEG as a PNG and you preserve every JPEG artefact faithfully while making the file several times larger. Quality is decided once, at the moment detail is discarded; the file format only decides how efficiently what is left gets stored.

JPEG: separate the colour, transform, round off

The JPEG standard, ITU-T T.81, was approved in September 1992. It is still the most widely used photo format, and later lossy image codecs follow the same basic recipe.

Step 1: split brightness from colour

The encoder converts RGB into one brightness channel (Y) and two colour-difference channels (Cb and Cr). Human vision is sensitive to changes in brightness but relatively poor at resolving fine colour detail, so the colour channels can be stored at lower resolution without most people noticing. Halving them both horizontally and vertically is called 4:2:0 subsampling and cuts colour data to a quarter. Halving only horizontally is 4:2:2; keeping full resolution is 4:4:4.

This is also where a familiar artefact starts. Thin red text on white has a small brightness difference but a large colour difference. At half colour resolution, the red spills into neighbouring pixels and the edges look smudged. That is why the problem is invisible in holiday photos but obvious in banners, charts and screenshots of subtitles.

Step 2: 8×8 blocks and the DCT

Each channel is cut into 8×8 blocks, and each block goes through a discrete cosine transform (DCT). The DCT turns 64 pixel values into 64 frequency coefficients. The top-left one (the DC coefficient) is the block’s average; moving toward the bottom-right, coefficients describe increasingly fine stripe patterns. The transform itself loses nothing — it is the same information expressed on different axes.

What makes it useful is that most blocks in a natural photo change gradually. Energy piles up in a few low-frequency coefficients, while the high-frequency ones are small numbers scattered near zero.

Step 3: quantization — the only lossy step

Each coefficient is divided by the matching number in a quantization table and rounded to an integer. The tables divide high frequencies by larger numbers, so most small high-frequency values become zero. The quality slider in a JPEG tool is essentially a scale factor on this table: lower quality means bigger divisors and more zeros.

Long runs of zeros are then written very compactly by Huffman coding (entropy coding), which is lossless again.

Where blocking and ringing come from

Push quality far down and each block keeps little more than its average and a couple of low frequencies. Because every block is approximated independently, neighbouring blocks stop lining up and the 8×8 grid becomes visible — the staircase you see in a blue sky or a painted wall.

Sharp edges such as text and thin lines need many high-frequency coefficients to be drawn accurately. Cut those off and you get rippled halos around the edge, known as ringing. That is the grime you see around letters when a screenshot is saved as JPEG.

Saving a JPEG as a JPEG again adds new quantization error on top of the old blocks. Even quality 100 cannot restore what was lost, and it often makes the file larger, because the encoder now dutifully preserves the old artefacts as if they were real detail.

PNG: store the differences, then deflate

PNG was designed in the mid-1990s as a patent-free alternative to GIF; its Third Edition became a W3C Recommendation in June 2025. Compression happens in two stages.

First, filtering. For every row the encoder picks one of five filters that replace each byte with a difference: None (no change), Sub (difference from the pixel to the left), Up (from the pixel above), Average (from the mean of left and above) and Paeth (a prediction from left, above and upper-left). Flat backgrounds and smooth gradients turn into zeros and small numbers.

Second, deflate — the same family of compression used in ZIP, combining LZ77 matching within a window of up to 32 KB with Huffman coding. Long runs of zeros collapse to almost nothing.

This makes PNG excellent for screenshots, interfaces, logos and diagrams, where colours are few and values repeat. Photographs are the opposite case: noise makes each pixel’s difference from its neighbours unpredictable, so the filters have little to work with. A photo saved as PNG is normally several times larger than the JPEG.

Two PNGs of the same image can also differ in size depending on which filter each row uses and how hard deflate searches for matches. That is why dedicated optimisers can shrink a PNG losslessly, and why re-saving a PNG through a browser’s built-in encoder can make it bigger than the original.

WebP: a photo format borrowed from video

Google announced WebP on the Chromium Blog on 30 September 2010. Lossy WebP reuses the keyframe compression of the VP8 video codec. It keeps JPEG’s DCT-and-quantization skeleton and adds two things:

• Block prediction: each block is predicted from neighbouring blocks that have already been decoded, and only the residual — the difference between prediction and reality — is transformed and stored.
• Adaptive bit allocation and arithmetic coding: the image is split into segments, spending fewer bits on flat regions and more on busy ones.

Lossless WebP is a separate design altogether, combining spatial prediction, colour decorrelation, palettes, LZ77 back-references and a cache of recently used colours. Google’s documentation reports WebP files about 30% smaller than PNG and JPEG at equivalent visual quality, and average savings of 60–70% when transparent PNGs are replaced by lossy WebP with alpha. Lossy compression plus a transparency channel is the combination JPEG simply cannot offer.

AVIF: a still frame from AV1

AVIF stores images compressed with AV1 — the video codec from the Alliance for Open Media — inside a HEIF container, which in turn is based on the ISO Base Media File Format. Larger, variable-size blocks, many directional prediction modes and strong filtering mean that at low bitrates AVIF tends to go soft rather than blocky. It can also carry HDR, wide colour gamuts and 10- or 12-bit colour.

The cost is encoding time. AVIF takes far longer to produce than JPEG or WebP, and the set of browsers that can encode it from a canvas is limited. Its quality scale also means something different — an AVIF at 50 frequently looks comparable to a JPEG at 80 — so never compare quality numbers across formats.

When browsers added support

According to Can I use, full support arrived in these versions:

Browser	WebP	AVIF
Chrome	32	85
Firefox	65	93
Safari	16.0 (partial in 14–15.6)	16.4 (iOS from 16.0)
Edge	18	121

Because Chrome shipped WebP years before Firefox and Safari, WebP long carried a reputation as the format that breaks on iPhones. Today both formats display for more than 95% of global browser usage. Keep in mind that displaying a format and encoding it are separate capabilities: a browser may show AVIF perfectly yet be unable to create an AVIF file from a canvas.

Which format for which job

Situation	Choose	Why
Ordinary photos for the web	WebP or AVIF; JPEG if compatibility worries you	Lossy compression pays off most here
Screenshots, documents, charts	PNG, or WebP at quality 90+	Avoids ringing around text and colour bleed
Logos and icons with transparency	High-quality WebP for delivery; keep PNG (or SVG) as the master	JPEG has no alpha channel
Masters you will keep editing	PNG or the camera original	Stops loss piling up with every save
Old systems, email attachments	JPEG	Opens everywhere

One rule matters more than any format choice: resolution is a bigger lever than quality. File size tracks pixel count, so taking a 4000-pixel photo down to 2000 pixels leaves a quarter of the pixels. If a photo will be displayed 1000 pixels wide, uploading it at 4000 pixels and cranking quality down to 40 gives you a larger and uglier file than resizing it first with the image resizer and keeping quality generous.

Where the size curve bends differs from photo to photo. The image compressor encodes at several quality levels and picks that point for you, and the image converter changes the format of many files at once.