How to Prepare Images for the Web: The Complete Checklist

Each step below gives the reason, the method and the number to aim for. The first four steps change the file itself and do most of the work: together they typically take a 3 MB phone photo down to about 200 KB. The last six are about how the page loads the file, and they decide whether a light image also appears fast.

The checklist

1. Choose the format: photos in WebP or JPEG, screenshots and flat graphics in WebP or PNG, logos and icons in SVG.
2. Resize to the displayed width × 2: about 1600 px for an article image, 1920–2400 px for a full-width hero, 600–800 px for a thumbnail.
3. Compress: quality 75–85 for photos, or a target size (50–150 KB for a content photo, 100–250 KB for a hero).
4. Strip metadata: remove EXIF data, GPS location and embedded thumbnails, and export in sRGB.
5. Name the file descriptively: blue-ceramic-mug.webp, not IMG_4821.JPG.
6. Write alt text: one short sentence that says what the image shows, or an empty alt for decoration.
7. Set width and height on every <img> so the layout does not jump (CLS under 0.1).
8. Lazy-load below the fold only: never the hero or any image that can be the Largest Contentful Paint (LCP under 2.5 s).
9. Serve responsive sizes with srcset and sizes so phones download a smaller file.
10. Check the result with PageSpeed Insights and the image audit.

1. Which image format should you use for the web?

The format sets how small a file can get before you touch any setting, so it comes first. Photos compress best with lossy formats: WebP is typically 25–35% smaller than JPEG at the same visual quality and works in every current browser, while JPEG remains the safest choice when a platform or email client insists on it. Screenshots, diagrams and flat graphics belong in a lossless format, because lossy compression smears text edges. Logos and icons should be SVG, which describes shapes instead of pixels and stays sharp at any size. For the side-by-side numbers, see WebP vs JPEG and the smallest image format for each job.

AVIF compresses photos even further than WebP, but it encodes more slowly and fewer apps open it. If your CMS or image CDN produces AVIF for you, use it; if you prepare files by hand, WebP is the practical default. Convert existing JPEG and PNG files with the WebP converter.

2. What size should images be for a website?

Pixel dimensions drive file size more than any other setting: halving the width removes 75% of the pixels. A 4032 px phone photo shown in an 800 px column carries about 25 times more pixels than the column needs on a standard screen, and still about 6 times more than a 2× Retina screen needs. The rule is simple: find the width at which the image is displayed (right-click it, choose Inspect, and hover the <img> in the developer tools to see its rendered size in CSS pixels), then export at twice that width so it stays sharp on high-density screens.

Going beyond 2× rarely pays: a 3× file weighs about 2.25 times as much as a 2× file for a difference few people can see. Never upscale a small image to reach these widths, since enlarging adds bytes without adding detail. The recommended image sizes guide covers more cases, and the compressor's Limit width option resizes and compresses in one pass.

3. How much should you compress, and what file size should you aim for?

Lossy compression at quality 75–85 removes detail the eye does not register at normal viewing size, and it usually cuts the file by half or more compared with quality 95. Start at 80 for photos, use 85–92 for screenshots and images with text, and go down to 65–75 for backgrounds partly covered by text. If you would rather think in kilobytes, set a target size instead: the compressor finds the highest quality that fits, and only scales the image down if even a low quality cannot reach the number.

• Thumbnail: 10–40 KB
• Content photo (1200–1600 px): 50–150 KB
• Hero or banner (1920–2400 px): 100–250 KB
• Screenshot with text: 80–220 KB

These are targets, not limits: a detailed aerial shot can honestly need 300 KB. Anything over 400 KB for an inline image usually means it was never resized. More detail in what is a good image file size and the best WebP quality setting.

4. Should you remove metadata from web images?

Yes. Camera and phone files carry EXIF data: date, device model, camera settings, often the exact GPS position, and an embedded preview thumbnail. None of it helps a visitor, it can reveal where a photo was taken, and it adds anywhere from a few KB to tens of KB per file. The compressor removes all of it on output (EXIF, GPS location, camera model and embedded thumbnails). Also make sure the image is in the sRGB color space: browsers treat untagged images as sRGB, so a photo exported in Adobe RGB can look dull once its profile is gone. Details in how to remove EXIF data.

5. How should you name image files?

