What Image Size and Format to Use for a Website
For most website images, resize to the largest size the image actually displays at (rarely more than 1920 pixels wide), save as WebP or a compressed JPG for photos and PNG only for graphics that need transparency, and keep the file under 200 KB wherever you can. That combination covers the vast majority of website images without a visible quality loss. The rest of this guide explains why those specific numbers, not just what they are.
Quick answer: Export each image as wide as its slot in CSS pixels times the screen's pixel ratio, as WebP or a compressed JPG for photos and PNG for transparency. A rule of thumb is under 200 KB for an inline image and under 500 KB for a large hero image.
Why website image size matters more than it looks like it should
Images are usually the heaviest part of a web page by a wide margin, often more of the total download than every other file on the page combined. A page that loads slowly loses visitors before they see it, and search engines measure load speed directly as a ranking factor. Fixing image size is one of the few web performance changes that costs nothing and breaks nothing: the picture looks the same, the file is just smaller.
The two levers that matter are pixel dimensions and compression. Pixel dimensions control how much raw data the image contains before any compression happens; compression controls how efficiently that data gets packed into a file. Most oversized website images have both problems at once: a phone photo shot at 4000 pixels wide, displayed on a page at 800 pixels wide, saved at full quality.
What pixel size actually to use
Resize to the largest size the image will actually display at on the page, not the size the camera or design tool handed you. A full width hero image on a typical desktop layout rarely needs to be wider than 1920 pixels; a blog post's inline photo rarely needs more than 1200; a thumbnail needs a few hundred at most. Uploading a 4000 pixel wide photo for a 600 pixel wide thumbnail wastes most of the download on detail nobody's screen will ever render.
If the same image needs to look sharp on both a phone and a large monitor, size it for the largest display it will realistically appear at, since a browser can always scale an image down to fit a smaller space, but it cannot add detail back in if the source was too small to begin with.
Image widths for common layout slots
One rule sits under every width below: a file should be as wide as the slot it fills, in CSS pixels, multiplied by the screen's pixel ratio. MDN's responsive images guide shows it with a 320 pixel slot, where screens with two device pixels per CSS pixel load a 640w file. MDN's devicePixelRatio page says a value of 2 is expected on HiDPI screens and that phone screens often report more. We read both pages, and web.dev's Responsive images lesson, on 8 November 2026. The export widths in the table are that arithmetic at ratios 1 and 2. The slot widths are examples we chose, except the 320 pixel slot, which is MDN's own example. The third file at ratio 3 for the phone row and the cap of 1920 pixels on the hero are our own judgment, not a rule from any of the pages.
| Layout slot | Slot width (CSS pixels) | Export widths (pixels) | Reason | Source |
|---|---|---|---|---|
| Full width hero | 1280 (an example width) | 1280 and 1920 | 1280 fills the slot at ratio 1. A 2560 file for ratio 2 costs far more bytes than the added detail is worth on a photo, so we stop at 1920 (our judgment). | MDN, Responsive images |
| Article column | 720 (an example width) | 720 and 1440 | The slot width, then the same width doubled for screens at ratio 2. | MDN, Responsive images |
| Card or grid thumbnail | 320 (MDN's example width) | 320 and 640 | The same pair as MDN's own example: the 640w file goes to screens at ratio 2. | MDN, Responsive images |
| Full width on a phone | 360 (an example width) | 360, 720 and 1080 | MDN says phone screens often report a ratio above 2. The third file, at ratio 3, is our judgment, not a figure from MDN. | MDN, Window devicePixelRatio (ratio above 2); the ratio 3 file is our judgment |
| Small avatar or logo | 96 (an example width) | 96 and 192 | A 96 pixel slot at ratio 2 needs 192, and at this size both files stay small. web.dev says images with lower pixel densities can look fuzzy. | web.dev, Responsive images |
The sources are MDN's Responsive images guide, MDN's Window devicePixelRatio page and web.dev's Responsive images lesson. For your own layout, type each slot width and the pixel ratios into the Responsive Image Calculator and it lists the widths to export.
Which format to actually pick
For a photo, use WebP if the site's audience is on a reasonably current browser (which covers almost everyone by 2026), or a compressed JPG as the safe fallback. Both use lossy compression built specifically for photographic detail, and WebP at an equivalent visual quality is usually meaningfully smaller than JPG for the same image. For a graphic that needs a transparent background, a logo, an icon or flat colour illustration, use PNG, or WebP's own lossless mode if the site already commits to WebP everywhere.
Do not save a photo as PNG. PNG is lossless, which is the wrong tool for a photograph's smooth gradients and thousands of subtle colour shades: the file ends up several times larger than the same photo saved as JPG or WebP, for no visible benefit, since a photo was never going to be pixel perfect on a screen anyway.
A realistic file size target
There is no single correct number, since a full width hero image and a small thumbnail have very different reasonable sizes, but a useful rule of thumb for an inline content photo is to keep it under 200 KB, and under 500 KB for a large hero image, before it starts noticeably dragging on page load, especially for a visitor on a mobile connection. If a page has a dozen images anywhere near a megabyte each, that page is carrying tens of megabytes before a single word of content downloads.
- Resize to the image's actual display size on the page, not the camera's original size.
- Photos: WebP first choice, compressed JPG as the fallback. Never PNG for a photo.
- Graphics with transparency: PNG, or WebP's lossless mode.
- Target under 200 KB for an inline image, under 500 KB for a full width hero image.
- Batch process: resize once, then compress, rather than eyeballing quality on every single upload.
Serving a different size to phones and desktops
A single fixed size image is a compromise: big enough to look sharp on a desktop monitor, which wastes bandwidth on a phone that displays it at half the width. Modern HTML supports a srcset attribute that lets a browser choose between several versions of the same image based on the visitor's actual screen size, downloading only the one it needs. Setting this up means preparing two or three sizes of the same image, commonly something like 800, 1200 and 1920 pixels wide for a hero image, which the Image Resizer produces quickly since the same crop and framing carry over between sizes, just the pixel dimensions change.
This matters most for the images visible without scrolling, since those delay how quickly a page feels loaded. Images further down a page benefit more from lazy loading, where the browser only downloads them once a visitor scrolls close enough to see them, which most current browsers now support natively with a single HTML attribute and needs no extra image preparation at all.
The mistake that undoes all of this
The most common way a well optimised image gets undone is uploading it somewhere that recompresses it again on top of the work already done, a content management system, a social platform share preview, or a page builder's own image handling, each applying its own compression pass. A JPG that was already carefully compressed once loses a little more detail every time it gets recompressed, called generation loss, so a file that looks fine locally can come out visibly softer once it has passed through two or three automatic recompression steps elsewhere. Where possible, upload the highest reasonable quality version and let a single system handle compression once, rather than pre-compressing hard and letting something else compress it again.
Doing all of this without leaving the browser
The Image Resizer changes the pixel dimensions to the size a page actually needs. The Image Compressor then handles the file size, with a quality slider or a target size in kilobytes if a specific limit matters more than a specific quality. The Image Converter switches format when the source file came in as the wrong one, such as a PNG screenshot of a photo that would shrink dramatically as a JPG instead. All three run entirely in the browser, so a batch of website images never has to leave the device to get resized, compressed and converted.