PNG, SVG or PDF: which QR code file do you actually need

The code looked crisp in the design file and came back from the printer with soft, grey-edged modules that nothing will scan. Nine times out of ten the cause is a file format decision made three weeks earlier: someone downloaded a 256-pixel PNG and the layout scaled it up to 40 mm.

Raster and vector, in terms of modules

A QR code is unusually hostile to raster scaling, more so than a logo or a photograph, and it is worth being precise about why.

A PNG is a grid of pixels. The rasteriser divides the requested image width by the number of modules across — including the quiet zone — and fills whole pixels. A 25-module symbol with a four-module quiet zone is 33 modules wide; at 512 pixels that is 15.5 pixels per module, so some modules come out 15 pixels wide and their neighbours 16. Nothing is blurred, but the grid is no longer perfectly even. Ask for a width that is a whole multiple of that count — 528, which is 16 × 33 — and every module is identical.

An SVG contains the modules as geometry: rectangles on a viewBox of exactly one unit per module. There is no resolution in the file at all. Whatever renders it, at whatever size, computes the edges fresh.

Why a scaled-up PNG scans worse

When a layout program, a browser or a RIP enlarges a bitmap, it interpolates — it invents intermediate pixels, and along a hard black-to-white boundary that means a band of grey. A decoder thresholds the image to two levels and looks for module edges; a soft, ambiguous edge shifts where it thinks the boundary is, and the error compounds across the symbol. The effect is worst on small modules, which is exactly where you have the least tolerance to spare.

Scaling a PNG down is fine. Scaling one up is the failure. If the code will be resized at all and you do not control by how much, supply vector.

The PNG size a print size actually needs

Pixels needed = centimetres ÷ 2.54 × dpi. At the 300 dpi most commercial print expects:

Round up, never down. The image API caps a PNG at 1024 pixels, about 8.7 cm at 300 dpi, and that ceiling is deliberate: rasterising a 2048-pixel code costs the server roughly four times as much CPU as a 1024-pixel one, while the SVG of the same code is a few hundred bytes and renders in the same time at any size. So past 8 cm the answer is format=svg, which is what you wanted for print regardless. The on-page generator has the same 1024-pixel PNG ceiling and the same SVG escape hatch.

Note that this table is about file resolution, not about whether the code is big enough to scan. Those are separate questions, and the second one — module size against reading distance — is settled in what size a printed QR code should be.

SVG for print, and SVG for the web

For print, SVG is simply the right answer whenever the code will be placed by someone else, resized, or printed larger than a business card. It is a few hundred bytes, it carries no resolution to get wrong, and a printer’s RIP renders the module edges at the device’s own resolution.

For the web it is quietly the better choice too. A QR code SVG is usually smaller than a 256-pixel PNG of the same code, it stays sharp on a high-density display without a second asset, and it costs nothing extra on a 2× screen. The one case where PNG still wins on the web is HTML email, where SVG support is patchy enough that it is not worth the risk.

Why this site’s SVG has no logo

The logo overlay in the generator is drawn onto an HTML canvas in your browser — the image is composited into the bitmap, along with the white padding ring around it. The SVG export is produced separately, straight from the module data, and there is no image in it to embed. So a logo code comes out of the PNG download, and a vector logo code means placing the plain SVG in your design tool and putting the logo on top of it there. That is the better workflow anyway, because you can see exactly what you are covering. The rules for how much you may cover are in putting a logo in a QR code without breaking it.

Getting the file into a design tool

InDesign and Illustrator. Place or open the SVG directly. Illustrator will give you an editable group of paths, which is what you want if you need to recolour the modules to a spot colour. In InDesign, place it and do not scale it non-proportionally — a QR code stretched on one axis stops being square modules and decoders lose their grid.

Affinity, Figma, Inkscape. All open SVG natively. Figma is fine for on-screen work; for print, get it out as PDF rather than exporting a PNG.

Word, PowerPoint, Google Docs. These are raster environments in practice. Use PNG, at the pixel size from the table above for the size it will print at, and turn off any “compress images” option — Office will happily downsample it to 96 or 150 dpi on save and destroy the code silently.

Canva. Upload the PNG at a generous size. Canva’s SVG handling depends on your plan and it re-rasterises on export, so give it more pixels than you think you need and check the exported PDF at 400% zoom before it goes anywhere.

EPS and PDF, and how to get one from an SVG

Some printers still ask for EPS, and many ask for a press-ready PDF. Both are vector containers, and both can be produced from the SVG without any loss:

• Illustrator or Affinity Designer — open the SVG, save or export as PDF or EPS.
• Inkscape — open the SVG, then File → Save As and choose PDF or EPS. It will also do this from the command line, which is handy if you are generating codes in bulk.

The mistake to avoid is placing an SVG in a layout, exporting a raster preview and sending that. If the final PDF was flattened to an image, you have a PNG in a PDF wrapper and all the scaling problems came back with it. Open the finished PDF, zoom to 800%, and look at a module edge: vector stays a hard corner, raster goes stepped or fuzzy.

Colour space, and the rich-black trap

Design files for print should be CMYK, and a QR code should be 100% K only — one plate, one ink.

A “rich black” built from all four inks (something like 60/40/40/100) looks deeper on a large solid area, which is why designers reach for it. On a QR code it is a liability. Four plates have to register perfectly for the module edges to line up; any press drift, and every module gets a cyan or magenta fringe on one side. That fringe is exactly the soft, ambiguous edge a decoder handles worst, and it costs you contrast at the same time. Set the modules to K-only and let them be slightly less dense than the rest of the artwork.

The same logic applies to coloured codes: keep them to a single ink or a spot colour where you can, and check the luminance contrast rather than the hue — the colour and contrast article has the ratios that survive and the ones that do not.

If the code is going anywhere near a screen as well as print, export twice rather than converting once. An RGB PNG for the website and a CMYK vector for the press is less work than reconciling one file that has to be both.

Transparent backgrounds, and the busy-photo trap

light=transparent on the API, or the equivalent in the generator, gives a PNG with a genuinely transparent background and an SVG with no background rectangle at all. That is right when the code sits on a flat, light, solid colour and you want it to inherit that colour rather than sit in a white box.

It is wrong on a photograph, and this is the single most common design decision that produces an unscannable code. A photograph varies in brightness across the symbol, so the decoder’s threshold between light and dark ends up correct for one corner and wrong for another. Even a lightly textured background eats the contrast the quiet zone is supposed to provide.

If the design calls for a code on an image, put a solid light panel behind it with the four-module quiet zone measured from the edge of the symbol, not from the edge of the panel. It looks like a compromise and it is the only version that scans.

Whichever file you settle on, the format decision is not proved until a printed copy has been through the pre-print testing procedure on a real phone.