Set the width or height you need and download the scaled image. The aspect ratio is locked unless you unlock it, and the result comes back in the format you put in.
Runs in your browser. Nothing is uploaded.
Resampling happens on a canvas: the image is decoded, drawn into a smaller rectangle so the browser interpolates between neighbouring pixels, and encoded again. The important arithmetic is that pixel count grows with the square of the dimensions. Halving the width also halves the height when the ratio is locked, which leaves a quarter of the pixels. That is why reducing dimensions is usually the far bigger lever: a 3840x2160 photograph taken down to 1920x1080 went from 2,057,152 bytes to 683,263, a saving of 66.8 percent, which is more than re-encoding the same file at a lower quality achieves.
Most images on the internet are far larger than the space they are shown in, and every one of those extra pixels is paid for on every load while being invisible. A photograph displayed in an 800 pixel column does not benefit from being 4000 pixels wide. The cost of resizing is that it is one-way: interpolation throws away information, and scaling back up afterwards produces a soft approximation rather than the detail that was there. Resize a copy, and keep the original wherever the image might be re-used at a different size.
Choose an image
The same questions a security review would ask, answered plainly.
Type a width and the height follows, so images do not end up stretched. Unlock it deliberately when you actually want to distort the frame.
A JPEG comes back as a JPEG and a PNG as a PNG, so a photograph does not silently become a much larger lossless file on the way through.
The image is read locally and a new file is written to your downloads. The original on disk is untouched whatever dimensions you try.
Scaling a 3840x2160 JPEG to half its width took 58 milliseconds. Even a 10.9 MB PNG completed in 212, without waiting on a network at either end.
There is no upload step and no server to receive one. The page loads once, then all work on your images happens in local JavaScript.
No daily limits, no per-file ceilings imposed by a server tier, no watermarks, and no account. The practical limit is your own device's memory.
The same target dimensions against two formats, and what each saved.
The standard case: a 4K photograph reduced to something reasonable for a page.
Input
3840x2160 JPEG, 2,057,152 bytes
Output
1920x1080 JPEG, 683,263 bytes, 58 ms
Settings: Aspect ratio locked, width set to 1920
Half the width and half the height is a quarter of the pixels, and the file fell by 66.8 percent. That is a larger saving than re-encoding the original at a lower quality would have produced, and the image still exceeds most display sizes.
The same picture stored without compression, scaled identically.
Input
3840x2160 PNG, 10,887,764 bytes
Output
1920x1080 PNG, 4,858,793 bytes, 212 ms
Settings: Aspect ratio locked, width set to 1920
Still a PNG afterwards, because the source was one. It fell by 55.4 percent and remains far heavier than the JPEG, which is what lossless storage of a photograph costs. Converting it would save considerably more than resizing did.
Real files, real numbers, and the machine they were run on.
| Scenario | Input | Output | Time | Notes |
|---|---|---|---|---|
| 3840x2160 JPEG down to 1920 wide | 2,057,152 bytes | 683,263 bytes | 58 ms | 66.8% smaller, still JPEG |
| 3840x2160 PNG down to 1920 wide | 10,887,764 bytes | 4,858,793 bytes | 212 ms | 55.4% smaller, still PNG |
How this was measured: Measured by driving this page in headless Chrome 152 on an Apple M4 Pro running macOS 15.5, on 2026-09-17. The fixture is handed to the page's own file input, the page's own button is pressed, and the figure recorded is the size of the file the page produces. Timings come from a warm page on a fast machine with no network involved, so treat them as a floor rather than a typical result.
Match the width to the widest the image is ever displayed at, then double it if you are supporting high-density screens. A full-width banner rarely needs more than 2000 pixels, and an image in a content column rarely more than 1600.
Most platforms want a square, so crop to square first and then resize to the dimensions they ask for, commonly 400x400 or 512x512. Resizing a rectangular photograph into a square without cropping stretches faces.
Leave the aspect ratio locked, which is the default, and only change one of the two boxes. The other updates to keep the proportions, so the picture scales rather than distorts.
There is no direct way to target a byte count here. Reduce the dimensions, check the reported size, and adjust. Combining a smaller width with compression gets under a specific limit faster than either alone.
Oversized images are the most common cause of a slow page. Scaling to the display size removes bytes that were never going to be seen, and doing it locally keeps unpublished work off other people's servers.
Job portals, visa applications and marketplace listings often specify exact pixel dimensions. Hitting them precisely is easier here than in an image editor you would otherwise have to open.
Reducing dimensions shrinks a photograph far more than compression does, which is usually the quickest route under an attachment limit when several images are involved.
Dropping full-resolution photographs into a slide deck or report bloats the file for no visible gain, since they are displayed at a fraction of their size anyway.
On a managed laptop or a borrowed machine there may be nothing installed that can resize an image. A browser tab needs no permission and no installation.
Identification documents, medical images and evidence photographs regularly need resizing to fit a form. This page cannot receive them, which removes the question of whether uploading is allowed.
Including the one people most often hope for.
Scaling up interpolates between pixels that already exist, so the result is a larger, softer version of the same information. It will not recover a licence plate or sharpen a distant face.
The discarded pixels are gone. Going back to the original dimensions afterwards produces a blurry approximation, so resize a copy and keep the source when the image may be needed at another size.
Redrawing through a canvas keeps pixels and nothing else, so EXIF including camera settings, capture time and GPS coordinates is dropped. Often welcome before publishing, occasionally a problem.
There is no batch mode and no way to change the framing here. Changing the aspect ratio without cropping first will stretch the picture rather than trim it.
It does not. The picture is decoded, drawn at the new size and encoded again by your own browser, with no request made at any point. If you want to satisfy yourself, put the machine into aeroplane mode after this page has loaded and resize something; it works exactly as before.
Scaling down discards pixels, which is the point, and at normal viewing sizes the result looks the same because there were more pixels than the display could use. Quality loss only becomes visible if you then view the image much larger than its new dimensions.
Whatever you put in. A JPEG returns a JPEG and a PNG returns a PNG, so a photograph does not become a much heavier lossless file on the way through. Formats a browser cannot encode, such as HEIC or GIF, come back as PNG.
Because PNG stores every pixel exactly, which is expensive for photographic content. The measurement above went from 10.9 MB to 4.9 MB purely through resizing; converting the result to JPEG or WebP would take far more off than any further size reduction.
Leave the aspect lock on, which it is by default, and edit only one dimension. The other recalculates automatically. Turning the lock off lets you enter both independently, which stretches the image unless the numbers happen to match the original ratio.
You can enter bigger numbers, and the browser will interpolate to fill them, but no detail is created. The output is a softer version of the same picture at a larger size, and for print or display work the right answer is usually to find a higher resolution original.
Only if your browser can decode HEIC, which Safari on Apple devices can and most others cannot. Where it does work the output is written as PNG, since canvas cannot encode HEIC. Converting to JPEG first is the more reliable route.
Nothing is imposed here. The practical ceiling is memory, because the image is held as raw pixels while it is redrawn: a 3840x2160 photograph is about 33 MB in that form. Browsers also cap canvas dimensions, typically in the tens of thousands of pixels per side.
No, this handles one at a time. That suits fitting a single image to a requirement and is slow for a folder of hundreds, where a desktop tool or a command line utility is the better choice.
Platforms change these regularly, so check the current guidance rather than trusting a number here. As a rule they re-encode whatever you upload, so supplying something close to their stated size avoids a second round of compression on top of yours.
No. A new file is written to your downloads folder and the original stays exactly where it was, at its original dimensions. Nothing here modifies anything in place.
Yes, provided the page has loaded once. All the work is done by the browser's own image handling, so no connection is needed afterwards. Reloading while offline relies on the browser cache.
There is no limit imposed by us, because there is no server tier to enforce one. The real constraint is your device's available memory, since the whole file is held in RAM while it is processed. Very large files are slower on phones than on a laptop.
No. There is no sign-up, no email, and no usage tracking tied to an identity. The tool works the first time you open it.