JPEG size reducer: luma dies first, chroma follows — measured

The channel split: nine budgets, three channels

The source is a 3000 × 2000 night photograph, 689,299 bytes, already JPEG. Each row is one run at one byte target, JPEG output. The three error columns are the mean absolute per-pixel difference on the 0–255 scale, measured against the original photograph at its full 3000 × 2000 frame, with each output upscaled back to that frame before comparison.

Read the quality column first. From 200 KB up it moves — 58.28%, 76.09%, 81.25% — and the dimensions stay at 3000 × 2000. From 100 KB down it is pinned at 40.47% (41.41% at 10 KB), and the dimensions shrink. Two regimes, one boundary, and the channel split moves with the boundary.

Two regimes: what changes at 200 KB

Above 200 KB the tool pays quality. Every additional byte buys a higher quality factor, which means finer quantization steps, which means smaller errors on all three channels. The Y error drops from 1.198 at 200 KB to 0.806 at 500 KB — a 33% reduction for 2.5× the bytes. Cb drops from 0.712 to 0.343, a 52% reduction. Cr drops from 0.680 to 0.365, a 46% reduction. In this regime chroma benefits more from each additional byte than luma does, which is why the Cb ÷ Y ratio falls from 0.594 to 0.426: the better the quality, the more the remaining error is luma, because the quantization matrix is already preserving chroma well.

Below 200 KB the tool hits the 40.47% quality floor and switches to scaling the picture. Now each additional byte buys pixels, not quality — and pixels are a luma asset. The 3000 × 2000 original carries its detail in the Y channel; when the tool shrinks to 2482 × 1655, the detail lost is luma detail, and the Y error rises. The Cb ÷ Y ratio climbs from 0.594 at 200 KB to 0.632 at 100 KB and 0.558 at 10 KB — meaning luma is taking a growing share of the new damage as the picture gets smaller. The ratio is not monotone (it dips at the extremes), but it never returns to the 0.41–0.43 range that the high-quality regime produces.

Why chroma starts lower and grows slower

JPEG's 4:2:0 chroma subsampling is the first thing that happens in the encoder, before the byte target has any say. Each 2×2 block of luma pixels shares one Cb sample and one Cr sample — the colour channels are at half width and half height from the start. That means two things for the error budget.

First, the chroma channels carry less information to lose. The original 3000 × 2000 photograph has 6,000,000 luma values but only 1,500,000 Cb and 1,500,000 Cr values in the JPEG representation — the other 4,500,000 colour samples were discarded at encode time. When the tool measures the error against the full-resolution original, it upscales the JPEG's half-resolution chroma back, and that upscaling itself is a smoothing operation. The error is measured against a source whose colour was already reduced, so it starts low.

Second, when the tool cuts pixels in the low-budget regime, it scales the whole image — luma, Cb and Cr together. The luma channel goes from 3000 × 2000 to, say, 1230 × 820, losing detail that was there. The chroma channels go from 1500 × 1000 (already subsampled) to 615 × 410, losing detail that was already sparse. The pixel-loss damage falls harder on luma because luma had more to lose. That is the measured 69% Y growth versus 33% Cr growth across the 100 KB to 10 KB range — a 2.1× ratio of damage rates that traces directly to the subsampling step.

The Cb ÷ Y ratio: a single number for the regime

The Cb ÷ Y column condenses the two regimes into one number. In the quality regime (200–500 KB) it sits at 0.41–0.59: chroma error is about half of luma error, and the ratio falls as quality improves. In the pixel regime (10–100 KB) it sits at 0.56–0.63: chroma error is a larger fraction of luma error, because luma is absorbing more of the pixel-loss damage. The boundary between the two ranges — 0.594 at 200 KB and 0.632 at 100 KB — is the same boundary the quality column shows: 58.28% to 40.47%, original dimensions to scaled.

This ratio is not a universal constant. A photograph with more colour variation (a sunset, a market stall, a painting) would start with higher chroma error and probably show a higher Cb ÷ Y throughout. A photograph with almost no colour (a black-and-white document scanned as JPEG) would show a Cb ÷ Y near zero, because Cb and Cr would be near-flat and near-error-free regardless of the target. What this page measures is one night photograph — rich in luma detail, moderate in colour — and the two-regime shape is what the mechanism predicts for any JPEG input, though the ratio values would shift with the picture.

