# QR codes in WebP and AVIF: what breaks

> Lossless WebP and lossless AVIF are safe for QR codes; lossy WebP and AVIF at converter defaults produce block artefacts that merge modules. The common trap is a CMS, CDN, or email pipeline silently recompressing your clean PNG. Serve SVG or PNG for codes, and always decode the served file.

Source: https://useqr.app/docs/troubleshooting/qr-code-in-webp-and-avif-issues · Last reviewed 2026-08-21 · UseQR is free forever, no signup.

---

## The format is not the problem: the mode is

WebP and AVIF each have two personalities. In **lossless** mode they reproduce every
pixel exactly: a lossless WebP of a QR code is as scannable as the PNG it came from, and
usually smaller (Google's own benchmark puts lossless WebP around **26% smaller than
PNG**). In **lossy** mode they are photo codecs, and photo codecs are optimised to throw
away precisely the thing a QR code is made of: hard, high-contrast edges.

The trouble is which mode you get by default. The reference WebP encoder, `cwebp`,
defaults to **lossy at quality 75**, and most bulk converters and "optimise my images"
tools follow suit. Convert a QR PNG with defaults and you get lossy WebP without ever
choosing it.

## What lossy compression does to modules

Lossy WebP and AVIF encode in blocks with frequency transforms, like JPEG. At low
bits-per-pixel the damage shows as **blocking**, faint square seams and smeared detail
that shift module boundaries and merge adjacent modules. One irrelevant reassurance to
discard: chroma subsampling, the classic JPEG villain, barely matters for a
black-and-white code, because the code lives in the luma channel. The blocking artefacts
are the real damage, and they hit luma directly.

The result is a code that often still scans at high quality settings and full size, and
fails once it is displayed small, printed, or recompressed again. It is the same failure
family as [JPEG damage](/docs/troubleshooting/qr-code-broken-by-image-compression), with a
modern file extension.

## The silent pipeline trap

The sharper trap is conversion you never asked for. You upload a clean PNG; the platform
serves WebP or AVIF:

- **CMS image pipelines**, WordPress optimisation plugins and image CDNs convert on
  upload or on delivery.
- **CDN "optimisation" features**: automatic format negotiation re-encodes images per
  visitor, usually lossily.
- **Email and messaging**, clients and platforms recompress inline images.

Your original file being pristine proves nothing about what visitors receive. The test
that counts: load the live page, save the image the page actually serves (or screenshot
it at 100% zoom), and decode *that* with our [scanner](/scan). If the served file fails,
exempt the QR image from optimisation (most plugins and CDNs allow per-file exclusions)
or serve it as SVG, which pipelines pass through untouched.

## Rule-of-thumb table

| Format and mode | Verdict for QR codes |
|---|---|
| [SVG](/glossary/svg) | Best: vector, immune to recompression, scales losslessly |
| PNG | Safe: lossless, universally supported |
| WebP lossless | Safe: smaller than PNG, but confirm the encoder was actually in lossless mode |
| WebP lossy | Risky: fine at high quality and full size, degrades badly below that; never for print masters |
| AVIF lossless | Safe in principle, but tooling defaults are lossy, so verify |
| AVIF lossy | Risky, same blocking failure as lossy WebP |
| JPEG | Worst, ringing at every module edge |

For print, the question answers itself differently: print workflows want
[SVG or PDF masters](/docs/print/why-you-should-print-qr-codes-from-svg), and WebP/AVIF
are not accepted by most prepress pipelines anyway. The web-format comparison in full is
in [QR code file formats compared](/docs/spec/qr-code-file-formats-compared).

## The verification habit

Whatever the format, the check is constant: decode the file that is actually served, at
the size it is actually displayed, with the [scanner](/scan), and run the
[validator](/validate) on anything destined for print. A code that decodes after the
pipeline has done its worst is a code you can trust.

## FAQ

### Can a QR code be saved as WebP?
Yes, safely, in lossless mode. Lossless WebP reproduces the code exactly and runs about a quarter smaller than PNG. The risk is that most converters default to lossy mode at moderate quality, which introduces block artefacts across modules.

### Why did my QR code stop scanning after my site optimised images?
An image-optimisation plugin or CDN recompressed your PNG into lossy WebP or AVIF on delivery. Decode the image the live page actually serves; if it fails, exclude the QR file from optimisation or switch it to SVG.

### Is AVIF worse than WebP for QR codes?
Neither is worse in lossless mode: both are exact. In lossy mode both damage module edges through block-based encoding; quality settings and encoders vary more with AVIF, and its tooling defaults to lossy, so verification matters more.

### What is the safest image format for a QR code?
SVG, because it is vector: no pixels to compress, no quality settings, immune to recompression pipelines, and it scales to any size losslessly. Where raster is required, PNG or verified-lossless WebP are the safe choices.

## Try it

- https://useqr.app/scan
- https://useqr.app/validate