JPEG Quantization Tables Explained: Why Quality 80 Isn't Always Quality 80

Set a JPEG to "quality 80" in one tool, then open the same photo in a different editor, set it to quality 80 there too, and compare the two files. They won't match — not in file size, not in sharpness, sometimes not even close. This isn't a bug in either tool. It's because "quality 80" was never a precise, universal number to begin with. It's a convenience layer sitting on top of the thing that actually controls compression: the quantization table.

A Quick Primer on How JPEG Actually Compresses an Image

JPEG doesn't compress a photo as one continuous image. It chops the picture into a grid of 8x8 pixel blocks and processes each block independently. For each block, it runs a mathematical transform called the Discrete Cosine Transform (DCT), which converts the raw pixel values into a set of 64 frequency coefficients — essentially a description of how much of the block's detail lives in coarse patterns versus fine, high-frequency detail.

Here's the part that actually creates the compression: those 64 coefficients then get divided by 64 corresponding numbers from a quantization table, and the results are rounded to the nearest integer. Rounding is where information gets thrown away — a coefficient that was 47.3 might round down to 47, but a small one like 2.1 divided by a large quantization value might round all the way down to 0. Once enough of those high-frequency coefficients round to zero, they take almost no space at all to store, which is where the file-size savings actually come from.

What a Quantization Table Actually Looks Like

A quantization table is just an 8x8 grid of numbers, one for each of the 64 DCT coefficients in a block. Small numbers near the top-left preserve more detail (since that corner represents the coarse, low-frequency information the eye is most sensitive to); larger numbers toward the bottom-right discard more of the fine detail the eye is least likely to notice missing.

The JPEG standard itself doesn't mandate one specific table — it provides example tables in its annex that became the de facto baseline nearly every encoder builds from. Here's the standard luminance (brightness) table defined in the JPEG specification:

The standard JPEG luminance quantization table (quality 50 baseline)

Notice the pattern: small values (10-20) cluster in the top-left, climbing to over 100 in the bottom-right. That's the table doing exactly what was described above — protecting the coarse detail the eye cares about most, sacrificing the fine detail first. There's a separate, more aggressive table used for color information (chrominance), since human vision is far less sensitive to color detail than to brightness detail, which is part of why JPEG can compress color images so effectively without obvious quality loss.

How a "Quality" Number Becomes an Actual Table

This base table corresponds to roughly quality 50. To get other quality levels, encoders scale every value in the table up or down using a formula that traces back to the Independent JPEG Group's original reference implementation, which most modern encoders still follow in spirit:

• For quality below 50: scale factor = 5000 ÷ quality
• For quality 50 and above: scale factor = 200 − (quality × 2)

Each value in the base table is then multiplied by that scale factor, divided by 100, and rounded — with the result clamped so no table value ever falls below 1. At quality 100, most values collapse down toward 1, meaning almost no information gets discarded (this is why quality 100 files are so much larger, not because of some separate "maximum quality mode," but because the quantization table itself becomes nearly transparent). At low quality settings, the scale factor grows large, and even the smallest base values balloon into large divisors that discard most of the fine detail.

Here's what that formula actually produces when you run the numbers, tracking two specific coefficients from the base table above — the most-protected top-left value (16) and a mid-frequency value further into the table (40):

Computed directly from the standard IJG scaling formula — quality 50 reproduces the base table exactly, by design.

A few things worth noticing in that table. Quality 50 reproduces the base table values exactly (16 and 40) — that's not a coincidence, it's why the standard base table is defined at quality 50 in the first place, as the fixed midpoint the formula scales around. Below quality 50, the scale factor grows sharply — dropping from quality 50 to quality 10 multiplies the divisor by 5x, which is a much bigger jump than the equivalent step from quality 50 to quality 90 in the other direction. This asymmetry is exactly why the low end of a quality slider feels so much more sensitive than the high end: the same 10-point movement near the bottom of the scale swings the actual compression far more aggressively than the same 10-point movement near the top.

Why Quality 80 in One Tool Isn't Quality 80 in Another

Here's where the inconsistency actually comes from. The scaling formula above is a convention, not a hard requirement of the JPEG standard — the standard defines how quantization tables are used to encode and decode an image, but it never mandates that every encoder must derive its tables from this exact base table using this exact formula. In practice:

