What Image Size Should You Use on a Website?

Pixel dimensions — 1920 × 1080, say — are the grid of pixels in the file. This is the number a browser cares about, and the one that drives everything else.

File size — 240 KB — is the bytes transferred. It follows from dimensions, format and compression quality together.

DPI or PPI — 72, 300 — is a print instruction: how many of those pixels to lay down per inch of paper. A browser ignores it completely. A 1000-pixel-wide image tagged 300 DPI and the same image tagged 72 DPI are byte-for-byte identical in every way that affects a web page, and display identically.

This is worth being firm about, because "save images at 72 DPI for web" is repeated everywhere and is a leftover from 1980s display conventions. It is not wrong so much as meaningless: changing the DPI tag alone does nothing. What people usually intend by it — "do not put a print-resolution monster on a web page" — is true, and the way to act on it is to change the pixel dimensions.

The rule that replaces all of it: export at the pixel dimensions the image will be displayed at, adjusted for screen density.

Start from the space the image occupies in your layout, then double it for high-density displays.

Two adjustments to that table.

Do not double blindly. A 2× hero at 2400px wide is a large file, and the visible benefit on a phone is real but modest for a photograph. Doubling matters most for text, line art and interface screenshots, where softness is obvious, and least for continuous-tone photography.

Never upscale. Exporting a 600px image at 1200px invents pixels and produces a soft, larger file — worse on both counts. If the source is smaller than you need, the source is the constraint.

The compressor's longest-edge ladder maps onto this directly: 1920px for a hero, 1280px for most content images, 1080px for social, 800px for thumbnails. Set the longest edge and the aspect ratio is preserved, so portrait and landscape images in the same batch both come out sensibly.

A phone with a device pixel ratio of 2 or 3 packs several physical pixels into each CSS pixel, so a 400px-wide slot can display 800 or 1200 real pixels. That is why an image exported at exactly its display width looks slightly soft on a modern phone.

Doubling every image is the crude fix and costs everyone the larger file. The proper fix is to offer several sizes and let the browser choose, which is what srcset is for — MDN describes it as providing "possible image sources for the user agent to use", with width descriptors like 400w and a sizes attribute telling the browser how wide the slot will be.

The practical division:

• You control the HTML — use srcset with two or three widths. A phone takes the small one, a desktop with a high-density display takes the large one, and nobody downloads pixels they cannot show.
• You upload to a CMS or a builder — most generate responsive variants themselves from your upload. Give them a generous source, around 2× the largest display size, and let the platform do the rest.
• You are hand-writing a single img tag — export at 2× the display width and accept the compromise. It is the right call for a small site.

Whichever route, always set the width and height attributes. MDN is explicit about why: including them lets "the aspect ratio of the image to be calculated by the browser prior to the image being loaded", reserving the space and "reducing or even preventing a layout shift". It costs nothing and prevents the page jumping as images arrive.

Dimensions decide how much data there is to compress; these are the targets worth compressing towards.

They are not arbitrary. The reason to care about total page weight is that images are usually the largest thing on a page and frequently the element that Largest Contentful Paint measures — web.dev lists img elements among the element types LCP considers, and puts the threshold for a good score at 2.5 seconds or less, measured at the 75th percentile of page loads across mobile and desktop.

That percentile is the part people miss. You are not being judged on your own laptop on office wifi; you are being judged on the slower quarter of real visits. A 2 MB hero that loads instantly for you is exactly the file that fails the metric for someone on a phone with two bars of signal.

Reaching these targets is almost always a dimensions problem rather than a quality problem. A correctly sized 1200px image at 80% quality lands in the 50–150 KB band without effort; a 4000px image cannot, at any quality setting you would be willing to use.

Guessing is unnecessary — the browser will tell you.

Open your page, right-click an image, choose Inspect, and read the element's dimensions. Browser developer tools show both the rendered size (the space it occupies) and the intrinsic size (the file's real pixels). When the intrinsic size is much larger than the rendered size, you have found waste, and the ratio tells you exactly how much: an image rendered at 800px from a 3200px file is carrying sixteen times the pixel data it can show.

Chrome and Firefox will also flag oversized images in a Lighthouse or performance audit, with the saving estimated in kilobytes, which is the least arguable way to prioritise a batch of them.

Then it is one pass through the resizer for a whole folder, or the compressor if you want dimensions and quality set together. The wider checklist covers the rest of what makes images fast — lazy loading, format, and which image must never be lazy-loaded.