What this does
An image has a size in pixels, and most of the time it is the wrong one: the photo is 4032 pixels wide and the site it is going to displays 800, or the form wants at most 1200, or the avatar slot wants exactly 512. This tool changes how many pixels an image has. Drop in a JPEG, PNG or WebP, type a width, a height or a percentage, and download the result; the preview and the before-and-after figures update with every change.
The resizing happens on your machine, in your browser, using the same resampler the Squoosh project built, compiled to WebAssembly and downloaded to your device the first time you use the tool. Your image is never uploaded, which is not a policy claim but an architectural one: there is no server that could receive it. The FAQ explains how to verify that in the network panel rather than take our word.
One thing this tool deliberately does not do is change the format. A JPEG goes in and a JPEG comes out. Nor does it crop: every pixel of your picture is still in the result. Both of those are different decisions, and they deserve their own tools rather than a checkbox surprise.
How to use it
- Drop an image onto the tool, or choose one from your files. JPEG, PNG and WebP are detected from the file’s own bytes, so a mislabelled extension does not matter.
- Type a new width or height and press Enter. With “Keep proportions” ticked, which it is by default, the other dimension follows automatically, so the picture keeps its shape.
- If you think in fractions rather than pixels, type a percentage instead, or press one of the common-width buttons; both keep the proportions whatever the tick says, because a preset that stretched your image would be a trap.
- Press download. The file is named after the original and the new size, so photo.jpg comes back as photo-1920x1440.jpg.
Why downscaled photos go muddy, and what this one does differently
Shrinking an image means averaging: each new pixel stands for several old ones. The trap is where the averaging happens. Images are stored with gamma encoding, a curve that spends more of the file’s precision on dark tones because eyes care more about them. Averaging those encoded values feels natural and is quietly wrong: the curve means the sum lands too low, so every place where light and dark pixels meet comes out darker than the scene. Fine detail is exactly where light and dark meet, which is why the effect reads as “smaller version looks muddy” rather than as an obvious bug.
We did not learn this from a textbook but by shipping the bug. The LEGO mosaic builder on this site averages photos down to brick grids, and its first version averaged gamma-encoded values: on our test images, more than a third of the bricks came out measurably darker than the scene they stood for. The fix there is the fix here. This tool converts the image to linear light, where averaging is physically meaningful, resamples, and converts back.
Two more choices matter. The filter is Lanczos, which weighs a wide neighbourhood of source pixels instead of the nearest few, trading a little speed for edges that stay crisp without ringing. And transparency is premultiplied first, so a transparent pixel cannot bleed whatever colour it secretly carries into its visible neighbours, which is where the dark fringes around logo edges come from in careless resizers.
Choosing sizes for the web
The common-width buttons are the sizes that cover most jobs: 1920 pixels fills a full-bleed hero on an ordinary screen, 1280 covers a content column, 800 suits an image inside an article, and 640 is a generous thumbnail. If the image will be shown at a fixed CSS size on high-density screens, double it: an image displayed at 400 points looks sharpest on a modern phone when it is 800 pixels wide.
The honest general rule is to match the largest size at which the image will actually be displayed, and no more. Every pixel beyond that is bytes your visitors download for nothing, and no amount of clever compression recovers what oversizing spends. Resizing is the single biggest saving available for web images, which is also why it is the first thing to try when a file will not fit under an upload limit.
Resizing and file size
Dimensions dominate file size: half the width and half the height is a quarter of the pixels, and usually something like a quarter of the bytes. The before-and-after line under the preview shows the real numbers for your image rather than an estimate, because the result is measured, not predicted.
After the resample, a JPEG or WebP is re-encoded at quality 75 and a PNG is repacked losslessly. If the result needs to weigh even less, or you want to choose the quality yourself, the image compressor on this site does that job properly, including searching for the best quality under an exact byte budget.
Limitations
It is not a cropper. With “Keep proportions” off, a new shape is reached by stretching, never by cutting parts of the picture off. If what you want is a 512 by 512 square from a photo that is not square, you want a crop first, and that tool is on this site’s roadmap.
Animated WebP is not supported. The tool works on still images; an animation will be refused rather than silently flattened to its first frame.
Enlarging cannot add detail. Going bigger interpolates; it does not invent. The tool allows it, says so when you do it, and leaves the judgement to you.
There are ceilings. Each side of the result is capped at 16,384 pixels and the whole at 100 megapixels, which is where browser memory stops being a theoretical limit. Sizes beyond that are refused with a plain sentence rather than a crash.
Large images take real time. The resampler and the encoders run single-threaded on your device, so a 40-megapixel photo can take a few seconds per change. The page stays responsive while it works; the work is real, it is just happening on your hardware rather than someone else’s.