Optimize images for the web: formats, rights, metadata and load time

Images are the biggest transfer block on most websites, and they decide more than load time: accessibility, privacy and cease-and-desist risk. Embedding a camera original with 4,000 pixels and 5 MB into a website is only the most visible mistake. This guide walks the complete path from photo to delivered file: clear the rights, check the metadata, crop, compress, embed correctly and describe. Every step links the matching free tool, everything runs in the browser without uploads.

Rights first: where may your image come from?

Before formats and kilobytes, comes the question chain that decides every image use: who made the image, where does the file come from, which concrete license applies, and are all conditions met? An image appearing in Google Image Search is not free to use because of that. Copyright protects photographs regardless of where they are findable, and publishing on a website needs a proper rights basis.

The common Creative Commons variants compared:

Two clarifications prevent false conclusions. First: not every Commons image is CC0, Wikimedia mixes CC0, public domain works and various free licenses, the check always applies to the individual file description page. Second: ShareAlike concerns a distributed adaptation, not automatically every compilation, and a simple crop for layout purposes is not in every case a legal adaptation.

What a cease-and-desist letter can cost is shown by a concrete BGH ruling: in the so-called sports car photo judgment of 13 September 2018, besides the license analogy of 100 euros there was an additional 100 euros for missing attribution, a surcharge of 100 percent. That is one ruling, not a price list. Further practice points: do not sign pre-formulated cease-and-desist declarations with contractual penalties unchecked, law firms cite amounts from 5,001 euros as examples, and removing the image from the article does not automatically settle an injunction claim. When a letter arrives: secure the letter and deadline, have license evidence checked, do not ignore it and do not pay blindly.

For every used image, a small internal record pays off: source, author, concrete license with version, retrieval date, permitted uses. CC0 does not require attribution, but document the provenance anyway, because the release by the actual rights holder is no guarantee, and the Commons platform itself assumes no warranty for every license statement.

Metadata: what is inside a photo file

A photo is more than its visible content. The EXIF standard, in the current version 3.1 from January 2026, defines fields for camera make and model, capture time, GPS latitude and longitude, GPS altitude and even device and lens serial numbers. On top come XMP and IPTC structures with descriptions, keywords, depicted persons and rights notices. Not every field is filled in every file, but the risks are concrete:

The scenarios are everyday cases: a bicycle or jewelry photo for a classified ad can reveal the storage location via GPS, a home-office desk photo can narrow down the home address, children's photos can make daily routines recognizable through recurring location and time data. And a cropped photo can still contain the original content through the embedded preview, Apple explicitly documents a sharing option that transmits the original including editing history.

What platforms and built-in tools do, and what they do not. The IPTC platform test of 2019 showed removed metadata in saved output images for Twitter and a largely removed set with remaining rights fields for Facebook. That is a historical test, not a guarantee for every export path. The reliable finding is the opposite direction: a 2025 forensic study found complete EXIF preservation including identical file hashes for document-based transfer paths and direct email delivery. Anyone sending a photo as a file attachment transmits the metadata with it.

The built-in tools are partial solutions. On the iPhone, the share menu under Options switches off location, camera model and capture time remain in the file anyway. On Android, the camera app disables location tags, the setting name is vendor-dependent, Google documents Save location on its own devices and Location tags on Samsung. The Windows Explorer path via Properties and Remove Properties is not to be recommended as a complete cleanup after a 2022 investigation by Didier Stevens, the EXIF directory entries disappeared, but associated strings still sat in the data block. macOS Preview removes location data specifically, documented is that not as a full-delete mode.

The reliable way: before publishing, check the concrete file, then clean it deliberately. The Image Metadata Inspector shows what is in the file, GPS, camera data, timestamps. The Image Metadata Cleaner removes EXIF, XMP and ICC data without recompression for JPEG, PNG and WebP and reads HEIC and AVIF files. Then check the exported file again, not just the preview. One boundary case belongs here: section 95c of the German Copyright Act protects electronic rights-management information, so with third-party images do not delete rights notices unchecked.

A newer development on the side: the C2PA standard for Content Credentials cryptographically signs provenance and editing information and works together with EXIF, IPTC and XMP. Provenance becomes more verifiable, but provenance is not truth, and the removable embedding is not the whole system.

Formats 2026: WebP as default, AVIF as option, JPEG as fallback

The format question is no longer a matter of belief in 2026, but a trade-off of file size, browser support and encoding effort. The baseline numbers:

