Image format checker

Images are typically the heaviest payload on a page — often 50-80% of total bytes transferred. The format an image is served in directly determines how large that payload is. Modern formats (WebP, AVIF) compress 25-50% better than legacy formats (PNG, JPEG, GIF) at equivalent visual quality, which translates into faster Largest Contentful Paint (LCP) — one of Google's Core Web Vitals ranking signals. Migrating hero images and above-the-fold content from JPEG to WebP or AVIF is often the single largest performance improvement available on a content site.

What this tool checks

• Broken <img> — no src, srcset, or data-src: invalid HTML
• Legacy JS lazy-loading — data-src / data-srcset patterns that could migrate to native loading="lazy"
• Legacy formats — PNG, JPEG, GIF, BMP images that could be served as WebP or AVIF
• Modern formats in use — direct .webp / .avif, or inside a <picture> with modern <source>
• SVG — correct format for icons and vector graphics (acceptable, not flagged)
• Data URI images — inline data:image/... images bloat HTML and can't be cached
• Unknown extension — images served from routes without a format extension in the URL
• srcset analysis — checks every URL in srcset, not just src
• Query-string tolerance — photo.jpg?v=1 is correctly recognized as .jpg

WebP and AVIF vs PNG and JPEG

• WebP (Google, 2010) — ~95% global browser support as of 2026. 25-35% smaller than JPEG at equivalent quality, supports transparency and animation.
• AVIF (AOMedia, based on AV1 codec) — ~94% global browser support. 30-50% smaller than JPEG. Slower to encode, so best for static assets that compile once.
• JPEG — the old standard. Still acceptable for photographic content if you don't want to migrate, but any CDN worth using can auto-convert to WebP/AVIF on the fly.
• PNG — use only when you need lossless or real alpha transparency beyond what WebP supports. Otherwise WebP is always smaller.
• GIF — use animated WebP or MP4 video instead. GIF is astonishingly inefficient for animation.
• SVG — use for icons, logos, illustrations. Not a raster format; comparison doesn't apply.

Good vs bad examples

Good — direct WebP with JPEG fallback via <picture>:

<picture>
  <source type="image/avif" srcset="hero.avif">
  <source type="image/webp" srcset="hero.webp">
  <img src="hero.jpg" alt="...">
</picture>

Good — responsive srcset with modern format:

<img src="photo.webp"
     srcset="photo-1x.webp 1x, photo-2x.webp 2x"
     alt="...">

Good — SVG for icons:

<img src="/icons/menu.svg" alt="Menu">

Good — native lazy-loading with a real format:

<img src="/photo.webp" loading="lazy" alt="...">

Bad — broken img (no src, no fallback):

<img>
<img src="">

Bad — large JPEG with no modern alternative:

<img src="hero.jpg" alt="...">  <!-- ~500 KB, could be ~250 KB WebP -->

Bad — legacy JS lazy-loading pattern (technically invalid HTML; use native loading="lazy"):

<img data-src="/photo.jpg" class="lazyload">

How to switch to modern formats

• Serve via <picture> with fallback — <source> entries for AVIF and WebP, <img> with JPEG as universal fallback
• Use a CDN with on-the-fly conversion — Cloudflare, Imgix, Cloudinary, AWS CloudFront with Lambda@Edge, etc. Serves WebP/AVIF to browsers that accept them, JPEG to everything else, with no change to your source HTML
• Save new images directly in WebP — modern design tools (Figma, Photoshop) export WebP natively
• Prioritize above-the-fold images — hero and LCP-element images matter most for ranking; deep-in-page images matter less
• Keep SVG for icons — don't "optimize" SVG icons into WebP; SVG is the right format for them

Common mistakes

• Relying on JS lazy-loading libraries — loading="lazy" is supported by 95%+ of browsers and doesn't require a library
• Huge PNGs used for photos — PNG is a lossless format; for photographic content it's always larger than JPEG/WebP
• Animated GIFs — animated WebP or MP4 video is 10-30× smaller for the same loop
• No modern format at all — if the site serves only JPEG/PNG, every photo is 25-50% larger than it needs to be
• srcset with only JPEG variants — responsive is good; staying on legacy format wastes the opportunity
• Large data: URIs — beyond ~1 KB the bloat outweighs the "one fewer request" benefit
• Missing src — for lazy-loading, use loading="lazy" with a real src, not empty data-src