How to compress an image without visibly losing quality

Image compression has a reputation for ruining pictures, and it earned that reputation from bad defaults, not from the idea itself. Done with a little care, you can cut a file to a fifth of its size and nobody looking at it at normal size will spot the difference. The trick is knowing which two levers exist and pulling them in the right order.

Lever one: dimensions, the one people forget

File size scales with pixel count, and pixel count grows with the square of the dimensions. A 4000x3000 photo carries twelve million pixels; scaled to 1600x1200, it carries under two million. That is an 84 percent reduction before any quality setting enters the picture.

So the first question is not what quality to use, it is where the image will be seen. A photo going into a chat message, a blog post, or a ticket will render at most around 1600 pixels wide, usually less. Sending more pixels than the screen will show is pure waste. Resize to roughly the display size, or a bit above it for zooming, and half the problem is gone. The resizer tool does this in the browser.

Lever two: encoding quality

Lossy formats like JPEG and WebP shrink files by discarding detail the eye is bad at noticing, and the quality setting decides how aggressive that discarding gets. The relationship is not linear. Between quality 100 and 80 the file often halves while the image looks identical at normal viewing size. Between 60 and 40 the savings get smaller and the damage gets visible: blocky patches in smooth gradients, halos around sharp edges.

That is why 80 is the number you will hear from people who do this a lot. It sits right where the curve bends, most of the savings, none of the visible cost. Drop lower only when the target is brutal, like an email system with a hard cap, and check the result at full size before sending.

Pick the right format before you squeeze

Compression settings cannot rescue the wrong format. Photos, with their soft gradients and noise, are what JPEG was built for. Screenshots and interface captures are the opposite case: hard edges, flat color, and text, which JPEG smears and PNG stores exactly. WebP handles both reasonably and usually lands 25 to 35 percent smaller than the JPEG equivalent, at the cost of a few very old viewers not opening it.

The format comparison guide goes deep on this. The short table: photo going to the web, JPEG or WebP at around quality 80. Screenshot with text, PNG, and shrink it by resizing rather than by lossy quality. Graphic with transparency, PNG or WebP, since JPEG has no transparency at all. Converting between them takes one step in the converter.

Compressing in the browser, step by step

The compressor on this site runs entirely client side, on a canvas in your tab, so the original never leaves your machine. Drop or paste an image, pick the quality level, and compare the before and after sizes it reports. If the result looks right, download it, or click for a shareable link, which uploads only the compressed version you approved.

A reasonable workflow for a heavy photo: resize to the target width first, then compress at around 80, then look at the result at the size people will actually see it. If you cannot tell the difference, you are done. If you can, step the quality up ten points and look again.

What artifacts look like, so you can check for them

Knowing what to look for turns quality checking from vibes into a thirty-second inspection. JPEG damage shows up in three places first. Smooth gradients, like sky or studio backgrounds, develop banding, visible steps where the transition should be seamless. Sharp edges grow faint ghost outlines, called ringing, which is why compressed text looks like it has a shadow. And flat areas break into faint 8-pixel squares, the blocking that gives over-compressed memes their look.

Check those three spots at 100 percent zoom on the compressed copy. If the sky is smooth, the text edges are clean, and flat colors stay flat, ship it. Nobody inspects an image in a chat thread harder than that.

Transparency and the odd formats

JPEG has no transparency, full stop. Compress a logo with a transparent background to JPEG and the transparency becomes a white or black slab. Keep transparency in PNG or WebP. Animated GIFs are their own mess, ancient compression and huge files, and converting them to video or animated WebP saves far more than any quality slider can. If you just need one frame of a GIF, screenshot it and share the still.

When not to compress

Keep originals for anything you might edit later. Every lossy save is a small haircut, and edits on top of edits compound it, which is where the muddy, over-processed look comes from. Archive the camera original, compress copies for sharing.

Skip recompression for files that are already small. Chat apps and CDNs often recompress on their side anyway, and a 150 KB image does not need your help. The real targets are the multi-megabyte phone photos and full-resolution screenshots, the kind that hit the caps listed in the attachment limits guide.

Metadata: free savings, and a privacy bonus

Camera photos carry an EXIF block, capture time, device model, sometimes GPS coordinates, that adds weight and says more about you than you might want a stranger to know. Stripping it shaves a little off the file and closes a real privacy hole, which the EXIF guide covers in full. Screenshots barely carry metadata, so this step matters for photos specifically. Most compressors, including canvas-based ones like the tool here, drop EXIF as a side effect of re-encoding, so you often get this for free without thinking about it.

The numbers you can expect

Typical results, not guarantees: a 4 MB phone photo resized to 1600 pixels and saved at JPEG quality 80 usually lands between 300 and 600 KB. A 1.5 MB full-screen PNG screenshot cropped to the relevant region often drops under 200 KB with no quality loss at all, which is a reminder that cropping is itself a compression strategy. And if the destination is a link rather than an attachment, size stops mattering to the recipient entirely, because a short URL weighs nothing in the message.