YouTube's WebP thumbnails are half the bytes of the JPEG at 1280x720. At 480x360 they are often bigger. 1,000 videos measured.

YouTube serves every video thumbnail in two formats. The JPEG lives under https://i.ytimg.com/vi/VIDEO_ID/ and the WebP under https://i.ytimg.com/vi_webp/VIDEO_ID/, same file names (maxresdefault, sddefault, hqdefault, and so on). The usual advice is "use the WebP, it is smaller." yt-dlp's issue tracker has a long thread arguing the opposite, titled "jpg thumbnails are actually better than webp?", and nobody in it had per-size numbers.

So I measured it. Short version: WebP is about half the bytes at 1280x720 and 640x480. At 480x360, the size most embeds and players actually use, WebP is the heavier file for 56% of recent uploads and 72% of videos uploaded in 2026.

What was measured

On 19 September 2026 I took 1,000 videos from the dataset behind an earlier availability study (8,664 videos): 500 from a sample of recent uploads pulled from channel RSS feeds, 500 from videos referenced on Wikidata, which skew older. Every one of the 1,000 has a maxresdefault.jpg.

For each video I sent a HEAD request to maxresdefault.webp, sddefault.webp and hqdefault.webp under /vi_webp/ and recorded the status and Content-Length. The JPEG sizes come from the 7 September measurements of the same videos. 3,000 requests, zero errors. No API key, no page scraping.

Per-size results

Medians are over videos where both files exist. The ratio column is the median of the per-video ratios, not the ratio of the medians.

At the two larger sizes the saving is consistent. Summed over all 965 maxresdefault pairs, the WebP files total 59.1% of the JPEG bytes, and the 90th percentile drops from 192.8 KB to 132.1 KB. At sddefault the sum is 59.5%.

hqdefault splits by upload age

The 33% figure at 480x360 hides two very different populations.

For the Wikidata-referenced videos (older, on the whole) the median ratio is 0.65 and WebP is larger for 10.4%. For the recent uploads the median ratio is 1.06 and WebP is larger for 56.1%.

By upload year, the share of recent uploads whose WebP hqdefault is bigger than the JPEG:

Vertical Shorts are the extreme case. Their pillarboxed hqdefault WebP is larger than the JPEG 85.3% of the time (n = 116, median ratio 1.17), while their maxresdefault WebP is only 0.40 of the JPEG.

Summed over every hqdefault pair, WebP still totals 82.7% of the JPEG bytes, because the older videos save a lot and the newer ones lose a little (median JPEG 16.7 KB against WebP 16.5 KB in the recent sample). If your traffic is mostly new videos, that average will not describe what you serve.

Two things this does not say. Bytes are not quality: the two files are separate encodes of the same frame, YouTube does not publish its encoder settings, and this dataset has no fidelity measure, so a heavier WebP may just be a higher-quality encode. And it does not say why the hqdefault ratio has drifted upward for newer uploads. The data shows the trend, not the cause.

A missing WebP is a 404 with an image body

30 of the 1,000 videos had no WebP at any of the three sizes, and 5 more had sddefault.webp and hqdefault.webp but no maxresdefault.webp. Every miss came back as HTTP 404 with a 552-byte image/webp body. That is the WebP twin of the JPEG behaviour, where a missing rendition is a 404 carrying a 1,097-byte grey 120x90 JPEG.

Browsers decode that body and fire load. So an onerror handler never runs, and the "fallback" you wrote quietly displays a grey rectangle. Recent uploads lacked the WebP maxresdefault less often (12 of 500) than the Wikidata videos (23 of 500).

Fallback that actually works

Server side, check the status. Browser side, check the decoded width, because the placeholder is 120 pixels wide and every real rendition is wider.

// Browser: try WebP first, then JPEG, at one size.
// Resolves to a URL whose decoded width proves it is a real thumbnail.
function loadReal(url) {
  return new Promise((resolve, reject) => {
    const img = new Image();
    img.onload = () => (img.naturalWidth > 120 ? resolve(url) : reject(url));
    img.onerror = () => reject(url);
    img.src = url;
  });
}

async function bestThumbnail(id, size = "maxresdefault") {
  const webp = `https://i.ytimg.com/vi_webp/${id}/${size}.webp`;
  const jpg  = `https://i.ytimg.com/vi/${id}/${size}.jpg`;
  try { return await loadReal(webp); } catch {}
  return loadReal(jpg); // let the caller step down to sddefault / hqdefault
}

// Node 18+: HEAD the file, trust the status code, not the body.
async function exists(url) {
  const res = await fetch(url, { method: "HEAD" });
  return res.ok;
}

What I would do with this

• At 1280x720 and 640x480, serve WebP with a JPEG fallback. Roughly half the bytes, and the WebP exists for 96.5% of videos that have the JPEG maxresdefault.
• At 480x360, measure before switching. For 2026 uploads the WebP was the larger file 72% of the time. If your pages show new videos, the JPEG hqdefault is the smaller download more often than not.
• Never trust onerror or the load event for a missing rendition. Check the status or the width.
• Do not promise 1080p. The realistic ceiling is 1280x720; a small set of legacy videos serves 1920x1080 at the maxres URL, and none of the recent uploads did.

Limitations

The sample is restricted to videos that have a JPEG maxresdefault, so it says nothing about WebP for the roughly 12% of videos that lack one. JPEG and WebP were measured twelve days apart; a thumbnail replaced in between would compare two different frames. WebP pixel dimensions were not read, only status and size.

Data

The full section, with the cohort tables, lives at thumbnailsgrabber.com/youtube-thumbnail-statistics#webp-2026-09. The per-video rows (video ID, cohort, and per size the WebP status, WebP bytes and JPEG bytes) are in youtube-thumbnail-webp-vs-jpeg-2026.csv, CC BY 4.0. The file names and URL patterns for every rendition are in the YouTube thumbnail URL guide.

If you have a fidelity measure (SSIM or similar) on a matched set of pairs, I would like to see it. The byte question is settled; the quality question is not.