Use a few lowercase words separated by hyphens that describe the picture: red-trail-running-shoe-side.webp rather than IMG_4821.JPG or Screenshot 2026-10-08 at 09.14.22.png. Google's image guidelines say the file name gives it a light clue about the subject, and readable names also make your media library searchable and your URLs cleaner. Avoid spaces (they become %20), keep names stable once published, and keep the extension honest: a WebP file should end in .webp. The rest of the picture is in image SEO best practices.

6. How do you write good alt text?

Alt text is read aloud by screen readers, shown when an image fails to load, and used by search engines to understand the picture. Write one short, specific sentence about what matters in context: “Runner tying a red trail shoe on a rocky path” beats “shoe”, and beats a list of keywords. Do not start with “image of”, since screen readers already announce it as an image. Purely decorative images (dividers, background textures) get an empty alt="" so assistive technology skips them. The alt text guide has more examples.

7. Why set width and height on every image?

When the browser knows an image's proportions before the file arrives, it reserves the space and the text below does not jump. That jump is measured as Cumulative Layout Shift, and Google rates a score above 0.1 as needing improvement. Put the image's real pixel dimensions in the tag, for example <img src="mug.webp" width="1600" height="1200" alt="…">, and keep it responsive in CSS with max-width: 100%; height: auto. Browsers derive the aspect ratio from the two attributes, so the image still scales down on phones without shifting the layout.

8. Should you lazy-load images?

Lazy-load images that start below the fold, and never the main image at the top of the page. loading="lazy" tells the browser to wait until an image is about to scroll into view, which saves data on long pages. But the largest image in the first screen is usually the page's Largest Contentful Paint element, and Google wants LCP under 2.5 seconds: lazy-loading it delays the download until the browser has worked out the layout. Load the hero normally and add fetchpriority="high" to it instead. See lazy loading without breaking LCP and how to fix Largest Contentful Paint.

9. Do you need srcset for responsive images?

If the same image is shown at very different widths on phones and desktops, yes. A phone with a 390 px wide screen at 3× density needs at most about 1200 pixels across, while a desktop column may need 1600. Export two to four widths and let the browser choose: <img src="mug-1600.webp" srcset="mug-800.webp 800w, mug-1200.webp 1200w, mug-1600.webp 1600w" sizes="(max-width: 800px) 100vw, 800px" width="1600" height="1200" alt="…">. WordPress, Shopify themes, Next.js and most image CDNs generate these sizes from one upload, so on those platforms the job is to upload a correctly sized, well-compressed master.

10. How do you check that your images are optimized?

Run the page through PageSpeed Insights. Since Lighthouse 13 (October 2025), oversized and poorly compressed files are listed together under the Improve image delivery insight, with an estimated saving in KB for each one, and the report names the LCP element so you can confirm the hero is not lazy-loaded. For a quicker answer focused only on images, paste the URL into the image audit: it lists the images on the page and how much each would save. Fix the biggest files first; they usually account for most of the weight. The PageSpeed images guide walks through each warning.

Which steps does your CMS or framework handle for you?

Some, not all. WordPress creates several smaller copies of each upload, adds srcset, width and height automatically, and lazy-loads images while trying to skip the first one; Shopify and most image CDNs resize on the fly; the Next.js Image component resizes, serves modern formats, builds srcset and lazy-loads by default. What none of them can do is choose a sensible master, write the alt text, name the file, or know which image is your LCP element. The split usually looks like this:

• Always yours: the format and size of the master (2400 px wide is plenty for almost any layout), quality, metadata, file name, alt text, and giving the hero high priority.
• Often automatic: smaller copies, srcset, width and height, lazy loading and, on some CDNs, WebP or AVIF delivery.
• Always worth checking: that the hero is not lazy-loaded and that the files actually delivered are small, with PageSpeed Insights or the image audit.

Common mistakes when preparing images

• Uploading the camera original and letting CSS shrink it: the visitor still downloads every pixel.
• Saving photos as PNG: a photo in PNG is typically 5–10 times larger than the same photo as a JPEG. See why PNG files are so large.
• Exporting at quality 100: it is not lossless for JPEG or WebP, and it typically makes the file 3–4 times larger than quality 80 for no visible gain.
• Lazy-loading everything, including the hero, which delays LCP.
• Leaving out width and height, which makes the page jump as images arrive.
• Treating 72 or 300 DPI as a size setting: DPI does not change web images; only pixels do. See image DPI for the web.