• Different encoders start from different base tables. Some, like the classic IJG library, use the table shown above. Others, including newer encoders like mozjpeg, use custom-tuned base tables designed to look better to the human eye at the same file size, even though the "quality" number reported is nominally on the same 0-100 scale.
• Some software uses an entirely different quality scale. Photoshop's "Save for Web" quality setting, for instance, runs on a 0-12 scale internally, which gets mapped to a JPEG quality percentage in a way that doesn't line up cleanly with the standard 0-100 scale used elsewhere.
• Browsers' built-in JPEG encoders — the ones powering browser-based tools like CompressFor, since everything runs through the Canvas API rather than a server — follow the browser's own implementation, which in Chrome and most Chromium-based browsers is built on libjpeg-turbo, generally tracking the standard table and formula closely, though exact behavior can still shift slightly between browser versions.

The practical result: "quality 80" is a meaningful, consistent number *within* one tool, one version, one encoder. It is not a portable, universal measurement you can compare across different software and expect identical results from.

Why This Matters for Compressing to an Exact File Size

This directly explains something covered in our guide on why compressing to an exact file size is harder than it looks: a single quality number doesn't map predictably to a file size, because the quantization table it produces interacts with the actual content of the image. A quantization table that zeroes out fine detail saves almost no space on a plain, low-detail image (there wasn't much fine detail to discard in the first place), but saves enormous space on a busy, highly-detailed photo.

This is also exactly why exact-size compressors can't just calculate the "right" quality number in a single step and move on. Since quality doesn't map predictably to file size — both because of image content and because of encoder-specific table differences — the only reliable approach is to actually try a quality level, measure the resulting file size, and adjust from there, narrowing in on the target through repeated attempts rather than a single calculation.

What This Means in Practice

A few practical takeaways from all of this:

• Don't compare "quality" numbers across different tools. Quality 85 in one editor and quality 85 in another can produce visibly different results. If you're chasing a specific look or file size, judge the actual output, not the number on the slider.
• Re-saving a JPEG at the same quality number repeatedly still degrades it. Each save re-runs the full DCT-and-quantize process on data that's already lost information from the previous save, compounding the loss even if the quality number stays identical.
• A quality setting around 75-85 is a safe default for photos across nearly all encoders, since this range sits comfortably above the point where compression artifacts become visible on most images, regardless of exactly which base table an encoder uses.
• If you need a specific file size rather than a specific quality number, use a tool built to search for that target directly rather than guessing at a quality percentage — see our guide on compressing an image to exactly 50KB for the practical version of this.

None of this changes how you should actually use a compressor day to day — for that, a quality slider and a size target are still the right tools. But understanding what's actually happening underneath explains why "quality 80" behaves the way it does, and why exact-size compression has to work the way it works rather than through a simpler shortcut.

Frequently Asked Questions

What is a JPEG quantization table?

A quantization table is an 8x8 grid of numbers that controls how much detail is discarded from each 8x8 block of pixels during JPEG compression. Higher numbers in the table mean more detail is thrown away in that part of the frequency spectrum, which is how JPEG trades quality for file size.

Why does quality 80 look different between two different tools?

The JPEG standard defines how quantization tables are used, but it doesn't mandate a single official mapping from a 0-100 quality number to specific table values. Different encoders scale the base tables differently, so the same quality number can produce different actual compression levels depending on which software made the file.

Is a higher quality number always a bigger file?

Within the same encoder and the same image, yes. But across different images or different encoders, no. A simple image at quality 90 can be smaller than a detailed image at quality 60, because quantization tables interact with image content, not just the quality number in isolation.

Does this affect exact-file-size compression?

Yes, directly. It's the reason exact-size compressors can't simply calculate the right quality number in one step and have to search for it instead, trying different quality levels and checking the resulting file size until it lands close to the target.

Can I see the quantization table used in my own JPEG file?

Yes, with the right tool. JPEG files store their quantization tables directly in the file header, and dedicated inspection tools can read and display them, though most everyday photo editors and compressors don't expose this information in their normal interface.

Related Guides

• What to Do If the File Is Too Large
• How to Compress Your Image to 50KB
• How to Reduce Image Size Without Losing Quality
• How Browsers Decode and Render Your Images
• What is an Image Compressor and How Does It Work?