How to Prepare Images for a Website: A Practical Checklist

Images are usually the heaviest thing on a web page, and the easiest thing to get wrong. A 4 MB photo dropped straight from a phone into a CMS can slow a page down more than all of its scripts and styles combined. The good news: preparing images properly is a repeatable, five-step routine. This checklist walks through each step with concrete numbers you can actually use.

Choose the right format

Format choice decides your starting point. The same photo can be three times larger as a PNG than as a well-encoded JPG or WebP, before you touch any quality slider.

In 2026, WebP is safe to serve to essentially every browser your visitors use, and AVIF support is broad enough that serving it with a fallback is worthwhile for large hero images. If you have a folder of PNG photos, converting them with the PNG to WebP converter is often the single biggest saving you will make.

One trap to watch for: screenshots and exported graphics frequently arrive as PNG even when they are photographic in content, because PNG is the default in so many tools. Check what an image actually depicts, not what extension it happens to have.

Resize to the display size

A common mistake is uploading a 6000-pixel-wide camera original to fill a 700-pixel content column. The browser downloads every one of those pixels, then throws most of them away.

A practical rule of thumb:

• Find the widest size the image will ever display at (check your layout, not the file).
• Multiply by 2 to cover high-density (Retina-class) screens. A 700 px column needs a 1400 px image at most.
• Full-width hero images rarely benefit from more than 1920–2560 px, even on large monitors.

Resizing is where most of the byte savings live, because file size grows roughly with the area of the image: halving both dimensions cuts the pixel count to a quarter. Use the image resizer for one-offs, and if you serve multiple breakpoints, generate the whole set at once instead of resizing on demand.

Compress before you upload

After resizing, compress. For lossy formats the quality setting is the lever: for typical web photos, quality in the 70–85 range is visually hard to distinguish from the original while cutting file size dramatically. Below about 60, artifacts start to show in gradients and around edges.

Reasonable budgets to aim for:

• Thumbnails and small inline images: under 30 KB
• Content images in an article column: 50–150 KB
• Full-width hero images: 150–300 KB, occasionally more for AVIF-less fallbacks

These are guidelines, not laws — a photography portfolio will budget differently than a documentation site. The point is to have a number in mind and check against it. The image compressor shows a side-by-side preview so you can push quality down until you see a difference, then step back up. Everything runs in your browser, so originals never leave your machine.

If you are preparing a whole site’s worth of images, the batch processor applies the same resize, format and compression settings to the entire set and hands back a ZIP.

Strip metadata

Photos straight from a camera or phone carry EXIF metadata: capture date, camera model, editing software, and often GPS coordinates. On a website this is dead weight at best and a privacy leak at worst — anyone can download the file and read it.

Most compressors drop metadata as a side effect of re-encoding, but do not assume; verify with a metadata viewer. The metadata remover shows exactly what a file contains and strips it locally. One nuance: if an image has an embedded color profile (common in photos exported from editing apps), converting to sRGB before stripping keeps colors consistent across browsers.

Markup that helps the browser

Well-prepared files still load badly with careless markup. Three habits matter most:

• Always set width and height on <img> tags. The browser uses the ratio to reserve space before the file arrives, which prevents the page from jumping around as images load.
• Lazy-load below-the-fold images with loading="lazy"— but never on the main hero image, which should load as early as possible.
• Serve multiple sizes with srcset so phones do not download desktop-sized files. Our guide to the website image optimizer generates the size variants and the matching markup in one pass.

Descriptive alttext belongs on this list too — it is an accessibility requirement first, and a search benefit second.

The checklist

Pin this next to your CMS:

1. Pick the format: WebP/AVIF for photos, SVG or PNG for graphics, PNG/WebP for transparency.
2. Resize to no more than 2× the largest displayed width.
3. Compress at quality 70–85 and check against a byte budget.
4. Strip EXIF metadata; convert to sRGB if a color profile is embedded.
5. In markup: width/height set, alt written, loading="lazy" below the fold, srcset for responsive sizes.
6. Use readable file names (blue-heron-lake.webp, not IMG_4382.webp).

Finally, verify the result the way a visitor experiences it. Open your page with the browser’s developer tools on the Network tab, filter to images, and look at the transferred bytes: the total for a typical page should sit comfortably under a megabyte, and no single content image should dwarf the rest. If one does, it skipped a step above — usually the resize.

Once this routine is muscle memory, preparing images takes a minute or two per file — and your pages stay fast no matter who uploads next.