What size should your images actually be?

One mistake accounts for most of it

Someone takes a photo, the camera writes a 6000 by 4000 pixel file, and that file gets uploaded straight into a layout that shows it at 800 pixels wide. The browser dutifully downloads all 24 million pixels, throws away roughly 97 percent of them, and paints the 800-pixel version. Nothing looks better for the trouble. The page just takes four seconds longer to appear.

This is not a subtle optimisation. A 6000-pixel photograph is commonly 8 to 12 megabytes. The same photograph resized to what the layout actually uses is usually under 200 kilobytes. That is not a 10 percent saving, it is a 98 percent one, and it is available before you touch compression at all.

So the first question is never "how do I compress this", it is "how many pixels does this slot actually need". Resize first with the image resizer, then compress the result with the image compressor. Doing it the other way round wastes most of the benefit.

Work out the display width, then double it

Find how wide the image is drawn on the page in CSS pixels. An in-article image in a typical text column is 700 to 800. A card in a three-across grid is often 380. An avatar is 40 or 48. That number, not the size of your monitor, is what you are designing for.

Then double it. Phones and modern laptops pack two or three physical pixels into every CSS pixel, so an image displayed at 800 wide is drawn into an 1600-pixel-wide area on most devices people actually browse on. Ship 800 and it looks softly out of focus on half your traffic.

Do not go past 2x. The jump from 1x to 2x is obvious to anyone. The jump from 2x to 3x is invisible in a normal viewing position on a photograph, and it costs more than twice as many bytes again, because file size scales with area rather than width. Doubling the width quadruples the pixel count.

The one exception is flat graphics with hard edges: logos, charts, screenshots of interfaces. Those show the difference at 3x more readily than a photograph does. If it matters, use a vector format instead and stop thinking about pixel dimensions entirely.

DPI does nothing on a screen

A client asks for images at 300 DPI. Your export dialogue has a DPI field. Somewhere along the line everyone learned that 72 DPI is for web and 300 DPI is for print. On a screen, all of it is noise.

A digital image is a grid of pixels and nothing else. The DPI value is a separate number stored alongside that grid saying how large to print it: 3000 pixels at 300 DPI means a 10 inch print. Change the DPI field without changing the pixel dimensions and the file on disk is byte-for-byte identical apart from that one tag. No browser reads it.

So when someone asks for a bigger image, they mean more pixels. When a printer asks for 300 DPI, they mean enough pixels for the physical size they are printing: multiply the inches by 300 and that is the pixel count you owe them. A 6 by 4 inch print at 300 DPI needs 1800 by 1200 pixels, and where those pixels came from is entirely up to you.

Numbers you can just use

These are export widths, already doubled for high-density screens, so use them as they are rather than doubling again. They assume a photograph. Flat graphics can go smaller because they compress far better.

Two of these are not really your choice. Social share cards are 1200 by 630 because that is what the platforms crop to, and getting it wrong means every face in the picture is cut in half in the feed. Email is capped at around 1200 wide because plenty of clients will not scale an image down gracefully and some still meter the download.

The ratio matters more than the exact width

A grid of cards where one image is 4:3, one is 16:9 and one is square looks broken in a way that is hard to name but instantly visible. Either the cards are different heights, or the layout crops them unpredictably and cuts heads off. This happens more often than an image being 60 pixels too narrow, and it looks far worse.

Pick one ratio per slot and crop everything to it before it goes anywhere near the layout. The image cropper does this with a fixed ratio, and the aspect ratio calculator works out the matching height when you know the width you want. For profile pictures that will be masked into a circle, the circle crop tool saves you guessing where the visible edge falls.

Ratios worth committing to memory: 16:9 for anything cinematic or video-adjacent, 4:3 for general photography and cards, 1:1 for avatars, product shots and anything appearing in a dense grid, 3:2 for straight-out-of-camera photographs, and 21:9 for wide heroes that sit behind text.

If a slot is still being designed and you want to see the shape before the real photos exist, drop in a placeholder image at the intended dimensions. It is much easier to argue about a ratio when you can see it.

You cannot add detail that was never captured

Take a 400-pixel image, set it to 1600, and you have a 1600-pixel image containing exactly as much information as before, now spread over sixteen times the area. The extra pixels are guesses averaged from their neighbours. The result is soft and slightly plasticky, and it is a bigger file than the original as a bonus.

The practical limit is about 1.5x for photographs before it becomes noticeable, and effectively zero for anything with text or hard edges, where the blur lands exactly where the eye is looking. A logo scaled up 4x looks unmistakably wrong to people who could not tell you why.

When you are handed something too small, the honest options are: get the original file, ask for a bigger export, retake the shot, or redesign the slot to be smaller. Displaying it at its native size in a smaller frame nearly always looks better than stretching it. A crisp small image reads as deliberate. A blurry large one reads as careless.

A workflow that stays out of your way

Keep the full-size original somewhere permanent and treat everything you publish as a disposable export. Once you have decided the slot needs 1600 by 900, that decision holds for every image that ever goes in it, so the work is one-time.

Batch the boring part. Crop to the ratio, resize to the target width, then compress, in that order, for every image in a set. If you also need a smaller format for the file size, do the conversion last with the format converter, after the dimensions are already correct.

Then check it on a phone. Almost every sizing mistake, in both directions, becomes obvious on a small high-density screen: too few pixels shows as softness, too many shows as a page that takes a beat too long to fill in. That single check catches more than any amount of arithmetic.