Large images are one of the most common reasons a website loads slowly. The good news: you can usually cut file size dramatically — often by more than half — with no difference anyone will notice at normal viewing size, if you compress the right way.
"Without losing quality" really means "without losing visible quality." Almost every useful size reduction throws some information away; the skill is choosing what to throw away. That comes down to four decisions, in this order: the format, the dimensions, the quality setting, and how you check the result.
Lossy vs. lossless, in one paragraph
Lossless compression shrinks a file without changing a single pixel — decompress it and you get the original back exactly. Lossy compression discards detail the eye is unlikely to miss, which is why it can make files far smaller. As MDN's image format guide puts it, photographs "can usually tolerate lossy compression, because the discarded detail is harder to see," while screenshots, diagrams, logos, and line art are better served by lossless encoding, because blurring and colored fringes around sharp edges are very visible.
JPEG vs. PNG — pick the right format first
Compression settings only get you so far if you're using the wrong format to begin with. JPEG uses "lossy" compression and is built for photographs — continuous tones, lots of colors, no sharp edges. PNG uses "lossless" compression and is built for graphics — logos, screenshots, text, anything with flat colors or transparency.
Using PNG for a photo produces a needlessly huge file. Using JPEG for a logo introduces blurry artifacts around sharp edges. Match the format to the content first, then compress.
Where WebP and AVIF fit
Both newer formats support lossy and lossless compression as well as transparency, so a single format can cover photos and graphics. MDN recommends preferring WebP or AVIF for raster images because they "generally provide better compression than PNG, JPEG, and GIF," and web.dev gives the same advice. WebP works in all current major browsers. AVIF support arrived later — Chrome 85, Firefox 93, and Safari 16.1, according to MDN's compatibility table.
If you need to support older browsers or apps, serve the modern format with a fallback using the <picture> element:
<picture>
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" alt="Product on a desk" width="800" height="600">
</picture>Our Image Converter can export PNG, JPG, or WebP, so you can produce both files from the same source.
Quality settings: where the real savings happen
JPEG and WebP encoders take a quality setting, and it's the biggest single lever you have. One caution first: the numbers aren't standardized. "80" in one app isn't guaranteed to match "80" in another, because each encoder maps the setting to its own internal compression parameters. In the browser, the canvas encoder takes a quality value between 0 and 1 for JPEG and WebP; when a tool shows 80%, it's typically passing 0.8.
In practice, the setting behaves the same way across encoders. At high settings you're mostly paying file size for quality gains nobody will notice on screen. Through the middle of the range, file size drops quickly while visible changes stay small. At low settings, blocky artifacts and smeared fine detail appear — first around sharp edges, text, and smooth gradients like skies.
A practical workflow: start at 80% quality, zoom in on any detail-heavy areas (faces, text, fine textures), and only increase quality if you can actually see degradation there. If you're chasing a hard size limit, lower it in small steps and stop at the first setting that fits.
Resize before you compress
This is the step people skip most often. If your image is 4000×3000 pixels but only displays at 800×600 on your site, you're not loading 5 times more data than needed — you're loading 25 times more pixels. Width and height both shrink by 5, so the pixel count drops from 12,000,000 to 480,000. As web.dev notes, the larger the number of pixels, the larger the file size of a raster image. Resizing to the actual display dimensions first, then compressing, gives a much bigger size reduction than compression alone.
"Display dimensions" needs one adjustment for high-density screens. A slot that's 800 CSS pixels wide on a phone or laptop with a 2× display shows 1,600 physical pixels, so an 800px-wide image can look soft there. A common approach is to export a 1× and a 2× version and let the browser choose with srcset — MDN's responsive images guide walks through the syntax.
A worked example: a phone photo at 4032×3024 (about 12.2 megapixels) is going into a blog column 800px wide. Resizing to 1600×1200 for 2× screens leaves 1.92 megapixels — about 6.4 times fewer pixels — before you touch the quality slider at all. Then compress at around 80% and compare.
Mistakes that quietly cost quality
- Re-compressing a compressed file. Every lossy save throws away more detail. Keep the original and always export from it, rather than editing and re-saving the same JPEG.
- Losing transparency by accident. JPEG has no transparency channel, so transparent areas are filled with a solid color. Our Image Compressor always outputs JPEG, so for a logo on a transparent background, use the Image Resizer (which keeps PNGs as PNG) or convert to WebP instead.
- Saving screenshots of text as JPEG. Text edges are exactly where JPEG artifacts show most. Use PNG or lossless WebP.
- Upscaling to "fix" a small image. Enlarging interpolates new pixels; it can't add real detail, and the result is a bigger file that looks soft.
- Judging at the wrong size. At 400% zoom, every image looks damaged. Check at the size and on the kind of screen your audience actually uses.
One side effect worth knowing: because browser-based tools redraw the image on a canvas and export the pixels, the new file generally doesn't carry over the original's camera metadata, such as the GPS location a phone may have recorded. That usually makes the file a little smaller, too.
A simple three-step process
- Resize the image to the largest size it will actually be displayed at (2× that for high-density screens, if it matters)
- Compress at 75–85% quality (JPEG or WebP), or keep graphics lossless as PNG or lossless WebP
- Compare the before/after at real display size, not zoomed in at 100%
Resize and compress an image right in your browser — nothing is uploaded anywhere.
Resize an image → Compress an image →For icons and small UI elements, it's also worth checking whether embedding the image as Base64 saves you an HTTP request entirely — our Image to Base64 tool handles that conversion in one step. Just keep it to genuinely small files: Base64 encodes every 3 bytes as 4 characters, so the embedded version is about a third larger than the original image.
Frequently asked questions
Does compressing an image reduce its resolution?
No. Compression changes how the pixel data is encoded, not how many pixels there are, so a 1600×1200 photo compressed at 70% quality is still 1600×1200. Resizing is the step that changes an image's dimensions.
Is WebP better than JPEG?
For most web images, yes. WebP generally compresses better than JPEG and also supports transparency, and it works in all current major browsers. Some older apps and upload forms still accept only JPEG or PNG, so keep a JPEG version when you need maximum compatibility.
Why did my PNG get a white background after compressing it?
JPEG has no transparency channel, so transparent areas are filled with a solid color when an image is saved as JPEG. To keep transparency, save the image as PNG or WebP instead.