Prepare Images for the Web: A Quality Checklist

Most images that look bad on a website are not bad photographs. They were exported at the wrong size, in the wrong format, sharpened at the wrong moment, or handed over with a colour profile the browser quietly ignores. None of those problems is difficult to fix. They just have to be checked in the right order.

This guide is that order. It starts with the two decisions that cause most of the damage — display size and format — and then works through colour, sharpening, compression and the small details that make a page feel finished. At the end there is a single checklist you can reuse for every image you publish.

1. Decide the size the browser needs, not the size in your source file

A camera delivers far more pixels than a web page can use. A 6000 px wide photo placed in a 720 px column wastes bandwidth, slows the page down and gains nothing visible. The reverse is worse: a 400 px image stretched across a full-width hero looks soft no matter how carefully it was edited.

Work from the layout inward:

• Measure the largest width the image will occupy in CSS pixels. For a full-width hero on a 1440 px page, that is roughly the content width, not the screen width, once margins and rails are counted.
• Multiply by 2 for high-density screens if the image is important. A 720 px wide image can be exported at 1440 px so it stays crisp on a phone or a laptop with a high pixel density display.
• Cap the result at the point where extra pixels stop being visible. For most editorial images on the web that ceiling arrives quickly; images above roughly 2500 px on the long edge are almost always heavier than they need to be.

If the same picture appears in three places — a card, a section image and a hero — export three sizes. CSS can scale one large file down, but the browser still downloads the largest version in every slot.

2. Treat DPI as metadata, not as a web setting

The 72 DPI idea survives because it is easy to repeat. It does not describe how browsers display images. A browser reads the pixel dimensions encoded in the file and lays the image out in CSS pixels; the DPI value written into the metadata is ignored for layout.

That has two practical consequences:

• Changing DPI from 300 to 72 does not make a file smaller or faster. Re-encoding it at a smaller pixel size does.
• The number that matters when you export from a photo editor is the pixel width and height, not a DPI field. If an export dialog offers both, adjust the pixels.

3. Choose the format by what the image contains

There is no universally best format, only a best match between content and codec. The useful split is:

Content	Good starting format	Why
Photographs, textured scenes, soft gradients	JPEG, WebP or AVIF	These formats handle smooth tonal transitions well and compress photographs efficiently
Flat graphics, icons, logos, illustrations with sharp edges	SVG when vector, otherwise PNG or WebP	Lossy compression around hard edges creates visible fringing and blur
Screenshots and UI captures	PNG or WebP	Text and thin lines survive lossless or high-quality encoding
Anything that needs transparency	PNG, WebP or AVIF	JPEG has no alpha channel, and transparent areas become a solid block
Images that need to work in the widest range of old software	JPEG or PNG	Both are understood everywhere

Two format mistakes are worth calling out. The first is exporting a screenshot as a low-quality JPEG: every letter and every table border acquires a halo, and the image stops being readable. The second is putting a photograph into an SVG. SVG is a vector format, so a raster photo inside it does not become sharper — it is simply wrapped in a larger file.

Modern formats such as WebP and AVIF usually produce a smaller file at comparable quality, but they are not automatically better if your workflow cannot preview the result. Export, open the file, and compare it at the size it will actually be displayed.

4. Correct and standardise colour before you export

The safe assumption for web delivery is sRGB. Screens, browsers and most publishing platforms treat sRGB as the baseline. If an image carries a wider profile — Display P3, for example — it may be displayed as if it were sRGB, which turns rich colours into oversaturated ones and subtle gradients into visible steps.

A sensible workflow is:

1. Edit in the widest profile you need, if you have a colour-managed setup.
2. Convert the document to sRGB before the final export rather than assigning an sRGB profile without converting. Assigning changes the label; converting changes the numbers to match the new target.
3. Look at the exported file once more, on the web, in a normal browser tab. That final check catches banding in skies, clipping in bright areas and profile mistakes that a colour-managed editor hides.

If you are publishing flat graphics with exact brand colours, sample the published result. Some colours shift slightly when a wide-gamut asset is converted, and it is better to know before a hundred images are live.

5. Sharpen after resizing, never before

Downscaling an image removes detail and leaves it looking slightly soft. The standard fix is a small amount of output sharpening applied after the resize, at the final pixel dimensions. Sharpening before the resize is not equivalent: the resize then averages away part of the sharpening, and artefacts that were invisible at full size can end up baked into the small file.

