“Resize without losing quality” is a common wish — and the honest answer depends on which way you’re going. Shrinking is nearly lossless; enlarging fights physics. Here’s how to get the best result either way.
We measured this ourselves. Here is the part that surprises people. Going from 1200 px to 800 px wide removes 56% of the pixels, yet our files only shrank 15% to 50%. The photo roughly halved (1.88 MB to 967.2 KB), while the screenshot gave up just 15% — its cost is in the sharp edges, and shrinking keeps every one of them. see the full measurements
Shrinking (downscaling): basically free
Making an image smaller in pixels is clean. The software averages neighboring pixels, so the result stays sharp — this is the safe, everyday case. A 4000-pixel phone photo scaled to the 1200 pixels your page actually shows looks great and loads faster.
Free in quality, but not proportional in bytes — and the gap is large. Going from 1200 px to 800 px wide removes 56% of the pixels, yet our four test images fell by wildly different amounts: the photograph 1.88 MB → 967.2 KB (-50%), the flat illustration 34.7 KB → 28.8 KB (-17%), the transparent logo 28.8 KB → 17.2 KB (-40%), and the UI screenshot only 18.0 KB → 15.3 KB (-15%). A screenshot spends its bytes on sharp edges, and shrinking keeps every edge.
Downscaling is close to free in bytes as well as in quality, and the two are easy to confuse. Our test photo through the image resizer went 1.88 MB → 967.2 KB (-50%):
| Test image | Input | Output | Change |
|---|---|---|---|
| Photo | 1.88 MB | 967.2 KB | -50% |
| Screenshot | 18.0 KB | 15.3 KB | -15% |
| Illustration | 34.7 KB | 28.8 KB | -17% |
| Logo with alpha | 28.8 KB | 17.2 KB | -40% |
Those numbers are pixels being discarded, not quality being traded — every output pixel is still an average of real input pixels. Compare that with the compressor on the same photo, which kept every pixel and reached 178.7 KB (-46%) by throwing away detail within them. Same direction of travel, completely different mechanism, and only one of them is reversible by re-exporting from the original.
Enlarging (upscaling): the hard part
Making an image bigger than its original can’t invent detail that was never captured. Interpolation stretches existing pixels, so edges get soft or blocky. Ways to cope:
- Don’t upscale if you can avoid it — start from a higher-resolution original.
- Logos and icons? Use a vector instead — trace a PNG to SVG and it scales to any size perfectly.
- For photos, a dedicated AI upscaler does better than plain resizing (but is heavier).
Get the sharpest resize
- Resize to the exact dimensions you’ll display — no bigger.
- Lock the aspect ratio so the image isn’t stretched.
- Resize first, then compress, if you also need a smaller file.
Do it in your browser — nothing uploaded
- Resize an image — set width/height with an aspect-ratio lock; runs locally.
- Compress an image — cut the file size after resizing. See also how to reduce image file size.
Bottom line: downscaling keeps quality; upscaling can’t restore it. Start big, shrink to fit, and reach for a vector when a logo needs to grow.
Vector vs raster: the real dividing line
Whether resizing hurts depends on what kind of image you have.
- Raster images (PNG, JPG, WebP) are a fixed grid of pixels. Enlarge them and there is simply no extra detail to show, so they blur.
- Vector images (SVG) are stored as math — points, lines and curves — so they redraw perfectly at any size. Logos, icons and simple illustrations belong here; photos cannot be vectors.
If a logo keeps needing to grow, stop resizing the PNG and trace it to SVG once.
That is also the practical reason to check what kind of image you have before resizing to save space. Halving the width of a photograph got us -50%; doing the same to a screenshot got -15%. If the goal is a smaller file rather than smaller dimensions, compression is usually the better lever.
Why enlarging blurs: resampling
Every resize resamples the pixel grid — it recomputes each new pixel from the old ones by interpolation:
- Nearest-neighbor — fastest, blocky; only good for pixel art.
- Bilinear / bicubic — smooth blends; bicubic is the common default.
- Lanczos — sharpest for downscaling detailed photos.
Downscaling has real pixels to average from, so it stays crisp. Upscaling has to invent the pixels in between, and invented detail always looks soft. That is the whole reason “enhance” only works in movies.
Crop first, then resize
If you only need part of a picture, crop to it before downscaling. Cropping first keeps the maximum number of real pixels in the area that matters, instead of throwing resolution away on parts you’ll discard.
Export format and the quality trade-off
| Format | Best for | Note |
|---|---|---|
| JPG | Photos | Lossy; 80–85% quality is the sweet spot |
| PNG | Flat graphics, transparency | Lossless, larger files |
| WebP | Both | Smaller than JPG/PNG, widely supported |
| AVIF | Both | Smallest, newer support |
| SVG | Logos, icons | Vector, infinitely scalable |
Re-saving a JPG again and again compounds compression loss (“generation loss”). Resize once, then export once at your target quality. Not sure which to pick? See the best image format for the web.
Which is also the answer to “what should I export as”. Resizing first and compressing second is strictly better than the reverse: at 967.2 KB the resizer has already removed the pixels the compressor would have spent bits on. Doing it the other way round pays to encode detail that the resize then averages away.
FAQ
Does resizing always reduce quality?
No. Downscaling keeps quality — you’re discarding pixels you didn’t need. Upscaling reduces it, because the extra pixels are guessed.
Which format keeps the most quality?
For photos, a high-quality WebP or AVIF; for flat graphics or transparency, PNG; for anything that must scale, a vector SVG.