Why resizing a photo can make the file bigger
It sounds impossible. You take a 190 KB photograph, ask for it at a quarter of the size, and get back two megabytes. The picture is smaller on screen and the file has grown eleven-fold.
The culprit is almost never the resizing. It is the format quietly changing on the way through. A browser resizes by drawing your picture onto a canvas at the new dimensions and asking the canvas to save it — and a canvas holds nothing but pixels. It has no memory of the file it was handed, so unless it is told which format to use, it writes PNG.
PNG sounds like the careful choice. For a photograph it is the wrong one. JPEG gets small by discarding detail your eye barely registers; PNG stores every pixel exactly, which is wonderful for a logo with six flat colours and hopeless for a beach at sunset. Re-saving a photograph as PNG throws away JPEG’s compression and replaces it with a scheme that has almost nothing to work with. Fewer pixels, far more bytes each.
Measured on a 1600×900 photographic JPEG of 192,867 bytes: asked down to 800×450, a quarter of the area, it came back as a 756,083-byte PNG. Asked for a 1080×1080 square, 2,134,993 bytes — eleven times the original.
This page keeps your format. A JPEG comes back a JPEG. Both file sizes are shown side by side for every picture, and if something does grow, the row says so in plain words rather than leaving you to notice later.
Four ways to say what size you want, and when each one fits
Most resizers give you two boxes and leave you to do arithmetic. Two boxes are the right answer surprisingly rarely.
A percentage. The simplest instruction there is: half the size, a quarter of the size. It works on a batch of mixed pictures without you knowing any of their dimensions, and it can never distort or crop anything, because the shape is preserved by definition. This is the default here, and it is what the page has promised in its title for a long time without offering it.
The longest side. The one to reach for when a website, a forum or a submission form says “no larger than 1920 pixels”. It handles landscape and portrait photos in the same batch without you sorting them first: whichever side is longer becomes 1920, and the other follows.
Fit inside a box. You give a maximum width and height, and every picture is made as large as it can be while staying inside. Nothing is cropped, nothing is stretched. This is the safe choice for a mixed batch that must all sit within a limit.
An exact width and height. Necessary when something demands precise dimensions — a banner slot, a print template, a profile picture. This is the only mode where the awkward question arises, and it is the one most tools handle dishonestly.
The awkward question every exact size asks
A 1600×900 photograph is not the same shape as a 1080×1080 square. You cannot have both the whole picture and that exact frame. Something has to give, and there are only three possible answers.
Crop the overflow. The picture fills the frame, undistorted, and whatever hangs over the edges is cut off. For a landscape photo squeezed into a square that is a substantial amount — the tool works it out and tells you before you commit: “about 44% will be cropped away to reach that shape”.
Add space around it. The whole picture survives, sitting inside the frame with empty bands above and below. You choose what fills them: nothing at all, white, or black. If the output is a JPEG, “nothing” cannot be honoured — JPEG has no transparency — so it becomes white rather than the black that unguarded transparency usually turns into.
Stretch it. Every pixel survives and the picture is distorted to fit. Faces get wider, circles become ovals. It is occasionally what you want and usually not, so it is offered last and named for what it does.
These are the same three choices CSS offers as object-fit, for the same reason: the problem is geometry, and geometry has no fourth answer.
One consequence worth stating, because the previous version of this page got it wrong: if you have asked to keep the original shape, this question does not arise, and the choice is not shown. A control that cannot change anything should not be sitting there implying that it can.
Making a picture bigger is not the same as improving it
Nothing can put back detail a camera never recorded. Ask for a 400-pixel image at 4000 pixels and you get a 4000-pixel blur in a much larger file. The pixels are invented by averaging their neighbours; there is no extra information anywhere for the tool to find.
This matters because it is easy to do by accident — a batch of mixed sizes, a target of 1920, and the small ones get quietly inflated. “Never make a picture bigger than it started” is ticked by default here. Anything already smaller than the target is left at its own size, and the row says so rather than handing you a bloated blur without comment. Untick it if you genuinely want the enlargement; it is your call, made knowingly.
Genuine enlargement — the kind that invents plausible detail rather than averaging — needs a trained model and a great deal of computation. It is a different tool and a different technology, and any resizer claiming to do it in your browser in a fraction of a second is not doing it.
Resizing and compressing solve different problems
These get confused constantly, and the confusion wastes a lot of people’s time.
Resizing changes how many pixels there are. Halving the width quarters the pixel count, because area is two-dimensional — a point worth holding on to, since “half the size” sounds like half the file and usually delivers nearer a quarter.
Compressing changes how many bytes each pixel costs. The dimensions stay put and the encoder is told to be less careful.
If your picture is 4000 pixels wide and needs to be 800, that is a resize. If it is already 800 wide and the file is still 900 KB, resizing further will wreck it and you want the Image Compressor instead, or a change of format — a WebP is routinely a third the size of the equivalent JPEG at the same quality, which the Image to WebP Converter handles.
Very often the right answer is both, in that order: resize to the dimensions you actually need, then compress what remains. Serving a 4000-pixel photograph into a 400-pixel slot is the single most common cause of a slow page, and it is what Lighthouse means by “properly size images”.
Questions people ask when resizing pictures
Will resizing make my photo blurry?
Making it smaller, no — you are discarding pixels, and the result is sharp. Making it bigger, yes, unavoidably. That is why the guard against enlarging is on by default.
How do I resize an image to an exact file size, like under 100 KB?
That is a compression target rather than a dimension one, and the Image Compressor searches for it directly. Resizing gets you part of the way — fewer pixels means fewer bytes — but the last stretch is the encoder’s job, not the resizer’s.
Can I resize several pictures at once?
Yes, up to 30, and they all get the same instruction. This is where the percentage and longest-side modes earn their keep: they work sensibly on a batch of mixed dimensions and orientations without you sorting anything first.
Will my transparent PNG stay transparent?
Yes. A PNG stays a PNG with its alpha channel intact, and if a fit adds space around the picture you can leave that space see-through too. Every preview here sits on a chequerboard so you can see the transparency rather than take it on trust — on a white background, a see-through area and a white area look identical.
What happens to an animated GIF?
Only the first frame survives, because no browser can write GIF files — the result is saved as a PNG and the row says so rather than handing you a still picture with a .gif name.
Does resizing remove the EXIF data?
Yes. The picture is redrawn on a canvas, and the canvas returns pixels and nothing else, so the camera model, the date and any GPS coordinates are gone. That is a loss if you are cataloguing photographs and a favour if you are about to post one publicly. If you want to turn a photo without losing any of that, the Image Rotator can rewrite a JPEG’s orientation tag without re-encoding anything.
What size should I make images for my website?
Roughly twice the width of the space they will occupy, so they stay sharp on high-density screens, and no more. A full-width hero on a typical layout wants around 1600–1920 pixels; a thumbnail in a 300-pixel slot wants about 600. Beyond that you are sending bytes nobody can see. For several sizes of the same picture, the responsive images approach lets the browser choose.
Why did my 1600×900 photo become 1000×563 instead of 1000×1000?
Because the shape was kept. 1600×900 is a 16:9 rectangle; forcing it into a square means cropping, padding or distorting. Untick “Keep the original shape” and the tool will ask you which of those you want, and tell you what it costs.
Are my pictures uploaded?
No. They are read from disk into this page, resized here, and handed straight back. Nothing is sent anywhere and nothing is stored.
Where the facts on this page come from
- MDN — HTMLCanvasElement.toBlob(), which defaults to PNG when no type is given — the root of the growing-file problem described at the top — and MDN — drawImage(), the nine-argument form this page uses to crop and scale in one pass.
- MDN — object-fit, the same cover / contain / fill choice expressed in CSS.
- MDN — image file types and formats, on which formats are lossless and which carry transparency.
- PNG Specification (Third Edition), W3C, on PNG’s lossless compression.
- Lighthouse — properly size images and Serve responsive images, Google, on sizing pictures to the space they occupy.
