An avatar must be 400x400, an article cover must be 1200 wide, an email attachment is capped at 2 MB, and the phone photo is 4032x3024. Resizing is the most common image job there is, yet many people end up with a squashed picture, a blurry one, or a file that did not get smaller. This article uses concrete numbers to show how to work out the target size, avoid distortion and softness, and do it locally in your browser so the photo never goes to anyone else.
Three ideas first: pixels, ratio, resampling
Pixel dimensions are the width and height of the image grid. 4032x3024 means 4032 dots across and 3024 down, about 12.19 million pixels in total. Resizing recalculates that grid onto a different one, a process called resampling. Aspect ratio is width divided by height: 4032/3024 is about 1.333, or 4:3. As long as the new size has the same ratio as the original, nothing is distorted.
Entering just one number is the safest approach. Given a target width, height = target width x original height / original width, rounded to a whole pixel. For example:
| Original | Target | Calculation | Result |
|---|---|---|---|
| 4032x3024 | Width 1600 | 1600 x 3024 / 4032 | 1600x1200 |
| 3000x2000 | Width 1080 | 1080 x 2000 / 3000 | 1080x720 |
| 1920x1080 | Width 1000 | 1000 x 1080 / 1920 = 562.5 | 1000x563 (rounded) |
| 3024x4032 (portrait) | Height 1280 | 1280 x 3024 / 4032 | 960x1280 |
Resizing locally with ToolGarden: the steps
- Open Image Resize and choose or drop an image. Inputs include JPG, PNG, WebP, GIF, BMP, SVG and AVIF, with a limit of 50 MB and about 40 million pixels per file; beyond that the page tells you.
- The page shows the original size. Keep Keep ratio ticked and change only the width or the height; the other is calculated from the original ratio.
- Pick an output format: JPG, PNG or WebP. The default follows the source: JPG gives JPG, WebP gives WebP, and other inputs such as GIF, BMP or SVG default to PNG. JPG and WebP have a quality slider, defaulting to 92 percent; PNG is lossless and has no quality setting.
- Generate, then read the output preview along with output size, file size and time taken.
- Check that lines and text edges are not soft, then download. Zoom into the preview for a closer look.
On privacy, the page says processing is local and data is cleared when you close it. To check for yourself, open the Network panel in your developer tools, process an image, and look for any request carrying the picture.
Resize versus crop: when you need both
Resizing keeps all of the picture and changes the pixel count; cropping discards what falls outside the frame and keeps pixel density. When the target ratio differs from the original, resizing alone must either stretch or leave empty space, so crop first and then resize.
Example: a 4000x3000 (4:3) photo needs to become a 1200x630 share cover (about 1.905:1). Forcing 1200x630 would squash it. Instead, crop an area with the target ratio: width 4000, height 4000/1.905, about 2100, a 4000x2100 strip. Then resize to 1200x630. Check: 4000/2100 and 1200/630 are both about 1.905, so no distortion. Image Crop does both in one pass because it offers a crop frame and an output size in the same workflow.
| Need | Approach | Distortion? |
|---|---|---|
| Same composition, just smaller | Resize with ratio kept | No |
| Different target ratio, must fill the frame | Crop to the target ratio, then resize | No, but part of the picture is lost |
| Different target ratio, must show everything | Resize, then pad the canvas (needs an editor to add background) | No |
| Untick Keep ratio and force both numbers | Stretch | Yes: people and circles deform, usually not recommended |
Why shrinking can alias, and how the tool handles it
Shrinking is not simply throwing pixels away. If 4000 pixels are reduced to 400 in one jump by sampling only the nearest few source pixels, fine lines and textures show jagged edges or moire. The usual remedy is to downscale in steps of at most half, so each new pixel combines more source pixels. In the current implementation, scaling uses high-quality smoothing, and when the reduction is more than 2x it halves repeatedly and only the last step lands on the target size; SVG sources use a dedicated resizing library to stay crisp. You do not do anything manually, but it explains why one pass from the original beats repeated shrinking: always start from the original and export once, rather than re-shrinking a previously exported small copy.
Why enlarging looks soft
Enlarging has to invent pixels, and algorithms can only interpolate. Taking 800x600 to 1600x1200 makes three quarters of the new pixels weighted averages of their neighbours; no detail that was never captured appears, and edges simply soften. If you need a bigger picture, find a higher-resolution original. If you only have the small one, Image Upscale or Image Enhance can add texture with algorithms or AI models, but that texture is an estimate, not real information, and must not be used as evidence.
How many pixels should the target be?
| Use | Rule of thumb | Example |
|---|---|---|
| In-article web image | 1x to 2x the container width (2x for high-density screens) | An 800 px container: export at 800 or 1600 wide |
| Social share cover | Follow the platform ratio and size; crop then resize | Share images around 1.91:1 are often 1200x630 |
| Avatar | Square, crop to 1:1 first | 400x400 |
| Email attachment size | Within 1600 wide is usually enough to read | 4032x3024 down to 1600x1200 |
| pixels = inches x dpi | 6x4 inches at 300 dpi needs 1800x1200 |
Print deserves a note: pixels have no centimetres of their own, physical size depends on dpi. The same 1800x1200 image is 6x4 inches at 300 dpi and 12x8 inches at 150 dpi, but looks correspondingly coarser. For print, decide the size and dpi first and then compute the pixel count; do not just change the width in the tool and assume you changed the centimetres.
A worked example: shrinking a phone photo for an email attachment
A 4032x3024 phone photo of, say, about 4 MB must be sent with each file under 1 MB. Step one: set width to 1600 with the ratio kept, giving 1600x1200. Pixels fall from about 12.19 million to 1.92 million, roughly 16 percent of the original. Step two: output JPG at the default quality or a little lower. Step three: read the file size the tool reports; if it is still too large, tune it with Image Compressor, or switch the format to WebP after checking the recipient can open it. Note that file size scales roughly, not strictly linearly, with pixel count, and also depends on image complexity and quality, so trust the figure the tool shows rather than estimating.
Format, quality and metadata
| Output format | Traits | Watch out for when resizing |
|---|---|---|
| JPG | Lossy, small for photos, no transparency | Transparent areas turn white; repeated saves accumulate loss |
| PNG | Lossless, supports transparency, large for photos | No quality slider; a shrunken photo can still be big |
| WebP | Lossy or lossless, supports transparency, web-friendly | A few old tools and OS previews do not recognise it; test before publishing |
On metadata, output re-encoded through a canvas normally no longer carries the original EXIF, which helps privacy but means capture time and copyright fields are dropped. To know whether a file has location data, inspect the final export with EXIF Viewer & Cleaner rather than assuming. Phone photos sometimes keep rotation only in metadata; if the result is sideways after resizing, fix it with Image Rotate.
Common problems, diagnosed
| Symptom | Likely cause | Fix |
|---|---|---|
| People look stretched or squashed | Keep ratio was off, or both numbers were typed with a mismatched ratio | Turn Keep ratio on and enter one dimension; crop first when a fixed ratio is needed |
| Text looks soft after shrinking | Too large a reduction, or shrinking an already-shrunk copy | Resize once from the original; use PNG for text-heavy screenshots |
| File got bigger after shrinking | A photo exported as PNG, or the source was an already heavily compressed JPG | Output JPG or WebP, or lower the quality |
| Transparent background turned white | Output was JPG | Use PNG or WebP |
| Too large or cannot decode | Over 50 MB / about 40 million pixels, or a damaged or unsupported file | Shrink elsewhere first, or change format |
| Wrong orientation after resize | Orientation lives in metadata and some software ignores it | Fix with Image Rotate before exporting |
When not to use this approach
- You need a lossless edit that keeps all metadata. Canvas re-encoding always recompresses and drops metadata; keep the original file.
- Very large images such as hundreds-of-megapixel scans or panoramas. Browser memory and canvas limits become the bottleneck; use desktop software or the command line.
- Colour-critical print work. Colour profiles are not guaranteed to survive; use professional software.
- Hundreds or thousands of files. Browsers are a poor fit for long batches; a command-line tool is better.
- You want to enlarge a small image and keep it sharp. Resizing cannot add detail; get a higher-resolution original.
A practical routine to finish: confirm the purpose, compute the target pixels, crop first if the ratio differs, resize once from the original, pick a suitable format and quality, then check the exported file for sharpness, size and metadata. Following that order avoids most distorted, soft or still-too-big results.