What Size Should Images Be on a Website?

Images are the largest thing on most pages and the easiest thing to get wrong in both directions. Too large and the page crawls on a phone. Too small and it looks soft on a modern screen, which reads as cheap even to people who could not tell you why.

Our page speed checklist says to serve images at honest sizes and puts them second only to hosting. This is the same advice with the actual numbers attached.

What width should you export?

Start with one question: how wide will this image be on screen, at most? Then double it.

The doubling is not padding. Most phones and modern laptops draw two or three physical pixels for every layout pixel you specify, so an image that occupies 600 layout pixels is being drawn into roughly 1200 physical ones. Give it 600 and the screen stretches it and it looks soft.

Concrete starting points, assuming a fairly standard site:

• Full-width hero or banner: 1920 pixels. Go to 2560 if your audience is likely on large desktop displays and the image is the point of the page. Above that you are paying for pixels almost nobody resolves.
• Image inside a normal content column: 1200 pixels. Content columns are usually 600 to 800 wide, so this is the doubling rule with a little room.
• Half width, or one of two columns: 800 pixels.
• Card in a three-column grid: 600 pixels.
• Small thumbnail or avatar: 300 pixels.
• Logos and icons: not pixels at all. Use SVG, which is a description of shapes rather than a grid of dots, so it stays sharp at any size and usually weighs a few kilobytes.

Height follows from whatever crop you want. Nothing here depends on height, only on how many pixels across the image has to cover.

Which format should you use?

Four answers cover essentially everything.

WebP, for photographs and most images. This is your default. WebP files typically land 25 to 35 percent smaller than the same picture as a JPEG at matching visual quality, and every current browser reads them. It also supports transparency, which is the job PNG used to be kept around for.

SVG, for logos, icons and anything drawn rather than photographed. Because it stores shapes instead of pixels it is sharp at every size on every screen, and a typical icon is one or two kilobytes. If your logo is a PNG, replacing it with an SVG is usually the highest ratio of improvement to effort available on a site.

JPEG, as a fallback that is still fine. If your workflow produces JPEGs and something in your stack converts them later, that is not a problem worth solving twice.

AVIF, if you want to go further. Smaller again than WebP at similar quality. Browser support is broad now though a step behind WebP, and it takes longer to encode. Treat it as an improvement rather than a requirement.

Two to avoid. PNG for photographs produces enormous files, because the format was designed for flat graphics and does not compress the noise in a photo. GIF for anything longer than a second is worse than a video by a wide margin: a short muted video file will look better and weigh a fraction as much.

How much should you compress?

Quality 75 to 85 in whatever tool you use. Below 70 you start seeing it, above 90 you are storing detail nobody will ever perceive.

Better than a quality slider is a target weight, because that is what the visitor actually pays:

• Hero image: under 200 KB. Under 150 if you can get there.
• Image inside content: under 100 KB.
• Card or thumbnail: under 50 KB.
• Whole page, all images together: under 1 MB as a rough ceiling for a normal marketing page.

Then look at it. Compression damage appears first in three places: clear skies, skin tones, and smooth gradients, where it shows up as faint blotches or banding. Busy photographs hide it almost completely, which is why a landscape can take heavier compression than a portrait.

What WordPress already does for you

More than most people realize, which changes what is worth your time.

When you upload an image, WordPress creates several smaller copies of it and writes a srcset attribute into the page. That attribute is a list of options, and the browser picks whichever one suits the screen it is running on. It has worked this way since 2015, and it means a phone is usually not downloading the desktop version.

As of September 2026 WordPress will also generate WebP versions of uploads where the server supports it, and serve those to browsers that accept them. Whether that is actually happening on your site depends on your host, so check rather than assume: open a page, right click an image, and look at whether the file it loaded ends in .webp.

What none of this can do is invent detail you never uploaded, or make a 6000 pixel original stop being a 6000 pixel original in your media library. Automatic resizing works from what you give it, so the upload-time decision is still yours.

The three mistakes that actually cost you

One: lazy-loading the hero. Lazy loading defers an image until it is nearly on screen, which is excellent for the twenty images below the fold and actively harmful for the one that is already visible. Applied to the hero it delays the exact pixel Google measures as your Largest Contentful Paint. This is common because some setups apply lazy loading to everything by default, and it is worth checking rather than assuming.

Two: no width and height. When the browser does not know how much room an image needs, it lays the page out without it and then shoves everything down when the image arrives. That shove is measured as layout shift, and it is the thing that makes you tap the wrong link on a phone. Setting dimensions is free and fixes it completely.

Three: uploading straight from the camera. A phone photo is around 4000 pixels wide and several megabytes, and it carries location and camera data you may not want published. Resize before uploading. This one habit is usually worth more than every other optimization on the list.

The hero image deserves its own thought

It is almost always the largest element on the page, which means it is almost always what your speed score is actually measuring.

So: size it properly rather than generously, load it eagerly rather than lazily, and give it priority if your setup offers that. Consider whether it needs to be a photograph at all, since a gradient, a solid color or an SVG shape costs nothing and sometimes looks better than the stock image it replaced.

And if the hero carries text over it, check the contrast against the busiest part of the image rather than the average, using the numbers in our guide to color. White text over a photograph is the most common readability failure on the web, and it is invisible to the person who made it because they already know what it says.

A workflow that takes two minutes

Per image, before it goes near WordPress:

• Decide how wide it will display, and double it.
• Resize to that width. Not larger, and not by dragging a corner in the page builder.
• Export as WebP at quality 80.
• Check the file size against the targets above.
• Look at it once at full size, particularly any sky or skin.
• Upload, and set the alt text while you are there.

Any image editor does this, including the free browser-based ones, and after the third image it takes about thirty seconds. Alt text belongs in the list because upload time is the only moment you will reliably remember what the picture shows.

Bottom line

Twice the display width, capped near 2560. WebP at quality 80. Under 200 KB for a hero, under 100 elsewhere. Dimensions always set, lazy loading on everything except the hero, and nothing uploaded straight from a phone.

That is the whole discipline, and it costs a couple of minutes per image against a page that loads twice as fast and looks sharp on the screens people actually own. It is also the cheapest speed work available: no plugin, no hosting change, and no code. If you want the rest of the order to fix things in, that is in our page speed checklist.