Bulk QR codes for print production: bleed, DPI and error correction

Export vector whenever the workflow allows it

A QR code is a grid of squares, which makes it an almost perfect candidate for vector output. SVG and PDF keep every module edge mathematically crisp at any scale, so the same file drops into a business card and a trade-show banner without degradation. For a bulk run, vector also keeps file sizes small enough that thousands of unique codes remain manageable in an imposition workflow.

Use PNG only where the downstream process demands raster — some variable-data printing pipelines and older RIPs still do. When you do, calculate resolution against the final printed dimensions, not the on-screen preview. A code that will print at 25 mm needs at least 295 pixels at 300 DPI; exporting the 150-pixel version that looked fine in the browser guarantees soft edges.

One further vector advantage at volume: modules stay perfectly aligned to the pixel grid at any output resolution, avoiding the subtle resampling artefacts that make raster codes lose contrast at the module boundaries.

Bleed, quiet zone and the trim that kills codes

Add the standard 3 mm bleed on any trimmed item, and then treat the code's quiet zone as untouchable. The quiet zone is a margin of at least four modules of background on all four sides, and it is part of the code, not padding around it. A guillotine that wanders a millimetre into that margin produces a code that fails on some devices and works on others — the worst possible outcome, because it passes casual testing and fails in the field.

In practice this means placing the code with its quiet zone entirely inside the safe area, not merely inside the trim line. On folded work, keep codes well clear of the fold: a crease running through the pattern breaks the module geometry that the decoder relies on, and no amount of error correction reliably compensates for a distorted grid.

For imposition, verify the quiet zone after the layout is assembled rather than in the individual artwork. Nesting many small codes tightly on a sheet is exactly where margins get quietly eaten.

Error correction, logos and how much damage you can absorb

The four error-correction levels recover roughly 7% (L), 15% (M), 25% (Q) and 30% (H) of a damaged or obscured code. Higher levels append more redundancy codewords, which raises the version and therefore the module count, so choosing H for everything is not free — it makes the pattern finer and can hurt more than it helps at small print sizes.

A centre logo consumes that recovery budget directly. Use Q as the minimum whenever a logo is present, H when the logo is prominent or the print conditions are rough, and never cover more than about a fifth of the total code area. Keep the logo away from the three large position-detection squares in the corners and the smaller alignment patterns — obscuring those defeats detection before error correction is ever consulted.

For bulk runs, pick one error-correction level for the whole job and hold it constant. Mixed levels across a set of codes produce mixed versions and therefore mixed physical module sizes, which makes it impossible to specify a single reliable minimum print size for the run.

• L (7%) — screens and pristine digital use only.
• M (15%) — the sensible default for clean coated print with no logo.
• Q (25%) — any centre logo, or uncoated and recycled stocks.
• H (30%) — harsh environments, laminate over textured surfaces, prominent logos.

Substrate and ink behaviour

Uncoated and recycled stocks absorb ink, which spreads the dark modules outward and narrows the light gaps between them. At normal sizes this is invisible; at 20 mm it can close the gaps enough that the decoder loses the grid. Compensate by printing larger, keeping the encoded payload short so the module count stays low, and where your press supports it, applying a slight negative trap to the code artwork.

Gloss and laminated finishes create the opposite failure: specular highlights that saturate the camera sensor at particular angles. Matte and silk finishes scan far more consistently, which is why they are the default for table tents and anything handled under directional lighting.

Dark substrates and inverted codes deserve extra caution at volume. Current iOS and Android cameras handle inversion, but a meaningful tail of older devices and third-party scanner apps still expect dark-on-light. On a five-thousand-piece run, a few percent of failures is a support burden you will hear about.

Variable-data runs: keeping thousands of unique codes straight

Unique codes per piece — serialised packaging, per-table restaurant tents, per-branch collateral, event badges — introduce a data-integrity problem on top of the print problem. Generate the codes from a single source list with a stable identifier column, and keep that list as the record of which code went where. Naming matters here for the same reason it matters in analytics: 'Branch 14, window' is retrievable a year later and 'code_0142' is not.

Build automated verification into the run rather than sampling by eye. Decoding the generated artwork programmatically and comparing the result against the source list catches off-by-one merge errors, which are the classic variable-data failure and are effectively invisible in a visual proof.

Because dynamic codes are re-pointable, a wrong destination discovered after printing is a dashboard edit rather than a reprint — provided the mapping between physical piece and code identity was recorded properly at generation time.

Pre-flight checklist before any run

Run this list on a physical proof, not a PDF. Every item on it corresponds to a failure that has cost somebody a reprint.

• Every code scans at final trim size, on at least two devices including one older handset.
• Quiet zone intact after imposition, folding and trim.
• Resolution verified against final print size, not screen size.
• Error correction level consistent across the run and appropriate for any logo.
• Destination URLs live and returning 200 — not staging, not a redirect chain.
• Codes are dynamic where the destination might ever change.
• Decoded output matches the source list, verified programmatically for variable-data runs.