A website image is ready when it has a clear purpose, permission to be used, an appropriate crop, an efficient file and a text alternative that fits its role. The smallest file is not always the best choice: visitors still need to recognise a product, read a diagram or understand the point of an illustration. Check the image in its actual page before approving it.
Use this checklist when preparing a new site, replacing an oversized banner or handing a folder of assets to a developer. Work through one representative image first, agree the decisions, then repeat them across the rest. Keep the original separately so a future redesign does not depend on an already compressed export.
1. Decide what the image needs to communicate
Write a one-sentence job for each image. A product photograph might show a surface finish; a process diagram might explain a sequence; a decorative texture might simply support the page's mood. If nobody can describe the job, reconsider whether the download earns its place. A smaller page can come from removing an unnecessary image, not just compressing every existing one.
Record the source, creator or supplier, permitted use and any required credit alongside the master file. Check whether the permission covers the intended website use and any editing or cropping. A file arriving in an email does not, by itself, settle those questions. Escalate uncertain permissions to the responsible rights holder or qualified adviser; this is an asset-management check, not legal advice.
For generated concept imagery, retain the prompt and generation record and label its role honestly. Do not present an imagined workspace, team or product as a photograph of the business. Remove unnecessary personal information from screenshots and inspect the final export, including anything visible in browser tabs or account panels.
2. Choose a format for the content
Choose a starting format, export a candidate, then compare it with the original at the size people will see. Different images respond differently to the same encoder settings. There is no single quality number or file extension that makes every asset ready for publication.
- Photographs and detailed illustrations: compare WebP or AVIF with a well-encoded JPEG. Keep the option that preserves the detail that matters at an acceptable transfer size.
- Simple logos and diagrams: consider SVG when a trustworthy vector original is available. Review the supplied SVG before adding it to the site and keep essential text available in the page.
- Raster artwork requiring exact edges or transparency: compare PNG with a suitable lossless or transparent WebP export. Inspect thin lines, lettering and translucent edges against the actual background.
- Animated assets: first ask whether movement adds information. A still image may communicate the same point with fewer distractions and a simpler delivery path.
These are test starting points, not a requirement to create every format. Each additional variant needs a reason and a working delivery setup. An unused AVIF sitting beside the live JPEG improves nothing. Keep export settings in the asset record so another person can reproduce a correction without guessing.
3. Match dimensions to the layout
Separate the source dimensions, the displayed dimensions and the crop. A photograph can contain thousands of pixels while appearing in a modest card. Exporting the full camera original for every card wastes transfer without necessarily making the card more useful. Conversely, stretching a tiny export across a large display exposes softness.
Responsive image markup can offer several image widths through srcset, with sizes describing the expected layout width. The browser selects a resource using that information and its environment. Use picture when the composition needs to change, such as a tighter mobile crop. MDN explains the distinction between resolution switching and art direction in its responsive images guide.
For the review, list the actual slots: full-width banner, two-column content image, card and social preview. Check a narrow phone and a wide screen. Keep the subject away from edges that disappear during cropping. If a face, label or important feature is cut off, changing compression will not solve the problem; change the crop or layout.
Set appropriate width and height attributes so the browser can reserve space using the image's aspect ratio. Make sure the responsive CSS and any alternative crops agree with that reserved space. Test the initial load as well as the fully loaded page: a stable screenshot can hide a jump that happened earlier.
4. Compress without losing the reason for the image
Compare exports side by side at their intended display size. Inspect gradients for banding, fine edges for halos, small details for smearing and transparent areas for unexpected fringes. For product imagery, confirm that a texture or colour distinction has not disappeared. The acceptable compromise depends on what the visitor needs to learn.
Agree a working size budget for each slot, then investigate exceptions. A detailed instructional image may deserve more bytes than a decorative card. A budget should prompt a useful conversation about format, crop and dimensions; it should not force an unreadable result or become an invented universal rule such as “every image must be below 100 KB”.
Measure the file the browser actually receives. A content system might recompress an upload, serve an unexpected variant or retain a previous cached image. Inspect the rendered page and network response after publication. Keep one approved master and clearly named exports, rather than repeatedly saving an already compressed image through another lossy step.
5. Write alt text for the image's role
Start with the surrounding content. Informative images need a text alternative that conveys their relevant meaning; decorative images normally use an empty alt="". If an image supplies a link or button's accessible name, describe its action or destination. Complex diagrams need a fuller explanation available nearby. The W3C alt decision tree helps distinguish these situations.
For example, a close-up on a materials page might use “Brushed brass handle with a rounded edge”. A linked icon leading to a download needs the download's purpose, not a description of the arrow. A decorative glow behind a heading should not announce “blue glowing background” to every screen-reader user. The same picture can need a different alternative on another page because its job has changed.
Write concise, natural language and include details only when they help replace the relevant visual information. Do not pack service keywords into the attribute. Check whether a caption or adjacent paragraph already says the same thing, and avoid making the reading experience needlessly repetitive. Translate alternatives with the page, including any meaning affected by localised labels or screenshots.
Review the page with images unavailable and inspect the accessible names of image links. This catches missing meaning and duplicate announcements that a visual review can miss. Automated checks can flag a missing attribute, but they cannot reliably judge whether a sentence describes the right thing.
6. Load the important image at the right time
The main image visible on arrival should not be delayed by lazy loading. Images further down the page are candidates for loading="lazy". Reserve their space too. The web.dev lazy-loading guidance explains why initially visible images need different treatment from those outside the initial viewport.
Check which image actually becomes the largest visible element on the page. A large decorative banner may compete with the headline and useful content. If the hero is the likely Largest Contentful Paint image, make it discoverable early and assess whether a high fetch priority is appropriate. Giving every image high priority removes the useful distinction.
Test with a fresh load and a constrained connection, then scroll through the entire page. Look for blank spaces that remain empty, visible content shifts and downloads much larger than their display slots need. Treat a local performance audit as evidence about that tested page and setup, not a promise about every visitor's connection or device.
7. Use a decision worksheet before exporting
Keep this small record with the asset folder. It links a visual decision to an implementation check and gives the next editor something more useful than a filename ending in “final”. Complete one row per role when the same master appears in several places.
| Decision | Record and verify |
|---|---|
| Purpose and source | What the image explains; master file; permission or approval record. |
| Placement and crop | Page and slot; displayed widths; focal point; mobile crop. |
| Export | Chosen format; pixel dimensions; file size; settings; visual review. |
| Alternative | Informative, decorative or functional role; localised text; nearby explanation. |
| Delivery | Responsive variants; reserved dimensions; loading behaviour; live URL. |
Consider a hypothetical ceramics shop preparing a bowl photograph for a product page. The master is a 4000-pixel-wide approved photograph. The team checks the actual product slot, exports two useful widths, compares JPEG and WebP, and chooses the version that preserves the glaze detail. The phone crop keeps the rim visible. The alternative describes the relevant finish; the adjacent product text carries dimensions and care instructions.
That example is a decision process, not a prescribed export recipe or a client result. A texture close-up, size diagram and decorative campaign image would lead to different choices. Record the reason for an exception so the next update does not undo it.
8. Check discovery and the final page
Use standard image elements for meaningful content, provide a working src fallback and keep image URLs accessible to crawlers when discovery is intended. Use descriptive filenames and place images beside relevant text. Google's image SEO guidance explains these practices; it also notes that Google does not index CSS background images. These checks support discoverability but do not guarantee indexing or rankings.
- Confirm the approved image, crop and alternative in every published language.
- Check the selected responsive file, intrinsic dimensions and loading behaviour.
- Follow image links with a keyboard and verify that their names make sense.
- Inspect the social preview separately; it may use a different crop and file.
- Keep the master, export settings and permission record available for the next update.
If image preparation is part of a wider website project, review Digital Studio's website service and include the existing assets and missing imagery in your website brief. A clear asset list helps the project start with concrete decisions about what to keep, replace or create.
