Initializing, please wait a moment

Compressed JPG Looks Blurry? Three Causes (and Quick Fixes)

Last reviewed 2026-05-03. You compressed a JPG to make it smaller and the result looks blurry, blocky, or pixelated. This guide names the three common causes, gives a one-line fix per cause, and shows a 30-second side-by-side test to figure out which one you hit.

30-second answer. The compression quality dropped below 50, OR the source you compressed was already a JPG re-saved several times, OR the source had been upscaled to a larger resolution before you compressed it. Re-compress the original at quality 70-85 with a JPG / PNG / WebP image compressor and the result usually goes back to looking normal.

Cause 1: compression quality was too aggressive

JPG compression quality runs on a non-linear scale. Quality 90 looks visually identical to the original on most photos. Quality 70 starts to introduce a small amount of blocking in flat colour regions but stays acceptable for the web. Quality 50 looks visibly softer; quality 30 looks blocky in sky / skin / sand and most readers will call the result "blurry." If your tool defaulted to a low quality value (some online compressors default to 50 or even 30 to advertise dramatic file-size reductions), the output will look worse than it has to.

Fix. Re-compress the same source at quality 70-85. Most photos look fine at quality 80 and shrink to about a third of the original size; quality 85 is a safer choice when the photo has fine detail like hair or fabric. The cycle-37 guide compress JPEG without losing quality - quality vs size walks through the proactive quality-vs-size decision table if you want to pick the value before you compress, not after.

Cause 2: the source was already a JPG, re-saved multiple times

Every JPG re-encode loses information; re-encoding a JPG that has already been compressed amplifies the blocking and chroma artifacts from the previous round. If you saved the photo from a chat app, then dragged it into a presentation, then exported the presentation, then ran the export through an image compressor, the file you fed to the compressor was a third- or fourth-generation JPG. Each generation built on top of the previous one's artifacts.

Fix. Find the original. On an iPhone, the original is usually a HEIC file in the Camera Roll - export the HEIC, then compress that, not a JPG that was sent through Messages or WhatsApp. The guide iPhone photo format explained: HEIC, JPG, PNG, RAW shows where each format lives. On a desktop, look for the camera RAW (.CR2, .NEF, .ARW) or the first-generation JPG straight from the camera, not the version embedded in a Word document or a PDF export.

If the original is genuinely lost and the only copy you have is a re-saved JPG, the artifacts cannot be removed - only hidden. Compressing at high quality (90+) will not reintroduce the lost detail; the right move is to use the re-saved JPG at the resolution it was actually shot, not enlarge it back to the original size.

Cause 3: the source was upscaled before you compressed it

Upscaling - taking a 1080-px wide photo and resampling it to 4K, for example - fabricates pixels by interpolating between the originals. JPG compression then groups pixels into 8x8 DCT blocks and quantises them; when the input pixels are themselves interpolated guesses, the quantisation step bins them into mush. The result looks "soft" or "smeared," with straight edges turning wavy and fine textures becoming a uniform grey.

Fix. Compress at the ORIGINAL resolution. If you need a small file at a high resolution, the right approach is the opposite: keep the original resolution, compress at quality 75-85, and let the browser or the slide tool downscale at display time. Browsers downscale crisply; upscaling at compression time and then downscaling at display time stacks two lossy steps for no gain. If you do need a higher-resolution version of a small original, AI upscalers (separate tools, not the JPG compressor) are the right tool - they hallucinate detail consistently rather than letting JPG compression smear it.

The 30-second sanity-check (which cause is it?)

Open the original and the compressed result side-by-side at 100% zoom (one-to-one pixel mapping; do NOT let the browser fit-to-window). Then look at three regions:

  • Flat colour regions (sky, skin, walls): if you see blocky 8x8 patches or banding, the cause is too-low quality (Cause 1). Re-compress at quality 80+.
  • Fine textures (hair, fabric, foliage): if you see speckled noise that wasn't there in a previous version, the cause is repeated re-encodes (Cause 2). Find an earlier-generation source.
  • Straight edges and sharp corners: if edges look wavy, smeared, or "stairstepped", the cause is upscaled source (Cause 3). Compress at the original resolution.

If you see all three at once, the source was probably both upscaled AND re-saved several times - the fix is to find the original-resolution, first-generation copy and compress only that.

FAQ

Why does JPG quality 90 still introduce visible artifacts on my screenshot?
JPG was designed for natural photos; it does not handle hard edges (text, UI screenshots, line art) well even at quality 95. For screenshots, save as PNG instead - PNG is lossless and usually smaller for screenshot-style content. The guide JPG vs PNG for the web covers when each format wins.

What about WebP / AVIF as a JPG replacement?
WebP at quality 80 is roughly 25-35% smaller than JPG quality 80 with the same visual quality. AVIF is smaller still at the same quality. If your delivery target supports them (modern browsers do), they are a strict upgrade over JPG. The guide HEIC vs JPG vs WebP compares the three on quality, support, and file size.

Does compressing twice at quality 90 equal compressing once at quality 80?
No - the effects are different. Two rounds of quality 90 land at roughly quality 81 in size but introduce more blocking artifacts than a single quality-80 pass, because each round quantises afresh. One pass at the right quality always beats two passes at higher individual qualities for the same final size.

What's the right resolution for a web-delivered JPG?
For full-width hero images, 1600-2400 pixels wide is plenty - browsers downscale; the source does not need to be 4K. For thumbnails, 400-800 pixels wide. For body images, 800-1200 pixels wide. Combine the right resolution with quality 75-85 and you'll usually beat the file size of any single quality slider on a too-large source.

Can I un-blur an already-blurry compressed JPG?
Not really - the lost information is gone. AI sharpening tools can guess at detail, but the guess is fabricated, not recovered. The reliable fix is to find the original and compress that; if the original is genuinely lost, accept the size you have and avoid re-saving the result.

Related

Why trust these tools

  • Ten-plus years of web tooling. The freetoolonline editorial team has shipped browser-based utilities since 2015. The goal has never changed: get you to a working output fast, without an install.
  • Truly in-browser - no upload. Every file-processing tool on this site runs in your browser through modern Web APIs (File, FileReader, Canvas, Web Audio, WebGL, Web Workers). Your photo, PDF, audio, or text never leaves your device.
  • No tracking during tool use. Analytics ends at the page view. The actual input you paste, drop, or capture is never sent to any server and never written to any log.
  • Open-source core components. The processing engines underneath (libheif, libde265, pdf-lib, terser, clean-css, ffmpeg.wasm, and others) are public and audit-able. We link to each one in its tool page's footer.
  • Free, with or without ads. All tools are fully functional without sign-up. The Disable Ads button in the header is always available if you need a distraction-free run.