How to Display WebP Images in HTML

Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.

Use a normal <img> element: <img src="photo.webp" alt="Description" width="1200" height="800">. The browser requests the WebP URL from src. Use <picture> with a fallback image when older or unknown clients may not support WebP.

Display a WebP with <img>

For a page whose audience supports WebP, the simplest markup is:

#	Preview	Product	Price
1		Introducing Squoosh: A Beginner’s Guide to Image Compression (Wish I Knew This Sooner)	$6.99	Buy on Amazon

<img src="photo.webp" alt="A red bicycle beside a brick wall" width="1200" height="800">

The src value can be a relative path, an absolute URL, or a URL generated by your asset pipeline. The file extension does not perform a conversion; your server must return the actual WebP file with the image/webp media type. See MDN’s MIME type guide and its image format guide.

Write useful alternative text

Put the information a sighted reader would gain from the image in alt. For a product photo, identify the product and relevant state; for a chart, summarize its conclusion or provide the data elsewhere. If the image is purely decorative, use an empty attribute:

#1 Best Overall

Introducing Squoosh: A Beginner’s Guide to Image Compression (Wish I Knew This Sooner)

$6.99

Buy on Amazon

<img src="soft-gradient.webp" alt="" width="1600" height="400">

Do not omit alt on a meaningful image. The enclosed <img> is also where alternative text belongs when you use <picture>. Guidance for the element and its accessibility attributes is in MDN’s <img> reference.

Declare intrinsic dimensions

Set the source image’s intrinsic width and height when you know them. The browser can reserve the correct aspect ratio before bytes arrive, reducing layout movement. These values describe the file, not necessarily its final CSS display size.

Offer a fallback with <picture>

Use <picture> when a portion of your audience may lack WebP support or when you need format selection. Put a typed WebP source first and a normal <img> fallback last:

<picture>
  <source srcset="photo.webp" type="image/webp">
  <img src="photo.jpg" alt="A red bicycle beside a brick wall" width="1200" height="800">
</picture>

The browser evaluates the <source> candidates and uses the enclosed <img> if no candidate is suitable. The type="image/webp" hint allows an unsupported format to be skipped. The complete selection behavior is documented in MDN’s <picture> reference and <source> reference.

Choose the fallback format

• Use JPEG for photographic content when a broadly compatible lossy fallback is sufficient.
• Use PNG when the fallback needs transparency or lossless detail.
• Use AVIF first only when you actually generate and serve AVIF assets for your audience.

A three-format chain looks like this:

<picture>
  <source srcset="photo.avif" type="image/avif">
  <source srcset="photo.webp" type="image/webp">
  <img src="photo.jpg" alt="A red bicycle beside a brick wall" width="1200" height="800">
</picture>

Keep the fallback meaningful: it must still have the correct alternative text and dimensions if every source candidate is skipped.

Use responsive WebP files with srcset and sizes

If the image is the same subject and crop at every viewport but you have several resolutions, use width descriptors. Pair them with sizes so the browser knows the expected rendered width:

<img
  src="photo-800.webp"
  srcset="photo-480.webp 480w, photo-800.webp 800w, photo-1200.webp 1200w"
  sizes="(max-width: 600px) 100vw, 800px"
  alt="A red bicycle beside a brick wall"
  width="1200"
  height="800">

Each 480w, 800w, or 1200w descriptor must match the pixel width of its referenced file. The sizes expression describes layout width, not file width. This lets the browser select an appropriate candidate instead of always downloading the largest asset. See MDN’s responsive image guidance.

Combine responsive resolution and format fallback

Place a responsive WebP candidate in <source> and retain responsive JPEG (or PNG) choices on the fallback image:

<picture>
  <source
    type="image/webp"
    srcset="photo-480.webp 480w, photo-800.webp 800w, photo-1200.webp 1200w"
    sizes="(max-width: 600px) 100vw, 800px">
  <img
    src="photo-800.jpg"
    srcset="photo-480.jpg 480w, photo-800.jpg 800w, photo-1200.jpg 1200w"
    sizes="(max-width: 600px) 100vw, 800px"
    alt="A red bicycle beside a brick wall"
    width="1200"
    height="800">
</picture>

Use different crops with media queries

When a mobile composition needs a different crop rather than merely a smaller file, add media to a source:

<picture>
  <source media="(max-width: 600px)" srcset="bicycle-close.webp" type="image/webp">
  <source srcset="bicycle-wide.webp" type="image/webp">
  <img src="bicycle-wide.jpg" alt="A red bicycle beside a brick wall" width="1200" height="800">
</picture>

Keep the enclosed image as a valid fallback for clients that do not use either source. Use this art-direction pattern only when the crop or composition really changes; use srcset alone for same-crop resolution variants.