Three classifications that make many guides outdated. First JPEG XL: the statement practically dead for the web is outdated, Chrome decodes JPEG XL by default from version 155, Mozilla from Firefox 158, Safari has partially supported since version 17, Edge remains excluded up to and including 155. For Google Image Search, JPEG XL is nevertheless not in the supported formats list. Second AVIF: half the file size is a median from an older benchmark, not a promise for every file, and in a small benchmark from October 2026 some subjects came out larger with AVIF than with WebP. Encoding time there was 7.6 times higher than WebP in the median, one-time creation and caching relativize that. Third the Google formats list: Image Search supports BMP, GIF, JPEG, PNG, WebP, SVG and AVIF, documented in the image SEO page with the German version dated 4 March 2026. HEIC and JPEG XL are missing there.

The compression practice condenses into five rules:

1. Crop and resize first, then compress. Pixel dimensions follow the display width in the layout, not the camera. The Image Resizer resizes, crops and rotates.
2. Work losslessly until the subject is finished. Each repeated lossy encoding can accumulate losses. Create every web variant from the original or a lossless master, not from the previous export. Optional editing steps are bundled with the Image Filters before the final export.
3. Test quality 75 to 85 as a starting range. The number is not a quality percentage and not comparable across formats. For AVIF, do not simply copy the JPEG or WebP value.
4. Really look at the output. Check sky, skin, hair, small text and transparent edges for blocking, banding and fringing. A met KB budget proves nothing about quality.
5. Convert iPhone photos first. HEIC is not a cross-browser web format, the Image Converter accepts HEIC and produces web-suitable outputs.

The Image Compressor runs directly in the browser, uploads nothing and exports JPEG, PNG and WebP. Two limits stated honestly: there is no guaranteed target size, and AVIF export is not included. Anyone who wants to test AVIF needs an additional tool, and then checks the output again with the same eyes.

Realistic file size targets as working values, not Google rules:

The values come from vendor guides, TinyThis cites the pixel and KB ranges, Shopify cites 200 KB or less as a rule of thumb for finished web images. Two additions: on retina displays the source width doubles for the same CSS width, Shopify cites 400 by 400 pixels for a 200 by 200 CSS pixel field as an example, that concerns pixel dimensions, not automatically kilobytes. And a subject with fine vegetation needs more data at equal dimensions than a calm surface, the budget is a target, not a promise.

For the format basics across all file types, from CSV to MP4, the handbook has a dedicated article on data formats.

Embedding correctly: space reservation, loading behavior and priority

The embedding decides whether an optimized image also yields a fast page. Three attribute groups, three different jobs:

On width and height, the precise situation: the HTML dimensions are the robust default recommendation, web.dev names CSS aspect-ratio explicitly as an alternative for space reservation. A ratio deviating from the original then needs object-fit against distortion. For normal content images the rule still holds: set both HTML attributes, plus the responsive CSS rules max-width and height auto.

On loading behavior, the clear separation: lazy loading belongs on images further down, never on the likely LCP image, a smaller image still arrives late when it is requested late. web.dev documents Fetch Priority with a Google Flights test improving LCP from 2.6 to 1.9 seconds, a historical experiment, not a guaranteed effect on every website. decoding="async" is a hint that other content need not wait for the image decode, not an LCP guarantee.

One stumbling block for image search: Google indexes only images reachable via the src attribute of an img element, including inside picture. CSS background images are not indexed and receive no native lazy loading via the HTML loading attribute. For images that should be findable in Google Images, the rule is: img tag with a real src URL.

With responsive images, srcset describes the actual pixel width of the source files, while sizes describes the expected display width in the layout. Missing sizes makes the browser assume 100vw, the full window width, which leads to unnecessarily large downloads for narrower content images. In PageSpeed Insights, the earlier checks Properly size images and Serve images in next-gen formats have been merged since Lighthouse 13 into the Improve image delivery insight, field data covers the last 28 days.

Alt text: one attribute, two jobs

Alt text serves people who cannot see the image, and search engines classifying the subject. WCAG 1.1.1 requires purpose-appropriate text alternatives, Google uses the alt text together with computer vision and page context. The W3C decision tree sorts the cases:

Writing rules with examples: describe the information, not the object. Instead of alt="photo of a tool", better alt="clamp fixing two wooden boards at a right angle". Instead of alt="before after", better a statement about the visible result, such as the frayed edges on the enlarged lettering. About 150 characters are a rule of thumb, not a technical limit. Do not start with picture of or photo of, screen readers already announce images. And no keyword lists: Google warns that keyword stuffing in the alt attribute can lead to a spam classification.

The most common mistake here is the missing attribute instead of the empty value: if you omit alt entirely, some screen readers read out the file name. Purely decorative images therefore explicitly get an empty alt="". How widespread the gaps are is shown by the Web Almanac 2024: from the rounded desktop sample values, about 15 percent of images have no alt attribute and about 30 percent an empty value, so roughly 55 percent with non-empty alt text. A non-empty value does not prove a good description, a file name as alt text also counts as non-empty.

