How to Prepare and Hand Over Website Photos Without Slow, Blurry or Badly Cropped Results

The short answer: keep your original files untouched in one place, give your developer a simple list that says where each image will be used and what matters in the frame, check that you have permission to use every image, and agree in writing who will upload new pictures after launch. The developer can then create the web versions. Image trouble is much easier to prevent when these questions are settled before the build starts.

This guide is practical advice rather than a universal standard. Your project, your platform and your developer may work differently, so treat every suggestion as something to agree together, not as a fixed service promise.

Why images go wrong

A photo that looks perfect on your phone can disappoint on a website in three common ways.

• Slow: one very large file is used everywhere, including small screens that never needed it.
• Blurry: a small or heavily compressed file is stretched to fill a wide space.
• Wrongly cropped: a landscape photo is forced into a square or a tall banner, and a face or your product is cut off.

All three are easier to avoid when everyone knows, early on, where each picture will appear.

Keep originals separate from delivery versions

Think of two folders with different jobs.

• Originals: the full size files straight from the camera, phone or designer. Do not edit or overwrite them, and keep a backup somewhere other than the developer's machine.
• Delivery versions: the resized, compressed copies the website actually serves.

Delivery versions can usually be produced again when you still have the originals and the processing workflow or settings that made them. The web.dev guide on automating image compression describes processing that leaves original files intact so settings can be adjusted later (web.dev, Automating compression and encoding). If only a shrunken copy survives, you lose flexibility: the detail the original captured is not recovered simply by enlarging the smaller file, so a sharper or differently framed version becomes harder to make.

Tell the developer where each image goes

A folder of files named IMG_4021 tells a developer almost nothing. For each image, consider noting:

• Page and use: for example, the top banner on the home page, a team portrait or a gallery tile.
• Focal point: the part that must not be cut off, such as a face, a product or a sign.
• Crop guidance: whether the image has spare room around the subject, and whether a wide, square or tall version might be needed.

The layout can show the same photo in more than one shape. A wide desktop banner might become a taller crop on a phone. If you flag the focal point, the developer can position the crop around it instead of guessing.

A hypothetical asset manifest

The example below is entirely invented for illustration. A spreadsheet or shared document works fine.

Name original files clearly and keep the manifest beside them. When someone replaces a photo later, the manifest shows what the old one was doing.

Confirm you have permission to use each image

Before handing images over, note where each one came from: your own camera, a photographer, a stock library, a supplier or a customer. Record the source and any terms or permissions in the manifest, and keep the receipt or message. Photographers and stock libraries may attach conditions to how their work is used. This is practical housekeeping, not a legal conclusion. If something is unclear, ask whoever supplied it, or seek qualified advice, before the image goes live.

Write alt text for the context, not the file

Alt text gives an image a text alternative. The W3C decision tree for the alt attribute shows that the right choice depends on the image's role on the page (W3C WAI, Alt Decision Tree). In plain terms:

• Decorative: an image that adds no information gets an empty alt attribute.
• Functional: where an image is what tells people what a link or button does, its alt text should communicate the destination or action. If real text next to it already says the same thing, an empty alt can avoid repetition, as the decision tree notes. Linked images do not all need extra wording.
• Informative: a photo or simple graphic that adds meaning gets a brief description conveying that meaning.
• Complex: a chart or detailed graphic needs its information included elsewhere in the page text.

The same photo can need different text on different pages. Add a short note to the manifest saying which category each image falls into. The owner usually knows the meaning best, and the developer can then help with wording.

Responsive variants, not one huge file everywhere

Uploading one enormous image for every screen sends more than many visitors need. A better approach is to prepare several sizes of each image and let the browser choose, using responsive image markup as the web.dev guide explains (web.dev, Automating compression and encoding). The same guide says sensible sizes depend on the space each image occupies in the layout, so there is no single correct width, file size or quality setting for every site. Ask your developer how they will decide, and suggest checking results by eye for softness or visible compression artefacts.

Loading and layout behaviour

Two technical details affect how the site feels.

• Do not lazy-load images visible at the top of the page. Lazy loading defers offscreen images, but web.dev advises against using it on images likely to be in view when the page loads (web.dev, Browser-level image lazy loading). A top banner should load normally.
• Set dimensions so space is reserved. The same article recommends width and height attributes so the browser can reserve room and avoid disruptive layout shifts.

These are developer tasks, but you can ask about them at review time.

Who does what

One possible split, to adjust for your project:

Owner

• Supplies original files and keeps a backup.
• Fills in page, use and focal point notes.
• Records the source and permission for each image.
• Helps decide which images are decorative, functional or informative.
• Names who will upload images after launch.

Developer

• Creates delivery versions and the sizes the layout needs.
• Applies crops around the focal points.
• Handles markup, including alt text, dimensions and loading behaviour.
• Checks images across screen sizes.
• Explains how future uploads should be prepared.

Launch acceptance checklist

Before sign off, walk through the site on a phone and a larger screen and check:

1. Nothing important is cut off in any crop.
2. No image looks soft or stretched at its displayed size.
3. The top of each page does not visibly jump as images load.
4. Images near the top of the page are not delayed by lazy loading.
5. Each image has the right kind of alt text for its role.
6. Complex images have their information in the page text too.
7. The manifest is complete and rights notes are filled in.
8. Originals are backed up outside the developer's machine.
9. You know how to replace an image, or who will do it.

FAQs

Should I compress my photos before sending them? It is usually better to send the originals. Resizing and lossy recompression are destructive: they discard detail you cannot restore. Lossless compression or archiving, such as a zip file, keeps the contents intact and is fine for transfer. If files are large, use a transfer method that handles size rather than shrinking the photos, and let your developer create the web versions.

What if I only have small or low quality photos? Tell the developer early. Ordinary enlargement does not restore detail the camera never captured, so what matters is how large the image will actually be displayed. A small photo may suit a small slot but struggle in a full width banner. Options include retaking the photo, using it in a smaller slot or choosing a different image. Deciding this before design avoids late rework.

Who should upload images after launch, and why ask now? Some owners want to update photos themselves through the content management system, while others prefer the developer to do it. The answer can shape how the site is built: self service needs clear instructions and guidance on preparing files, while developer managed updates need a simple request routine. Settle it before launch and store the manifest and originals where the responsible person can find them.

A modest next step

Before your next project conversation, list your ten most important images and note the page, the focal point and the source of each. If you are also pulling together wider requirements, the website project brief guide covers that side. If you are planning a new site, a relaunch, a small web app or a mobile app and would like to talk it through, you can see how I work on the work with me page.

Sources

• W3C WAI, An alt Decision Tree: https://www.w3.org/WAI/tutorials/images/decision-tree/
• web.dev, Browser-level image lazy loading for the web: https://web.dev/articles/browser-level-image-lazy-loading
• web.dev, Automating compression and encoding: https://web.dev/learn/images/automating