Image Resizer
Exact dimensions, percentage or a longest-edge cap, with the aspect ratio held.
Drop an image to resize
Then type the pixel dimensions you need. The ratio holds until you turn the lock off, and the original file on disk is never touched.
Choose image JPG · PNG · WEBP · AVIF · GIF (first frame) · SVGBefore & after
Drag the handle · arrow keys nudge itThe frame keeps the original's proportions. With the ratio locked the two halves sit on exactly the same pixels; turn the lock off and the right half shows the shape you asked for instead.
- Original pixels
- —
- Output pixels
- —
- Scale
- —
- Original file
- —
- New file
- —
- Change
- —
Output size
Whole pixels only, so awkward ratios drift a fraction: 33% of 1023 px is written as 338, not 337.59.
The long side lands on this number and the short side follows the ratio — handy when a CMS asks for "no wider than 1600" and you'd rather not do the division.
Halving the width cuts the pixel count to a quarter, which is why the byte size falls faster than the percentages suggest.
Format & quality
Size and quality are different dials. Leaving the pixels alone and dropping quality to 82% still halves most photographs; below 60% the blocking starts showing in skies and skin.
PNG is lossless, so the slider has nothing to trade and stays disabled. Its file size is decided by the pixel count you typed above.
This image has transparent pixels and JPEG has no alpha channel, so they'll be flattened onto white. The Image Converter can put a colour of your choosing behind them instead.
Enlarging is a guess. Going from 1,200 px to 2,400 px leaves the encoder three unknown pixels for every one it has, and it fills them by averaging the neighbours. You get a bigger file and a softer picture, never more detail.
A resampler averages, and that is all it can do
Reducing an image is not a matter of deleting pixels. Deleting four out of every five samples leaves the surviving one to stand for the whole block, which turns fine texture into a scatter of speckles and hard edges into a staircase. What a resampler does instead is average each block of source pixels into the single pixel that replaces it, so every sample in the neighbourhood contributes something to the result:
2400 × 1800 reduced to 600 × 450
4 source pixels across -> 1 destination pixel
4 source pixels down -> 1 destination pixel
16 source samples are averaged into each output sample
16:1 — the kind of reduction a phone photo takes
when it is being made into a thumbnail
That is why a heavy reduction looks soft rather than broken: the arithmetic is right, and what has been removed is real detail. An averaging filter is the simplest kind and is what a browser gives a canvas by default. Better filters reach further afield and weight the nearer samples more heavily, which preserves edges at the cost of a little ringing near them. The difference between the two is visible on fine text and barely visible on a photograph.
DPI is not a property of the picture. A pixel has no size until something decides how large to draw it, and a number in the file header saying 300 DPI is a suggestion for software that lays images out on paper. Changing that number changes no pixels at all: it is an instruction to a printer, not data. The number that decides what a file is worth is the one in the width and height fields, and where the picture is going, the layout decides that rather than the file.
Why the two fields are linked
Width and height are held together by default because changing one on its own changes the shape of the picture. A 1200 × 800 photograph forced into a 1200 × 1200 box is stretched vertically, and faces come out subtly wrong in a way that is easy to feel and hard to name. Unlink the fields when the distortion is the point — a deliberate squeeze, an aspect correction on a file that was authored wrong — and leave them linked for everything else.
The longest-edge cap is the ratio-proof way to ask for a size. Rather than naming two dimensions and hoping every source has the same proportions, it says no side is longer than this and lets the other follow, which is what a mixed set of photographs actually needs. It is also the right setting for a batch of files whose shapes differ, because nothing gets stretched to fit a box it was never in.
Neither field crops. A resize changes how many pixels there are and keeps the frame exactly as it was, so a 16:9 photograph resized to a 1:1 box comes out distorted rather than cropped, and a square thumbnail out of a wide photo is a crop that happens somewhere else. Where the picture has to fit a fixed frame — a share image, a profile slot — the subject has to be found first and trimmed, and what is left is then resized to fit.
Sharpening is a correction, not a step
Downscaling leaves edges slightly dulled, and a light sharpen afterwards restores the impression of crispness that the averaging took away. It is worth doing once, at a radius well under a pixel, and it is worth not doing at all on the images that do not need it. A screenshot or a piece of line art has edges that are already exact, and sharpening them produces a bright halo along every boundary that no amount of zooming will explain.
Photographs take it well, because their edges are gradual and a small amount of edge contrast reads as detail rather than as a line. If the same file is going to be sharpened again by something downstream, skip it here: the effect compounds, and a second pass on an already-sharpened image produces the crunchy look that gives resized photographs a bad name.
Order, and where the file goes next
Resize first, compress second. Compressing and then resizing throws the compression away and adds a generation of loss, because the pixels being resized have already been rounded and the resampler cannot tell that rounding apart from real detail. Resizing first also means the quality setting is applied to the pixels that are actually going to ship, rather than to pixels on their way out.
After that the two neighbours here are worth a look. The Image Compressor takes the file that was just sized and finds the smallest version of it that still holds up, and the Image Converter changes the container when the destination wants a different one — including laying a colour behind the transparent parts, which is what a PNG has to become before it can be saved as a JPEG.
Reference
What size the destination asks for
| Where it is going | Pixels it needs | Format that suits it | Why that number |
|---|---|---|---|
| Email attachment | Up to about 1600 px on the long edge | JPEG | The recipient opens it on a screen that will not show more, and mail clients cap attachments by size. |
| Blog post, inline | 1200–1600 px wide | JPEG or WebP | Sharp on a retina laptop when the article column draws it at 800 CSS px wide. |
| Full-width hero | 1920 px, and 2560 px if it has to be sharp on a 4K display at 100% | JPEG or WebP | Matches the widest box the layout will ever draw it into, so the browser never has to scale it. |
| 2× retina asset | Twice the CSS pixel size the layout asks for | PNG for flat art, WebP or JPEG for photographs | A 400 px slot wants an 800 px file. Past 2× you are paying for pixels nothing on the page displays. |
| Open Graph share image | 1200 × 630 px | JPEG or PNG | The platforms crop to a fixed frame, so the proportions matter as much as the pixel count. |
| Profile picture | About 400 × 400 px, square | JPEG or PNG | Expect the platform to crop it again, so keep the subject near the middle. |
| Favicon | 16, 32 and 48 px | PNG | Browsers choose from the set they are handed, so look at the rest of the set before settling on one size. |
| About 1800 px for a 6-inch-wide print, at 300 PPI | JPEG or PNG | The one case where a big number is genuinely required, because paper has no pixel grid of its own. | |
| Archive copy | Keep the original, resize a copy | The original's format | A resize cannot put back detail it discarded, so the full-size file is the only one worth keeping. |
Read the middle column as a ceiling rather than a target. Each row is the largest the destination will ever draw the picture, and anything past that is bytes the visitor pays for and never sees.
The target is the largest number of pixels the image will ever be drawn at, and nothing above it. That figure comes from the layout rather than the file you happen to have: the widest box the picture sits in, multiplied by the densest screen you support. A 6000 px photograph shown in an 800 px column is not a sharper picture than the same photograph resized to 1600 px. It is the same picture carrying detail no screen in the chain will display, on a page that loads more slowly for it.
Resizing up is the other half of the same mistake. Interpolation estimates each new pixel from the ones around it, so a 1000 px file stretched to 2400 px holds no more information than it started with, only a softer rendering of it. If a destination needs more pixels than the source holds, nothing on this page can conjure them; a higher-resolution original is the only route.
One more step earns its keep. Downscaling averages neighbouring samples and throws the rest away, which leaves edges slightly dulled even when the arithmetic is right. A light sharpen after the resize, applied once, puts the impression of crispness back. Photographs take it well; screenshots and line art usually want none of it, because their edges are already exact.
Questions
Resizing, answered plainly
Can I enlarge a photo without losing quality?
No. Nothing in a 1,200 px file knows what belonged in the 1,201st pixel, and no amount of clever interpolation will find out. A small enlargement — 10 or 20% — is usually invisible at normal viewing size and perfectly safe to ship. Past about double, softness and halo artefacts around hard edges become obvious, and the file grows as if the detail were real.
Why is my PNG larger after being resized down?
Because the source was probably already squeezed by something better than a canvas encoder. PNG is lossless, so a tool like pngquant can throw away colour precision and beat the browser's own encoder comfortably. The Change cell will tell you honestly, in either direction. If it says the output is bigger, keep the file you already have — or switch to WebP, whose lossless mode usually wins on flat graphics.
What happened to the EXIF data, and why did my photo come out the right way up?
The orientation tag is read and applied before anything is drawn, so a phone photo lands the way you saw it on the phone rather than sideways. Turning it into pixels means the tag is no longer needed, and the output carries no metadata at all: no GPS coordinates, no camera body, no shutter speed, no timestamp. For a picture you're about to publish, that is usually the point.
Is there a limit on how big an image I can drop in?
The limit is this machine's memory rather than a policy of mine. A 60-megapixel photo is roughly 240 MB once it has been decoded into raw pixels, and that is the real cost — the compressed file size tells you very little about it. Nothing is queued behind a transfer here, so if it feels slow, that is your own CPU drawing the scaled bitmap. Above 16,384 px on either side, browsers decline to allocate the canvas at all, and the tool will say so rather than fail silently.
What percentage do I want for a retina screen?
A 300 px slot on a 2× display wants a 600 px file, so 50% of a 1,200 px original is the honest answer — and 100% is what you want if you already have the 2× file and the CSS box is half its width. The percentage row is the quickest way to say that. The file you ship should be the size of the largest box it will ever be drawn into, multiplied by the densest screen you support.
Should I resize before or after compressing?
Resize first. Compressing and then resizing throws the compression work away and adds a generation of loss, because the pixels you resized from have already been rounded and the resampler cannot tell that rounding apart from real detail. Resizing first also means the quality slider is being applied to the pixels you are actually going to ship, rather than to pixels that are about to be thrown out. In practice the order matters more than either setting on its own.
Why does my photo look softer after resizing?
Because downscaling discards detail. Each block of source pixels is averaged into one, which leaves edges a little dulled, and the resampler smooths what survives. The effect is slight at half size and worse the harder you squeeze. A light sharpen afterwards, at a fraction of a pixel of radius, restores the impression of crispness. This tool does not sharpen, so that step belongs in a photo editor if the softness bothers you.
Why did my transparent background come out white?
Because JPEG has no alpha channel. Every pixel has to be given some colour, and transparent ones get flattened onto white. Pick PNG or WebP as the output format and the transparency survives the resize. If you want a colour other than white sitting behind the see-through parts, the Image Converter can lay one in before you resize.