How to tell if a JPG was compressed too much

Last reviewed 2026-05-04. Most "this JPG looks bad" complaints are over-compression rather than a small or low-resolution source: the file was saved at a low quality value (or re-saved several times) and detail was discarded each pass. The free JPEG Compression Level Checker reads the quality value the file was saved with so you can decide whether the image still has room to compress further or whether it has already been pushed past the visible-artifact threshold and re-encoding will only make it worse.

What the JPEG quality value actually means

JPEG (the lossy image format defined by ITU-T T.81 / ISO/IEC 10918-1) compresses by dividing the image into 8x8 pixel blocks, transforming each block to frequency space (the Discrete Cosine Transform), and dividing the frequency coefficients by a per-frequency quantization table - a 64-entry matrix of integers. Higher integers in the table mean more aggressive rounding and more bytes saved; lower integers mean finer detail preserved at the cost of file size. The "quality" number you see in image editors is a 1-100 dial that scales these quantization tables: every encoder applies the dial slightly differently, but the well-known Independent JPEG Group `cjpeg` convention (the de-facto reference behind Photoshop, ImageMagick, GIMP and most web tools) maps q100 to "no quantization" (almost lossless), q75 to a balanced web default, and lower values to progressively coarser tables. The quality value is stored alongside the JPEG so a reader can recover it later - which is what the JPEG Compression Level Checker reads back.

Reading the saved-with quality of an existing JPG

Upload the file to JPEG Compression Level Checker and the tool inspects the quantization tables embedded in the file and estimates the IJG-equivalent quality value the JPG was saved at. The file is processed on the freetoolonline AWS service (the standard upload pipeline) and the quality value is returned for inspection - useful when you have a JPG of unknown origin (downloaded from the web, sent over chat, exported from an unknown editor) and want to know its compression headroom before deciding whether to compress further.

Four visible signs of over-compression

The quality number is a useful proxy, but a JPG can also be diagnosed visually. The four signs below are all consequences of the 8x8 DCT + aggressive quantization that JPEG uses; a JPG showing any one of them at 100% zoom has been compressed past the comfortable threshold for that content.

• Blockiness on smooth areas. A blue sky or plain wall starts to show faint 8x8 pixel squares, especially when colour transitions slowly. This is the most reliable sign of low-quality JPEG: the smooth gradient is being approximated by piecewise-constant blocks.
• Ringing halos near sharp edges. Around high-contrast edges (text on a plain background, the silhouette of a building against the sky, a black logo on white) you see faint ghost echoes of the edge - a few pixels of "ring" before and after. This is the high-frequency DCT coefficients being clipped by the quantization step; the encoder cannot represent a perfect step edge with the budget it has.
• Color bleeding and banding. Smooth gradients (a sunset, a backdrop fade) start to show step transitions instead of a continuous blend. Colours run slightly outside their boundaries because JPEG sub-samples chroma at lower resolution than luma (the 4:2:0 default).
• Loss of fine detail. Eyelashes, fabric weave, hair, fine text, and small leaves on a tree all blur into mush. The high-frequency information is gone; no editing can recover it from the JPEG alone.

Why re-encoding usually makes it worse

JPEG is a lossy format: every save discards information. Re-saving an already-compressed JPG (even at a higher quality number) does not recover the detail that was thrown away in the first encode - it just adds a fresh round of quantization on top of the already-quantized data. This is generation loss, and it shows up as cumulative softness, drifting colours, and growing blocking. So once a JPG is below roughly q60 the right move is almost never "compress it again at q90" - it is "go back to the original and re-export". If you do not have the original, treat the existing JPG as the floor: use it as-is rather than re-saving.

The exception is when you are intentionally shrinking a JPG for a specific delivery (an email attachment, a chat upload). In that case the right tool is Compress Image on the original (highest-quality available) source - not on a previously-compressed JPG. See How to Choose a Compression Level - Quality vs File Size for a quality-value picker keyed to delivery channel, and When to Compress vs Convert an Image for the format-choice question.

Quality-value cheat sheet (IJG cjpeg convention)

The IJG `cjpeg -quality` convention is the practical scale most tools follow. Use these as guideposts when reading a value from JPEG Compression Level Checker.

• q95 to q100 - print baseline. Visually identical to the original on screen; file size is large. This is what high-end editors export when they want JPEG without visible loss.
• q85 to q94 - the visual breakpoint. Most viewers cannot tell this apart from the original at normal viewing distance; file size is roughly half of q95.
• q75 to q84 - the web default. Photoshop "Save for Web" and most CMS image pipelines target this band. Artifacts begin to be visible on careful inspection of smooth areas but not in everyday viewing.
• q60 to q74 - the artifact zone. Blocking and ringing appear on attention; this is where chat / messaging apps often re-encode shared photos.
• Below q60 - already over-compressed. Use the file as-is or replace it from the original; do not re-save.

Companion guides on the JPG / image-conversion cluster: How to Choose a Compression Level - Quality vs File Size (the choose-before counterpart to this read-after guide), JPG vs PNG for the Web (format choice), HEIC vs JPG vs WebP (format choice across modern alternatives), and When to Compress vs Convert an Image (compress vs format-change decision).