QR codes in CMYK print

Print QR modules as 100% K — single-plate black. Rich black and converted RGB black are four-colour builds, and normal press misregistration of around 0.1 mm puts a coloured fringe on every module edge, blurring the whole grid at once, which error correction cannot repair.

One plate or four

Offset CMYK builds every colour from four plates, and the plates never align perfectly — a well-run press holds registration to around ±0.1 mm. For photographs that drift is invisible. For a QR code it is structural: a module on coated stock is only about 0.4 mm, so a 0.1 mm offset between plates smears a fringe across a quarter of every module edge.

That is the entire argument for the rule: QR modules print as 100% K, nothing else. One plate, no registration to hold, edges as crisp as the press can make them.

The black builds compared

Build	Plates	Result on a QR code
100% K	1	crisp edges — the correct choice
Rich black (e.g. C60 M40 Y40 K100)	4	fringing risk on every edge
RGB #000000, auto-converted	4	same risk, arrives by accident
Registration black (100/100/100/100)	4	never use — ink limit violations on top

Rich black exists to make large solid panels look deeper, and it does. A QR code gains nothing from that depth — the decoder thresholds luminance, and 100% K is already comfortably past the 40% contrast requirement on white stock — while paying the full registration and dot gain price.

The RGB paste accident

The most common route to a four-colour code is silent: an RGB PNG dropped into a CMYK document. On export, colour management converts RGB black into a rich-black build across all four plates — no dialog, no warning. The layout looks identical on screen, and the problem only exists on press.

Two checks catch it every time:

Separations preview (Acrobat or InDesign output preview): turn off the K plate. A correct code vanishes; a converted one leaves a ghost image in C, M and Y.
A loupe on the wet proof: cyan or magenta shadowing along module edges means the build is wrong — that is precisely the failure to spot before signing the proof.

Placing a vector code and colouring it 100% K in the layout removes the risk entirely, which pairs naturally with printing from SVG.

Background and error correction

Leave the background as unprinted paper — 0% ink — and keep the quiet zone ink-free. A light tint background is survivable if the luminance difference stays above 40%, but it buys nothing.

Note what error correction can and cannot do here: it repairs localised damage, and registration fringing degrades every module simultaneously, so no EC level compensates. EC M is the sensible default; fix the ink build, not the redundancy. If brand colour is essential, a single dark spot ink preserves the one-plate property.

Before the run: validate the artwork, check the size against distance with the size calculator, and walk the pre-press checklist.

FAQ

Should a QR code be rich black or 100K?

100% K, always. Rich black prints from four plates, and normal registration tolerance of about 0.1 mm fringes every module edge — a quarter of a 0.4 mm module. Single-plate black has no registration to lose.

Why does my printed QR code have coloured edges?

The black is a four-colour build — usually an RGB image auto-converted on export — and the plates are fractionally out of register. Rebuild the code as 100% K, or place a vector code coloured in the layout.

How do I check a QR code is 100K before printing?

Open the print PDF in separations preview and hide the K plate: the code should disappear completely. Any residue on the cyan, magenta or yellow plates means the build is wrong.

Can error correction fix registration blur?

No. Error correction repairs localised damage — a scuff, a stain, a logo. Misregistration degrades every module edge at once, which is a systemic loss the decoder cannot vote its way out of.