What "compress image size" means for JPEG specifically

A general image compressor handles PNG, WebP, JPEG and other formats, each with its own loss mechanism. A JPEG size reducer is the narrower case: the input is already JPEG, which means the colour is already subsampled and the coefficients are already quantized. Re-encoding a JPEG to a smaller JPEG is therefore not the same as encoding a raw image — the second encode is quantizing coefficients that the first encode already flattened. The second-pass page measured the cost of that re-quantization directly: a tenth of a level per extra pass. This page measures the cost of the first pass, split by channel, and the finding is that the first pass's damage is luma-heavy by a factor of 1.4 to 2.4 at every budget.

If the file must stay JPEG, the lever you have is the byte target, and the channel split tells you what that lever spends. Above 200 KB it spends quantization — all channels improve, chroma faster than luma. Below 200 KB it spends pixels — luma deteriorates faster because detail is a luma property. If the file does not need to stay JPEG, WebP at the same byte count buys 37.5% more pixels, and the lossless PNG route removes bytes without touching a pixel — different mechanisms, different trade-offs, different pages.

Reduce jpg file size: the channel view

Someone searching to reduce jpg file size is usually after one number: fewer bytes. The channel split does not change that number — it explains where the quality cost of getting there lands. The practical read is that a JPEG reduced to 100 KB or below has lost more brightness detail than colour detail, which means the output looks softer (luma blur) before it looks desaturated (chroma smear). At 200 KB and above the output looks lower-contrast but not softer, because the tool kept the pixels and paid quality — and quality loss in JPEG is evenly spread across the frequency domain, not concentrated in luma. The nine rows above are the measured version of that statement; the 200 KB page is the same boundary seen from the quality side, without the channel split.

Image quality reducer: reading the table backwards

If the goal is an image quality reducer — keep the file size roughly fixed and maximise quality — the table reads from bottom to top. At 500 KB the quality was 81.25% and the Y error was 0.806; at 300 KB the quality was 76.09% and the Y error was 0.928. The marginal cost of going from 500 KB to 300 KB — giving up 204,832 bytes — was 5.16 quality points and 0.122 Y levels. The marginal cost of going from 300 KB to 200 KB — giving up 95,433 more bytes — was 17.81 quality points and 0.270 Y levels. The marginal cost of going from 200 KB to 100 KB — giving up 100,199 bytes — was zero quality points (the floor held) and 0.330 Y levels, plus 2,065,750 pixels. Three steps, three very different bills, and the expensive one is the one that crosses the 200 KB boundary.

Photo compressor online: in this tab, not on a server

This is a photo compressor online in the literal sense — it runs in the browser — but the processing never leaves your machine. The photograph is decoded, re-encoded and returned inside the tab; no request carrying it goes to a server. That is also why these numbers reproduce: the same input bytes with the same target return the same output bytes — 202,286 at 200 KB, 102,087 at 100 KB, 61,310 at 60 KB, 20,385 at 20 KB, matching this site's runs from previous sessions on the identical photograph. A reducer you can re-run is a reducer you can verify, and every number above is one run deep in a browser anyone can open.

How to reduce a JPEG with the channel split in mind

1. Check whether 200 KB is available. If the upload form or the target allows 200 KB or more, the tool will keep all your pixels and pay quality — and the quality regime is where chroma recovers fastest. The Y error at 200 KB was 1.198; at 100 KB it was 1.528. That 0.330 gap is the price of crossing the boundary.
2. If the target is below 200 KB, expect softness before desaturation. The pixel regime cuts luma detail first. The output will look blurry (lost edges, lost texture) before it looks washed out (lost colour), because Y grows faster than Cb or Cr.
3. Set the target, drop the file, read the verdict. Bytes, dimensions and quality are on the result line. The channel split is the analysis behind those numbers — it does not change the output, it explains it.
4. If the file came back "already inside your limit", stop. Running it again at the same target returns the identical file — measured on the second-pass page with 0 ms encoder time and 100% identical pixels.