The file name itself is a small comprehension signal: Google names my-new-black-kitten.jpg as a better example than IMG00023.JPG and describes file names as very light clues about the subject. That is not a ranking promise, but a descriptive name costs nothing.

For graphics with overlaid text or meaning-carrying icons, WCAG 1.4.11 additionally applies: at least 3:1 contrast against adjacent colors for graphic components required for understanding. The Contrast Checker tests color combinations against WCAG, and for layout planning with reserved image areas there is the Placeholder Image Generator. The Color Picker helps with color values from a subject, for example for matching captions.

Images and Core Web Vitals

Images directly affect two of the three Core Web Vitals: the Largest Contentful Paint, when the main image is requested late, transferred slowly or rendered late, and the Cumulative Layout Shift, when images loading without space reservation shift content. The target values at the 75th percentile: LCP at most 2.5 seconds, INP at most 200 milliseconds, CLS at most 0.1.

The LCP diagnosis separates four partial times: Time to First Byte, Resource Load Delay, Resource Load Duration and Element Render Delay. An isolated optimization can shift time rather than always lowering the final value. In practice: first identify the actual LCP element, then check whether it is lazy-loaded, whether its discovery comes late and whether the file is unnecessarily large. The INP, by the way, does not benefit from image optimization, it measures interaction latency, not load time.

For more depth on measurement and further levers, the handbook article Build your own website has a dedicated section on Core Web Vitals, and the Website Performance Playbook walks the tool sequence.

The complete workflow: from camera to website

All steps of this guide in an order that works as a checklist:

1. Clear the rights. Check provenance, author and concrete license, four questions per image: who made it, where does the file come from, which license applies, are all conditions met?
2. Check visible content. Faces, license plates, documents, screen contents: effectively obscure whatever should not be public. The Censor Image editor pixelates or blackens deliberately. Separate the two protection layers: pixelating changes no metadata, removing metadata changes no pixels.
3. Check and clean metadata. Look inside with the Image Metadata Inspector, GPS, camera data, timestamps. Then clean with the Image Metadata Cleaner and check the exported file again.
4. Crop and resize. Determine the display width in the layout, choose matching pixel dimensions, implement with the Image Resizer. Plan double source width for retina.
5. Finish optional editing. Bundle brightness, effects and filters before the final export, with the Image Filters.
6. Choose format and compress. Convert HEIC first with the Image Converter, then compress to WebP or JPEG with the Image Compressor. Quality 75 to 85 as a starting range, compare the output with the original.
7. Check file size against the target budget. Hero under 200 to 300 KB, content image under 150 KB, thumbnail under 50 KB, as guidance values, not boundary laws.
8. Embed with width, height and matching loading behavior. Set space reservation, do not lazy-load the LCP image, use loading="lazy" for images further down.
9. Set alt text and file name. Describe informatively, decorate with empty alt="", no keyword lists.
10. Measure in the browser. Check in the developer tools which file is actually loaded, and scroll the page once completely, even lazy-loaded images can cause layout shifts.

For the guided processing of a single image, the Image Workflow Playbook walks the four steps filter, size and crop, convert and compress, all in the browser without uploads.

Common mistakes in image optimization

1. Embedding the camera original. 4,000 pixels and 5 MB for an 800-pixel layout field is wasted transfer.
2. Lazy-loading the LCP image. A smaller image still arrives late when it is requested late.
3. Omitting alt attributes instead of emptying them. Decorative images need a present, empty alt="", otherwise screen readers read file names.
4. Keyword lists as alt text. Google warns of spam classification, description beats keyword density.
5. GPS coordinates in classified-ad photos. The location switch when sharing is a start, still check the exported file.
6. Trusting Windows Explorer cleanup as a complete solution. The 2022 investigation shows leftover data in the data block, check the exported file.
7. NC images on ad-funded sites. Attribution does not lift the non-commercial condition.
8. Google Image Search as an image source. Findable is not licensed, the rights chain always comes first.
9. Assuming AVIF halves every file. The median from a benchmark is no per-subject promise, measure the output.
10. Treating JPEG XL as a web standard. The browser situation improved markedly in 2026, the Google formats list still does not include it.
11. Checking only the KB number. Blocking artifacts, banding and smeared text are seen in the image, not in the file manager.
12. CSS background images as content images. They are not indexed in Google Images and get no native lazy loading.

Frequently asked questions about images for the web

The most important questions from practice, answered briefly and with the state of research.

[The FAQ answers are in the FAQ block at the top of this page.]

If you want to go deeper on privacy: the guide Services without an account explains why local browser tools like the image tools of studio-tools work privacy-consciously, and the article Build your own website places images in the full launch context.