Spec & internals
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.
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 |
| 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:
- 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.
- 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 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. 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, so generate at final display size or larger. This is the default download from most generators, UseQR's API 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; the print case for it is on vector vs raster.
- 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.
- 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 checks the rendered result, and for print the checklist is test 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 — free, no signup
Related
- QR code anatomy — every region of the symbol — A labelled tour of a QR code: finder patterns, separators, timing, alignment, format and version information, the data region and the quiet zone.
- Vector vs raster QR codes — SVG scales infinitely; a raster QR must be 300+ DPI at final printed size — a 3 cm code needs at least 354 pixels. The print-shop arithmetic.
- QR code SVG path structure — How a module matrix becomes SVG — one merged path versus thousands of rects, crisp-edges rendering, integer coordinates, and why seams appear.
- QR code broken by image compression — JPEG ringing, chat-app recompression and low-quality WebP all eat module edges. Why compressed QR codes fail, and the PNG-or-SVG rule that prevents it.
- What DPI should a QR code be printed at? — Print QR codes from vector artwork — SVG or PDF — and DPI becomes irrelevant, because the RIP renders exact edges at the device's native resolution. If…