Resize images online to exact pixels, free

Compression is the right tool when the dimensions are already correct and you only want a smaller file. Resizing is the right tool when the picture is physically bigger than the space it lives in. Most oversized web images need resizing first and compression second, which is why the order discussion later matters.

Aspect ratio, and why locking it stops the stretch

Aspect ratio is the relationship between width and height, written as two numbers like 4:3, 16:9, or 1:1. A 4000x3000 photo has a 4:3 ratio. Resize it to 1200x900 and the ratio holds, so the image looks identical, just smaller.

Resize it to 1200x600 instead and you force a 2:1 ratio onto a 4:3 picture, squashing everything in the frame vertically. Faces go wide, circles become ovals, text leans. That distortion is the single most common resize mistake.

Max-bounds mode guards against this by preserving the ratio automatically. You give a limit and the image scales down until its longest side fits, keeping both axes in proportion. You can also supply a single dimension and leave the other blank: give a width of 1200 and the height computes itself from the original ratio. This is the safest way to hit a target width without doing arithmetic.

Exact-size mode is the deliberate exception. It forces the precise width and height you type, ratio be damned, because some targets demand an exact pixel count. A 1080x1080 Instagram square or a 1200x630 Open Graph card has to be those numbers.

The honest tradeoff: if your source is not already at that ratio, exact mode stretches it. The fix is to crop the picture to the correct ratio first, then resize. Crop changes the framing, resize changes the size, and doing them in that order keeps the subject proportions true.

Scaling down looks good, scaling up does not

When the tool resizes, it redraws your image onto a Canvas at the new dimensions with high-quality smoothing turned on. For downscaling, that smoothing is a real advantage. Going from 4000 pixels to 1200 pixels, the engine averages groups of source pixels into each destination pixel using bilinear sampling, which keeps edges clean and avoids the jagged stair-stepping that cruder methods produce. Moderate reductions, say halving or quartering the dimensions, come out crisp.

Very aggressive reductions soften more. Shrinking 4000 pixels straight to 200 pixels throws away so much information that fine texture flattens. If sharpness at small sizes matters, resize closer to the target rather than making one giant leap, and accept that thumbnails are always a little softer than their source.

Upscaling is the harder limit. When you ask for dimensions larger than the original, the tool has to invent pixels that were never captured. It can stretch and blend what exists, but it cannot add detail that the camera did not record.

A 600 pixel image pushed to 1800 pixels looks soft and slightly mushy, with blurred edges where sharp ones used to be. No browser or desktop tool conjures genuine new detail from nothing. The practical rule: resize down freely, resize up only when you have no better source and accept the softness.

Pixel sizes that fit common targets

Picking a target width is easier with reference numbers. For blog and article body images, the content column on most sites runs between 1200 and 1600 pixels wide, so resizing to a 1600 pixel maximum covers nearly every layout while keeping files reasonable. A full-width hero or banner that spans an entire large monitor wants around 1920 pixels. Product thumbnails in a grid sit comfortably between 400 and 800 pixels, since the grid shrinks them anyway and a smaller source loads faster.

Social platforms publish exact targets and reward matching them. An Instagram square post is 1080x1080, a vertical story or reel is 1080x1920, and the Open Graph image shown when a link is shared on most networks is 1200x630. A YouTube thumbnail is 1280x720.

Avatars and profile photos are usually small squares, often 400x400 or smaller. These are good candidates for exact-size mode after a crop to 1:1.

Two habits keep these from biting you. First, design for the highest-density screens your audience uses: many phones and laptops render at two or three device pixels per CSS pixel, so an image displayed at 600 CSS pixels can look sharper sourced at 1200.

Second, do not exceed the display slot by a wide margin. A 4000 pixel file in a 1200 pixel slot is pure waste. Match the source to where it will be shown, with a modest allowance for dense screens.

Print versus screen, and the DPI confusion

DPI (dots per inch) and PPI (pixels per inch) describe how many pixels fall into one inch of physical output. A common myth says screen images must be 72 ppi and print must be 300 ppi, and that setting 72 ppi makes web files smaller. That is wrong on the web side.

A screen does not read the ppi tag. It cares only about pixel dimensions, so a 1200x800 image is 1200x800 whether its metadata claims 72 or 300 ppi, and the file size barely moves either way. The 72 ppi number is a leftover from old print workflows with no effect on how a browser renders pixels.

Print is where ppi becomes real, because paper has a fixed physical size and the printer needs enough pixels to fill it cleanly. The math is plain: pixels needed equals physical inches times the target ppi. A photo printed 4 inches wide at 300 ppi needs 1200 pixels (4 times 300), and an 8x10 print at 300 ppi needs 2400x3000 pixels. Drop below roughly 300 ppi at the intended physical size and the print can look soft or show visible pixel structure up close.

So the split is this. For screen, ignore ppi and resize by pixel dimensions to fit the slot. For print, decide the physical size, multiply by 300, and resize so the pixel dimensions meet that figure. If a print needs 2400x3000 and your source is only 1500x1875, no resize will rescue it: you need a larger original, because scaling up cannot add the detail.

Resize first, then compress: why the order matters

The two operations chain best in a specific sequence. Resize first to cut the bulk of the pixels, then compress the smaller result to shave the remaining data. Running it the other way around wastes effort. If you compress a 4000 pixel file down to a tidy size and then resize it to 1200 pixels, the resize throws away most of the pixels you just spent care compressing, and you usually have to compress again anyway.

Doing resize first means the compressor works on far fewer pixels from the start, so it reaches a small file with less quality loss. A 4000 pixel photo resized to 1200 pixels has already shed about 90 percent of its data through the dimension change alone, often turning a 5 MB original into a few hundred KB before compression even runs. Compressing that lighter file then trims it further with room to keep quality high.

In practice the flow is two tools used in order. Use this resizer to set the pixel dimensions, download the result, then compress it after resizing if you want lighter JPEG output, hit an exact KB target if you have a hard ceiling, or convert to WebP if a smaller format suits the destination. Each tool runs on its own, so you move through the steps deliberately and check the result at each stage.

Standardizing a whole gallery to one width

A catalog or photo gallery looks uniform only when every image shares the same dimensions, and that is tedious to do by hand. The batch flow handles it. Drop up to 100 files, each up to 50 MB, set one width, and every image comes out at that width. Because all of it runs in your browser with no upload, even a large product library stays on your machine and processes without waiting on a server queue.

Max-bounds mode is the safe default for a mixed batch. Set the cap and any image already under it passes through untouched while the oversized ones scale down, all keeping their aspect ratios. That avoids stretching the odd portrait shot that snuck into a set of landscapes. When the catalog needs identical pixel dimensions for a rigid grid, switch to exact-size mode, but crop the sources to a shared ratio first so nothing distorts.

A consistent gallery pays off twice. Visually, the grid lines up and looks deliberate instead of ragged. Technically, images sized to their display slot load faster, which keeps pages quick on phones and slow connections. Pick a target width, run the batch once, then pass the output through a compressor if you want the files lighter still.