QR code SVG vs PNG: which file format to use, and when

The five-minute version

1. SVG for anything printed, engraved, cut, or placed in a design tool. It is sharp at any size because it is geometry, not pixels.
2. PNG for email, social, messaging, and software that cannot import vector. Export it large: about 12 pixels per millimetre of the printed size, or twice the displayed size on screen.
3. JPEG never. Its compression works by softening exactly the edges a scanner reads.
4. PDF or EPS when a printer asks: make them from the SVG, never from the PNG.
5. Keep the SVG as the master and derive every PNG from it. The next print run, the bigger banner and the new letterhead are then free.

What the two formats are, in one paragraph each

An SVG is a list of instructions: a dark square from here to here, then another. Whatever opens it draws those squares fresh at whatever size and resolution is asked for, so a 2 cm label and a 2 m banner come out of the same file with the same perfectly hard edges. A QR code is the ideal case for this — a grid of same-sized squares in two colours, no curves, no gradients — which is why the file is also tiny, usually a few kilobytes.

A PNG is a fixed grid of pixels, each with a colour. It is exact at the size it was exported and only at that size. Shown smaller, the software averages neighbouring pixels together, which is safe up to a point; shown larger, it has to invent pixels between the ones it has, and it puts the inventions on the module edges, where a scanner is looking. The design guide walks through what that looks like once the file is in a layout. This guide is about the choice before that: which file to download for where it is going.

Choose by destination

• A printer, a sign maker, a label supplier: SVG (or a PDF made from it). Print is the one destination with no upper limit on resolution, so it is the one where raster is always a compromise. If the supplier’s form only accepts PNG, export at the size in the next section and say in the order notes that it must be placed at 100%, not scaled up.
• A design tool: SVG, on any tool that takes it — Figma, Illustrator, Affinity, InDesign, Inkscape, Canva on a paid tier, current Word and PowerPoint. The one thing to check is whether the tool keeps it as vector or quietly rasterises on import; see trap four below.
• A web page: SVG or PNG. Inline SVG is sharp on every display and a few kilobytes; a PNG at twice the displayed pixel size is fine and simpler to hand to a CMS. On a page, either works. What does not work on a page is a code too small to scan from a phone held at a laptop screen, which is a screen problem, not a format one.
• An email: PNG. Mail clients do not reliably render SVG; Gmail and Outlook strip or block it. Send a PNG on a solid white background, large enough that a phone can read it from another screen, and expect the client to show it at its own size regardless of what you intended.
• Social media and messaging: PNG, knowing it will be re-encoded. Nearly every platform converts uploads to JPEG and resizes them. You cannot stop that; you can only give it the least to damage: a large PNG, solid white background, code well inside the frame with generous margin.
• Engraving, vinyl cutting, embroidery, etching: SVG, always. These processes trace a path; a raster has none, and the software will either refuse it or auto-trace it, which turns square modules into wobbly approximations of squares.
• Anything else that asks for JPEG: PNG anyway. Nothing that accepts JPEG rejects PNG. The only reason to ever make a JPEG of a QR code is that a form will accept nothing else, and then make it from the largest PNG with the least compression the exporter allows.

When it has to be PNG: the arithmetic

The size of a PNG is a number of pixels, and the only question is how many you need for the physical size it will be shown at. For print the answer is 300 pixels per inch, which is roughly 12 pixels per millimetre. A 3 cm code needs about 350 pixels across. A 10 cm code, about 1,200. A 20 cm poster code, about 2,400. For a screen, twice the number of pixels it will be displayed at covers every high-density display in use.

Two consequences. First, if you do not yet know the final size, export large — 2,000 pixels or more — and place the file smaller wherever it ends up; shrinking is safe, enlarging is not, and a 4,096-pixel PNG covers a 34 cm code at print resolution. Second, the number is about the pixels in the file, not the “DPI” a program reports. DPI is a label a file carries suggesting how big to print it; changing it changes nothing about the pixels. A 350-pixel image labelled 300 DPI and the same image labelled 72 DPI are the same image, and both are a 3 cm code and not a centimetre more. The size guide has the module floor that decides how small the code itself can go.

Five ways a vector file goes wrong

SVG is the right answer for print so consistently that guides, including this site’s, tend to say “export as SVG” and stop. The format is not magic. These are the things that go wrong with a vector QR code, in the order they usually turn up.

1. Strokes instead of fills. Some generators draw each module as an outlined square rather than a filled one. It looks identical until the file is scaled, and then stroke widths do not scale the way fills do — some tools keep strokes at a fixed width, so the modules grow but their outlines do not, and a code enlarged for a banner arrives with thin-edged, hollow-looking squares. Open the SVG in a vector tool and check: modules should be filled shapes with no stroke.
2. Hairline seams between modules. A code drawn as hundreds of adjacent rectangles can show faint light lines where they meet, because the renderer anti-aliases each edge separately. On screen it looks like a fine grid over the dark areas. A good generator merges adjacent modules into single paths so there are no seams to draw; a press RIP usually closes them anyway, but a laser cutter or a vinyl plotter will faithfully cut every seam. If you see the grid in a preview, that is the file, not the display.
3. A raster logo inside the vector. A logo dropped into the centre is often a PNG embedded in the SVG. The code around it is still vector; the logo is a bitmap at whatever size it was, and it is the logo that will pixelate on the banner. Use a vector logo if the file is going large, or accept that the centre image has a size ceiling the code does not.
4. The tool rasterises on import. Canva’s free tier, most label-printing software, some sign-order portals and several online print shops accept an SVG upload and convert it to pixels on the way in, at a resolution you do not control. The file was vector; the artwork is not. If a preview looks soft at high zoom, this is why, and the fix is to supply a large PNG at a known size so at least the resolution is yours.
5. RGB black on a CMYK press. SVG has no CMYK. Its black is an RGB black, and a press that receives it may build the dark modules from all four inks, which is a rich black, and if the plates sit a fraction of a millimetre out of register the module edges go soft and coloured. Before sending to litho or offset, set the dark modules to 100% K in the vector tool. Digital and inkjet presses do not care.

Transparent or solid background

Both formats can carry a transparent background, and for a QR code you almost never want one. A transparent file contains no white, so the quiet zone — the blank border the scanner needs — is supplied by whatever the file sits on, and that is fine until it sits on a dark panel, a photograph, kraft stock, or an email client in dark mode. Export on a solid white background and the margin travels inside the file. The only case for transparency is a code that has been deliberately designed onto a specific light background and will never leave it.

The format outlives the print; the code has to outlive the format. A vector file is the durable artefact: it will produce a perfect code in ten years. That is only useful if what the code says is still true in ten years, and a code that points at a redirect service will fail when the subscription does, in every format. The static-versus-dynamic guide has the argument; the short version is that a static code and an SVG are the same idea applied to the data and the drawing.

The working habit

1. Download the SVG and keep it in the same folder as the brand assets, named for what it encodes. That is the master.
2. Make PNGs from the master when a destination needs one, at the size that destination needs, and treat them as disposable.
3. Scan the destination, not the file. A file that scans on your screen proves the generator worked; the format questions above are all about what happens after. The testing guide has the sequence.