Keep output sharpening restrained. Text, fine line work and high-contrast edges are the first places where over-sharpening shows as a bright or dark fringe. Compare the exported result at 100% zoom before uploading. A slightly soft image reads as natural; an over-sharpened one reads as damaged.

The same logic applies to noise reduction. Aggressive noise reduction removes grain and fine texture together, so apply it at a size close to the final one and check the result there.

6. Compress for the target, then check it

Compression is where quality and weight trade against each other. There is no single correct setting, but a few habits keep the trade honest:

• Start with a quality that looks clean at 100% zoom, not the lowest number a slider allows.
• Judge at the display size. An image that looks fine in a 300 px card does not need to survive pixel-peeping at 300%.
• Compare file sizes between export attempts — the same visual quality is often available for substantially fewer bytes.
• Prefer a slightly smaller image over a badly compressed one. Reducing dimensions by 10% usually costs less quality than pushing compression far enough to hit the same byte target.

As a rough starting point, many editorial thumbnails land comfortably under 100 KB, section images under 250 KB and full-width heroes under 400 KB after correct resizing. Those are targets to check against, not rules to hit at any cost.

7. Handle transparency deliberately

If an image needs a transparent background, choose a format that actually supports it — PNG, WebP or AVIF — and check the result against the background colour it will sit on. Semi-transparent edges can show a halo if the image was exported with a matte colour that does not match the page.

If you do not need transparency, removing it saves bytes. Flattening a logo onto the exact background colour of the page often lets you use a smaller file and avoids a faint rectangle appearing around the graphic on a different background.

8. Keep text out of images

Text inside a raster image has three disadvantages: it softens when the image is scaled, it cannot be selected or translated, and search engines cannot read it. Headings, captions, interface labels and callouts belong in HTML and CSS. If a text element must be part of an image for design reasons, export it at the displayed size and avoid scaling it afterwards.

The exception is a screenshot of a real interface, where the text is evidence of the product rather than page copy. Even then, capture at the final display size where possible.

9. Finish with the details that make a page work

Small details are not decoration; they affect how a page behaves:

• Width and height attributes. Declaring the intrinsic dimensions lets the browser reserve space before the image loads, which prevents the layout from jumping.
• Lazy loading. Defer images below the first screen so the top of the page loads first. Do not lazy-load the main hero image, which is usually the element that determines the largest contentful paint.
• Alt text. Describe what the image shows and why it is there. A short, specific sentence is better than a list of keywords; decorative images should have an empty alt.
• Filenames. hero-photo-2026.jpg ages badly; team-workshop-editing-raw-files.jpg still describes the picture years later.
• A final visual check on a real page. Export, publish to a review page, and look at the image in context on a phone-sized viewport. A file can pass every technical check and still be the wrong size for the layout.

10. A workflow that fits in a browser

None of this requires a desktop application. If the only remaining changes are crop, straighten, exposure, colour conversion and a correctly sized export, a browser-based editor is enough — and it prevents the classic problem of opening a photo editor and “improving” everything along the way. The FreeAIGeneration photo editor runs in the browser with no account required, and the RAW photo editor handles files that need demosaicing before those final steps.

For logos and simple line artwork, exporting from a vector editor to SVG produces a file that stays sharp at every size and compresses to almost nothing. Keep the source document next to the exported asset so the next person can update the image instead of recreating it.

If a tool promises to fix an image with an AI feature — upscaling, noise removal, object replacement — read the claim carefully before you rely on it. Our explainer on what “AI-powered” actually means covers how those features are described and what to verify.

The checklist

Before any image goes live:

1. Display size measured, export size decided, high-density variant chosen where it matters.
2. Pixel dimensions adjusted; DPI ignored as a web setting.
3. Format matched to content; no text baked into a raster image unless it is a screenshot.
4. Colour converted to sRGB and checked in a browser.
5. Output sharpening and noise reduction applied after resizing.
6. Compression judged at display size, file size compared between attempts.
7. Transparency handled or removed deliberately.
8. Width, height, alt text, filename and loading strategy set in the page.
9. A final look at the published page on a phone-sized viewport.

Work through those nine checks and the quality problem usually disappears before anyone opens a code editor.