How to add a QR code to a design without breaking it

The five-minute version

1. Export from the generator as SVG. Fall back to a PNG of at least 1000 px on a solid white background only if the tool will not take vectors.
2. Place it, then size it for the reading distance using the ten-to-one rule. Never scale a PNG above 100%.
3. Leave a blank border four modules wide on all sides. Nothing may touch it: not a box, not a background photo, not the page edge.
4. Recolour only the dark modules, keep them clearly darker than the background, and set black to 100% K for print.
5. Export the final artwork as PDF, not JPEG, and scan the exported file on a phone before it goes anywhere.

What a design tool does to a code

The generator hands you a finished thing: a grid of squares whose edges are exact, whose contrast is absolute and whose margin is part of the specification. A design tool then treats it as an image, and an image is something to be arranged. Every operation in the toolbar — resize, crop, tint, add effect, export — is a transformation that assumes the picture will look fine if it comes out a little different. A photo does. A QR code is a data carrier, and “a little different” is the whole failure mode.

None of this is a criticism of the tools. It is a mismatch of intent: they optimise for how the artwork looks to a person, and the only judge that matters here is a camera reading a grid through a phone lens from a metre away. Five operations do most of the damage.

One: placing a raster where a vector belongs

A QR code is the ideal vector graphic. It is squares on a grid, two colours, no curves. An SVG says “a square from here to here” and the tool draws it exactly at any size, on any export, at whatever resolution the press asks for. A PNG says “here are some pixels”, and every time the tool scales it, it invents new pixels between the old ones. Scaled up, the module edges go soft. Scaled down, adjacent modules blend, and a square that should have been dark comes out grey.

Rule: SVG in, and only ever scale a PNG down. Canva takes SVG on its paid tier and PNG on the free one; if you are on the free tier, export the PNG at 1000 to 2000 px and place it smaller than its native size, never larger. Figma, Illustrator and Affinity paste SVG directly. InDesign places SVG, and also has its own vector QR generator under Object, which makes a static code and is a perfectly good choice. Word and PowerPoint insert SVG on current versions; on older ones, use the large PNG and switch off “compress images in file” before saving, because the default resamples every picture to 220 ppi on save.

Two: trimming the quiet zone

The blank border around a code is not white space to be reclaimed. It is four modules of nothing, on every side, and the scanner uses it to find where the pattern starts. The most common way a design breaks a code is a designer tightening the layout: cropping the export to the pattern edge, nesting the code in a tight box, laying it over a photograph, or running it to the trim line. Every one of those puts something dark next to the pattern, and the finder patterns stop being findable.

Keep the generator’s margin, and if the layout wants the code on a coloured panel, give it a white plate with the quiet zone inside it. On a busy background the plate is not optional, it is the only thing making the code a code.

Three: recolouring past the contrast floor

Brand colours are the second killer. A scanner reads luminance, how light or dark each module is, and cares nothing for hue. So navy on white is as good as black, charcoal on cream is fine, and a brand yellow, orange, light blue or pastel anything on white is a code that reads only in perfect light, which is to say on your monitor and nowhere else. Recolour the dark modules if you must; keep the light modules white or nearly so; and put a finger over the result and squint. If the pattern does not look dark on light, it will not scan.

The inverse is a risk, not a style. A light code on a dark panel reads on most current phones and fails on a lot of dedicated hardware — the door scanner, the till, the warehouse gun, older Android cameras. The screen guide has the same warning from the dark-mode side. If the design demands dark, put the code on a white plate.

Four: styling the modules and dropping in a logo

Rounded modules, dots instead of squares, gradients across the pattern and a logo in the middle are all things the design tool makes easy and the scanner tolerates only up to a point. That point is the code’s error correction: a level-H code can lose 30% of its modules and still read, level M about 15%, level L 7%. Styling spends that allowance. A logo covering a tenth of the area at level H is fine. The same logo on a level-L code is reading from the other side of the cliff, and the first smudge on the printed flyer pushes it over.

If the brief wants a logo, generate the code at level H in the first place — you cannot add error correction afterwards in the design tool, only spend it. Keep the logo centred, on a solid white box with a little padding so it never touches a module, and leave the three big corner squares and the smaller alignment square near the bottom-right corner alone; those are how the scanner orients the grid and no amount of error correction replaces them.

Five: the export pipeline

The code can be perfect in the file and still die on the way to the press. Three settings do it.

• JPEG. The format is designed to throw away exactly the information a QR code is made of: hard edges and high-frequency black-and-white. A code exported inside a JPEG gets ringing around every module. Export artwork with a code in it as PDF for print and PNG or SVG for screen, never JPEG.
• Rich black. A CMYK black built from four inks looks deeper on a photograph and registers slightly out on every module edge, because four plates never align perfectly. Set the code’s dark colour to 100% K, single ink, no cyan, magenta or yellow underneath. The same applies to the white: paper, not a four-ink “paper white”.
• Scale on the way out. Fit-to-page in the export or print dialog shrinks the whole artwork by 4 to 6%, and with it the code you sized so carefully. The label guide covers this at length; the short version is that every dialog between you and the press must say 100%.

Where the URL gets decided

The design stage is where the code’s destination becomes permanent, and it is worth noticing that the moment is not the print run. It is the approval: the client signs off the proof, the file goes to the printer or the sign shop or the packaging supplier, and from then on the code is fixed for the life of everything printed from it. Up to that moment you can regenerate for free, which is the only editability anyone actually uses.

Decide the URL before the designer starts, not after they finish. A dynamic code sells itself as the answer to “we might change it later”, but what actually happens later is the redirect subscription lapsing while the artwork keeps circulating. If the destination genuinely might move, encode a short path on a domain you own and keep the redirect yourself; the packaging guide walks through why. For everything else, put the final URL in the brief and generate a static code once.

Before you send the file

• Export the final artwork, open the exported file, and scan the code out of that, not out of the design canvas. The canvas shows you the source; the export is what leaves.
• Scan it at the size it will be printed. Zoom the exported PDF until the code is its real dimensions on your monitor and read it from the distance the finished piece will be read.
• Check the quiet zone survived every layer above the code. Turn on outlines or hide the background and confirm nothing sits inside four modules of the pattern.
• If the code lives in a batch — a spreadsheet of tables, tickets or vouchers — check that the merge field is on the code layer, and scan three: the first row, the last row, and one from the middle.
• When the printed proof arrives, scan the proof. Everything above is a rehearsal for that one test, and it is the only one that counts.