WEBP MIME Type – Free, Online, Private

What .webp is

WebP is a RIFF container. The first twelve bytes are RIFF, a little-endian size, and WEBP. Inside, VP8 is lossy, VP8L is lossless, and VP8X is the extended header used for alpha, animation, and the ICC profile. A still WebP and an animated WebP both use image/webp. RFC 9649 is the registration. Browsers that show WebP in an img tag have done so for years. A decoder that only understands the RIFF header and not the VP8 chunk will accept the type and still fail to draw pixels.

IANA registers image/webp in RFC 9649. The media type is image/webp. Extensions that use it on this page: .webp. A client compares the type, not the filename, once the response has arrived. The filename still matters on disk and in Content-Disposition, which is why a wrong extension and a wrong header are two different bugs.

What sends image/webp

What sends image/webp: Send image/webp for a .webp response, including an Accept-negotiated variant of a JPEG or PNG URL. When you negotiate, the Vary header has to include Accept, or a cache will hand the WebP bytes to a client that asked for JPEG. The Content-Type follows the bytes you actually sent. Do not leave image/jpeg on a body that starts with RIFF. Do not add a charset. A download of the original upload should use the type of the original, not the type of a transcode the user did not ask for. The file on disk is still .webp. Once the response exists, a client trusts image/webp, not the filename. If you offer WebP only as a negotiated variant, keep a JPEG or PNG at the canonical URL for clients that do not send an Accept that lists image/webp. The canonical response keeps its own type. Link headers can advertise the alternate. They do not replace Content-Type on the response the client is reading.

Content-Type for .webp

Send image/webp and do not add a charset parameter. The body is binary. A charset tells a text decoder to reinterpret bytes that are not text, which corrupts a download and does not help a browser sniff the format.

Content-TypeContent-Type: image/webp

nginx, Apache, and Express

These snippets map .webp to image/webp. nginx reads the types block when it picks a type from the URL's extension. A location that sets default_type, or an application that sets the header itself, overrides that map. Apache AddType applies in the directory context where you put it. The Express static example writes the header for files ending in .webp so a stale mime database in the framework cannot disagree with the type on this page.

nginx# /etc/nginx/mime.types, inside the types { } block
image/webp                  webp;

ApacheAddType image/webp .webp

Expressimport express from "express";

const app = express();
app.use(express.static("public", {
  setHeaders(res, filePath) {
    if (filePath.endsWith(".webp")) {
      res.setHeader("Content-Type", "image/webp");
    }
  },
}));

Pitfalls for image/webp

Pitfalls that show up for image/webp, and not for a neighboring type with a similar extension: The usual production bug is a converter that writes WebP and a framework that still sets image/png because the route was /photo.png. The img tag may still decode it, and a strict client will not. The second bug is animated WebP served to a pipeline that takes only the first frame and then caches that still image under the animated URL. The third is skipping Vary and poisoning a shared cache. The fourth is treating WebP as always smaller. A small PNG icon can grow when you put it in a lossy WebP. Measure the file.

• Lossless and lossy WebP share image/webp. The chunk fourcc tells them apart.
• A RIFF size that does not match the body is a truncated file. Proxies that buffer badly produce this.
• image/x-webp is an old unofficial value. Send image/webp.
• Alpha in VP8X is not the same as a GIF transparent index. Do not drop the ALPH chunk and expect the same edges.