How Image Compression Works — Resolution, Quality, Chroma Subsampling and Metadata

A photo's file size is determined by "how many pixels, how many bits per pixel, and what extra information" is stored. It's common for a single smartphone photo to be 3–5MB while an application upload form asks for 100–500KB, and there are five main ways to close that gap. This article explains how each one affects file size and image quality, and in what order to adjust them when you need to hit a target size.

1. Resolution — the most reliable way to shrink a file

The raw data size before compression is width in pixels × height in pixels × 3 bytes (RGB). A 4032×3024 photo has about 12.19 million pixels, or roughly 36MB of raw data. Halving both the width and height cuts the pixel count to one quarter, and the compressed file shrinks by roughly the same proportion.

When a required pixel size is fixed, as with application photos, resize to that size first. That alone often gets you under the target size. The Korean Ministry of Foreign Affairs recommends 413×531 pixels for online passport photos and requires 500KB or less; a JPG resized to those dimensions usually clears the limit comfortably even at high quality.

2. Quality and quantization — what the "quality" slider in JPG and WebP does

JPG splits the image into 8×8 blocks, converts them into frequency components, then divides each component by a value from the quantization table and rounds the result. Lowering the quality raises these divisors, so more high-frequency components become 0 after rounding. When zeros run on in long stretches, the entropy coding that follows (Huffman coding) represents them very compactly, and the file gets smaller.

• Quality 90 and above: hard to tell apart from the original by eye, but this is where file size climbs steeply.
• Quality 70–85: the most efficient range for photos. Most web photos fall here.
• Quality 50 and below: banding in sky and skin, smudges around edges (ringing), and 8×8 block boundaries start to show.

The relationship between quality and file size isn't linear. Dropping quality from 95 to 85 shrinks the file a lot, while dropping from 60 to 50 saves less and makes the damage more noticeable. So if you'd have to go below quality 60, reducing the resolution gives a better result.

3. Chroma subsampling — storing less color information

The human eye is sensitive to changes in brightness but less sensitive to changes in color. So JPG and lossy WebP commonly convert RGB into brightness (Y) and color difference (Cb, Cr), then store the color difference at half the resolution horizontally and vertically (4:2:0). This alone cuts color information to a quarter and halves the total raw data.

In photos the difference is barely visible, but in images with red text or thin colored lines, the edges of letters may look smeared. Lossy WebP always uses 4:2:0 by specification (MDN), so for graphics where colored text matters, PNG or lossless WebP is a better fit.

4. Metadata — tens of KB hidden inside a photo

Smartphone photos carry EXIF information such as the device, time and GPS coordinates, along with a small preview thumbnail and a color profile (ICC). This usually amounts to a few KB to a few dozen KB — a small share of the total — but when the target is tiny, like 100KB or less, it can't be ignored. Above all, the problem is that location data stays in the file. Re-encoding through the browser's Canvas strips most of this information. For details, see EXIF metadata and privacy.

5. Format choice — the same quality in fewer bytes

At the same quality, newer codecs are smaller. Google reports that lossy WebP is 25–34% smaller than JPG at the same SSIM quality, and AVIF is usually smaller still. But if the recipient only accepts JPG you can't change the format, so this approach is mainly for publishing on the web. Differences between formats are summarized in JPG vs PNG vs WebP vs AVIF.

Quality values aren't comparable across formats or programs

"Quality 80" is not a unit defined by any standard. Each encoder maps the quality value to quantization strength in its own way, so the same 80 produces different quality and file sizes in JPG, WebP and AVIF — and even for JPG it differs slightly from program to program. So rather than relying on an absolute rule like "save at X," it's more accurate to decide by zooming in and comparing the output with the original. When processing many images under the same conditions, test on one first and then apply the settings to the rest.

Progressive JPG

Besides the baseline mode, which draws the image top to bottom in a single pass, the JPG standard (T.81) also defines a progressive mode that shows a blurry version of the whole image first and then sharpens it step by step. It improves perceived speed when viewing large photos over a slow connection. The size difference depends on the photo, and some older devices and programs can't read progressive JPGs, so baseline is the safe choice for submissions.

A worked example

Suppose you need to upload a 4032×3024 smartphone photo (about 3–4MB) at "1000 pixels wide or less, 200KB or less."

1. First, reduce the width to 1000 pixels. The height becomes 750 pixels to keep the ratio, and the pixel count drops to about 6% of the original. This step alone usually brings it down to a few hundred KB or less.
2. Save at quality 85 and see whether it exceeds 200KB. If it does, lower the quality to 80, then 75, or find it with a binary search.
3. If the photo is noisy, like a night shot, and you'd need to go below quality 60, shrinking a bit further to 900 pixels wide gives a cleaner result.

The order for hitting a target size (KB)

When meeting a requirement like "please upload 200KB or less," this order causes the least quality loss.

1. First resize to the required pixel dimensions. If a spec exists, use that size; otherwise, use the size it will be displayed at (e.g., 1200–2000px wide).
2. Find the quality with a binary search. Save at the midpoint between quality 50 and 95; if the result is larger than the target, split the lower half again, and if smaller, the upper half. In 7–8 tries you can find the highest quality that stays under the target.
3. If the quality gets too low, reduce the resolution a little more. Cutting width and height by 10% reduces the pixel count by about 19%. Then repeat step 2.
4. Check how KB is defined. Some sites treat 1KB as 1,000 bytes and others as 1,024 bytes. If you don't know, calculate with 1,000 bytes and make the file smaller — that passes under both definitions.
5. Distinguish "under" from "or less." If the rule says "under 100KB," a file of exactly 100KB won't pass.

The Compress Image tool does this automatically. Enter a target size in KB and it binary-searches the quality, reducing the resolution when it hits the quality floor, and picks the sharpest result that stays under the target.

Common mistakes

• Re-saving a compressed file at higher quality: re-saving a JPG already saved at quality 60 at quality 95 only makes the file bigger; the lost quality doesn't come back.
• Compressing repeatedly: loss accumulates with every save. Always produce the result you want from the original in one go.
• Compressing screenshots as JPG: text gets mushy, and the file can even end up larger than a PNG. Keep screenshots as PNG or reduce their resolution.

Frequently asked questions

Last updated: 2026-09-23

Sources

• ITU-T Recommendation T.81 (09/92) — JPEG specification
• Google for Developers — An image format for the Web (WebP)
• MDN — Image file type and format guide
• Korean Ministry of Foreign Affairs passport portal — Online passport photo check (file specs)