Which markup should you choose?

WebP size, quality and browser compatibility

WebP supports lossy and lossless compression, transparency, and animation. MDN reports that lossy WebP is 25–35% smaller on average than JPEG at visually similar compression levels, and that lossless WebP is typically 26% smaller than the same image in PNG. These are format-guide averages, not a promise for your particular image; compare your own files at an acceptable visual quality. Details are in MDN’s format guide.

Current major browsers have broad WebP support, but historical support is less complete. MDN specifically notes that Safari behavior depends on the Safari and macOS versions and calls out Safari 14 or later with macOS Big Sur or later. If your visitors include older software, retain the fallback rather than claiming universal support. Check the browser versions that matter to your site; no single compatibility statement covers every embedded browser or legacy device.

Make the server deliver the right asset

1. Verify the URL in src points to the WebP file you deployed, including capitalization and directory.
2. Request that URL directly and inspect the response headers. The media type should be image/webp, not an HTML error page or a generic type.
3. Check that the response body is the image, not a redirect to a login page, hotlink-denial page, or missing-file document.
4. If you changed the file but the old picture remains, purge the cache layer that serves that URL or publish a new filename.

Changing .jpg to .webp in a URL does not convert bytes. Convert the source during your build or image workflow, upload the resulting file, and configure the server or CDN to identify it as image/webp.

Troubleshoot a WebP that does not display

The broken-image icon appears

• 404 or wrong path: copy the exact URL from the rendered HTML and open it directly; correct the path or filename.
• Wrong response type: inspect headers and configure the server for image/webp.
• HTML returned as the image: resolve authentication, redirect, rewrite, or error-page rules at that URL.
• Unsupported client: add the <picture> fallback shown above.

The fallback never appears

Ensure the WebP is inside a <source> element within <picture>, and that the fallback is the child <img>. A standalone <source> is not the format-selection mechanism. Also check that the fallback URL itself loads.

The image causes layout movement

Add accurate intrinsic width and height to the fallback or standalone <img>. If CSS constrains the image, preserve its ratio with your layout rules rather than replacing those attributes with arbitrary numbers.

The wrong resolution or crop loads

For resolution switching, check that every srcset width descriptor matches its file and that sizes describes the actual layout width. For art direction, put the narrower media condition before the general source and verify each crop visually.

Or skip the browser setup

If you need a rendered reference of a page that uses WebP, ScreenshotNeo is a website screenshot API and MCP server. It accepts a URL and returns a PNG, JPEG, WebP, or PDF. Before capture it accepts cookie or consent banners and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each cleanup step can be turned off. Bot checks, CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed, and each response reports the result in X-Page-Verdict and X-Billed headers. An MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients.

Use the API documentation at screenshotneo.com/docs/ for authentication and options. This one-call example captures a page:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Python

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

Node.js

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo includes full-page capture with lazy images loaded, CSS-selector element capture, dark mode, 12 device presets plus custom viewports, retina scale, PDF paper and page controls, custom CSS and JavaScript, clicks, selector waits, delay or network-idle waits, request and resource blocking, custom headers, cookies, user agents, Authorization, timezone, geolocation, transparent backgrounds, resizing, configurable-TTL caching, signed links, asynchronous jobs with signed webhooks, bulk capture of up to 100 URLs per call, a usage API, an OpenAPI specification, and compatibility with parameter names used by other screenshot APIs.

Every feature is included on every plan: Free includes 1,000 shots per month with no card; Starter is $5 for 3,000; Growth $15 for 15,000; Pro $39 for 60,000; Scale $99 for 250,000; and Business $249 for 1,000,000. Yearly billing gives two months free. Sign up free for 1,000 screenshots a month with no card.

FAQ

Is WebP limited to still images?

No. WebP supports animation as well as lossy and lossless images. Your markup still uses <img>; the asset itself determines whether it is animated.

Should every image use <picture>?

No. Use plain <img> when one WebP asset meets your audience and layout needs. Add <picture> for a format fallback or a viewport-dependent crop.

Can CSS turn a JPEG URL into WebP?

No. CSS can style an image, but it does not change the bytes served by an image URL. Generate and deploy a WebP asset, then reference that asset in HTML.

Frequently Asked Questions

Can WebP be animated?

Yes. WebP supports animation; display the resulting asset with the same <img> element.

Do I need <picture> for every WebP?

No. Plain <img> is sufficient when you do not need a fallback or viewport-specific crop.

Can CSS convert a JPEG into WebP?

No. Conversion must happen in your image-generation workflow; HTML then points to the generated WebP file.

Quick Recap

Bestseller No. 1

Introducing Squoosh: A Beginner’s Guide to Image Compression (Wish I Knew This Sooner)

$6.99

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.