Questions this page gets

Does JPEG compression damage colour more than brightness?

No. On this tool, luma (Y) took more damage at every target measured. At 10 KB the Y mean error was 2.571; Cb was 1.436 and Cr was 1.096. At 500 KB the split was Y 0.806, Cb 0.343, Cr 0.365. The Cb-to-Y ratio never exceeded 0.63, meaning chroma error was consistently the smaller half of luma error. The common belief that JPEG "kills colour first" describes the 4:2:0 subsampling step, which does halve colour resolution before quantization — but that step is fixed and target-independent. As the byte budget tightens, the additional damage falls harder on luma, not on chroma.

Why does JPEG subsample colour before compressing?

Because the human visual system is less sensitive to colour detail than to brightness detail. JPEG's 4:2:0 subsampling keeps one Cb and one Cr sample for every 2×2 block of luma samples, reducing the colour data to one quarter of the luma data before quantization begins. That fixed reduction is why chroma error starts lower and grows more slowly than luma error as the budget tightens — the colour information was already reduced at a stage the byte target does not control.

At what file size does the reducer switch from quality loss to pixel loss?

At 200 KB for this 6-megapixel photograph. Above 200 KB the tool kept all 6,000,000 pixels and paid quality (58.28% at 200 KB, 76.09% at 300 KB, 81.25% at 500 KB). Below 200 KB quality hit the 40.47% floor and the tool scaled the picture — 2482 × 1655 at 100 KB, 623 × 415 at 10 KB. The Cb-to-Y ratio confirms the switch: it jumped from 0.594 at 200 KB to 0.632 at 100 KB, meaning luma started absorbing a larger share of the new damage.

Is there a way to reduce JPEG size without any quality loss?

Not within JPEG — any reduction below the current file size requires re-quantization, which is lossy by construction. The lossless alternative is to re-encode the container without touching the pixels, which is what the PNG size reducer page measures (18–36% smaller, pixels identical by hash). If the file must stay JPEG, the best you can do is one pass to the final target — the second-pass page measured the cost of going lower from an already-reduced file.

Does "jpeg size reducer" work differently on .jpg and .jpeg files?

Not on this tool. The encoder decodes the file and re-encodes the pixels, so the extension never reaches it — this site ran one photograph as .jpg, .jpeg and .jpg again on the 60 KB page and all three returned 61,310 bytes, identical byte for byte.

Is my file uploaded?

No. Decode, re-encode and the compliance check all happen in the tab. The numbers on this page were produced by the same in-browser compressor you can run yourself.

Where the numbers come from. All figures measured on 5 November 2026 with Chrome 157.0.8103.38 (headless, driven over the DevTools protocol) on Windows 11, using this site's compressor through its published interface, one run per row, each in a fresh tab. Source: a 3000 × 2000 night photograph, 689,299 bytes. Output bytes were confirmed two ways on all nine runs — the tool's report and a FileReader read of the returned blob, all equal; dimensions two ways (createImageBitmap and an image element), all equal. The Y/Cb/Cr split converts each pixel to YCbCr per the JFIF spec (ITU-R BT.601 coefficients) and measures the mean absolute error of each channel against the source at full frame, with each output upscaled back to 3000 × 2000 before comparison. Two independent decode paths agreed to within 0.058 levels on every row and every channel. One photograph is one sample point: a different picture will produce different error values, though the two-regime shape — luma-heavy below 200 KB, chroma-faster-recovering above — is what the JPEG mechanism predicts for any input.

Read these alongside: where the bytes come off cuts the same photograph into 40 tiles and shows the damage landing on texture, not evenly; the segment audit parses each output byte by byte and shows the quantization tables staying at 138 bytes across every target; the KB ladder puts six single-pass budgets in one page; 200 KB is the boundary where quality stops and pixels start; the second-pass page measures what one extra encode costs; WebP is what the same bytes buy in a different format; and the PNG size reducer is the lossless alternative — bytes off the file with every pixel identical by hash.