# QR code file formats compared

> Use SVG for anything that will be resized or printed and PNG for fixed-size screen use. JPEG is never correct for QR codes: its 8 × 8 DCT blocks and chroma subsampling smear module edges. PDF and EPS are print hand-off containers; WebP is acceptable only in lossless mode.

Source: https://useqr.app/docs/spec/qr-code-file-formats-compared · Last reviewed 2026-08-21 · UseQR is free forever, no signup.

---

## The table

| Format | Type | Compression | Scales cleanly | Right for |
|---|---|---|---|---|
| **SVG** | vector | n/a (text, gzips well) | yes, infinitely | print, design hand-off, anything resized |
| **PNG** | raster | lossless | no, fixed pixels | screens, email, docs at final size |
| **JPEG** | raster | lossy, always | no | **nothing, never use for QR** |
| **WebP** | raster | lossy *or* lossless | no | web delivery, lossless mode only |
| **PDF** | vector container | n/a | yes (if vector inside) | print-shop hand-off |
| **EPS** | vector container | n/a | yes | legacy print workflows |

A QR code is the pathological worst case for lossy compression: nothing but hard
black–white edges, which is precisely the signal lossy codecs are engineered to
approximate away.

## Why JPEG is never correct

Two mechanisms, both structural to the codec:

1. **Block transforms.** JPEG compresses in **8 × 8 pixel DCT blocks** and discards
   high-frequency detail per block. A sharp module edge is almost pure high-frequency
   signal, so compression replaces it with "ringing", ghost ripples either side of every
   edge. On a code whose modules are only a few pixels wide, ripples from neighbouring
   edges overlap and shift where the decoder perceives the edge to be.
2. **Chroma subsampling.** Standard JPEG (4:2:0) stores colour at **half resolution in
   both axes**, a quarter of the colour information. Black-on-white codes lose least
   here, but any [coloured code](/docs/design/qr-code-colors-that-scan) has its module
   colour smeared across neighbours.

The damage compounds: every re-save re-runs both. A code that survives one save at high
quality dies after a screenshot-crop-resave cycle through messaging apps. The failure
gallery is at [QR code broken by image compression](/docs/troubleshooting/qr-code-broken-by-image-compression).
If a workflow will not accept anything but JPEG, export at maximum quality with the code
large in the frame, then verify.

## Notes on each survivor

- **PNG** is lossless, the pixels you render are the pixels stored. Its only failure
  mode is resolution: a PNG enlarged past its pixel size goes
  [blurry or pixelated](/docs/troubleshooting/qr-code-pixelated-when-enlarged), so
  generate at final display size or larger. This is the default download from most
  generators, UseQR's [API](/docs/developers/free-qr-code-api-no-key) included.
- **SVG** stores the geometry itself, so one file serves every size from favicon to
  banner. Structure details are on [QR code SVG path structure](/docs/spec/qr-code-svg-path-structure);
  the print case for it is on [vector vs raster](/docs/spec/vector-vs-raster-qr-codes).
- **WebP** has two modes, and the mode is the decision: lossless WebP behaves like a
  smaller PNG; lossy WebP shares JPEG's edge-smearing family of artefacts. Beware
  platforms that transcode uploads to lossy WebP without asking, symptoms catalogued in
  [WebP and AVIF issues](/docs/troubleshooting/qr-code-in-webp-and-avif-issues).
- **PDF** is what print shops actually ask for. A PDF with the QR as embedded vector art
  is as good as SVG; a PDF wrapping a low-resolution raster is exactly as bad as that
  raster. Which kind you have is worth checking before a print run.
- **EPS** survives in older prepress and cutter workflows. If a shop requests it,
  convert from SVG in a vector editor rather than exporting raster to EPS.

Whatever the container, the file is only proven when decoded from its final form,
[/validate](/validate) checks the rendered result, and for print the checklist is
[test before printing](/docs/how-to/how-to-test-a-qr-code-before-printing).

## FAQ

### Should a QR code be PNG or JPEG?
PNG, always. PNG is lossless, so module edges stay sharp. JPEG's block-based lossy compression rings and smears exactly the hard edges a decoder samples, and quality degrades further with every re-save.

### What is the best format to send a print shop?
Vector: SVG, or a PDF containing the code as vector art. Vectors rasterise at the press's full resolution at any physical size. If only raster is possible, supply PNG at 300 DPI or more at the final printed dimensions.

### Why did my QR code stop scanning after I uploaded it somewhere?
Many platforms recompress images on upload (often to lossy JPEG or WebP), and may also downscale them. Both operations blur module edges. Upload the code larger than needed, prefer platforms that preserve PNG, and rescan the published version.

### Is WebP safe for QR codes?
Only in lossless mode, where it behaves like an efficient PNG. Lossy WebP introduces edge artefacts of the same family as JPEG. If you cannot control which mode a pipeline uses, ship PNG instead.

## Try it

- https://useqr.app/url
- https://useqr.app/validate
- https://useqr.app/bulk