If the printer accepts vector, send SVG, EPS or PDF and DPI stops being a question, because vector carries no resolution at all. When a raster file is required, 300 DPI at the final printed size is the floor: decide the printed width first, multiply by 300, and export at least that many pixels. What decides whether the scan works is printed pixels per module, and below roughly four of them the edges smear.
A designer exports a 300 by 300 pixel PNG for a code that will sit three inches wide on a trade show banner. On paper that works out to 100 DPI. The proof looks fine on a laptop, the printed code fails on half the phones that try it, and everyone blames the QR code rather than the file.
Print resolution is the most common reason a code that worked on screen stops working on paper. It is also one of the easiest problems to avoid, because the correct answer usually involves not thinking about DPI at all.
If the printer takes vector, send vector
SVG, EPS, and PDF describe a QR code as what it really is: a set of rectangles with coordinates. There is no resolution attached. Print it on a business card or on the side of a truck and the edges stay mathematically sharp, because the press software redraws the geometry at whatever resolution it runs.
Ask for vector first, every time. Most professional printers prefer receiving it. A QR code is close to the ideal vector candidate, since it is flat geometry with no gradients or photographic detail to preserve.
If your generator only produces PNG, that is a limit of the generator rather than of the format. Ours exports SVG at no extra cost: [build the code](/) with full styling, then a free account by email or Google releases the vector file.
When raster is required, 300 DPI at final size is the floor
Some workflows insist on a raster file: a print-on-demand template, an office printer driver, a partner's brand kit. 300 DPI is the standard commercial print resolution and it works as the floor for a QR code. Two words in that sentence do the real work: final size.
DPI means nothing without a printed dimension attached to it. A 1200 pixel image is 300 DPI at four inches, 150 DPI at eight inches, and 600 DPI at two. The number you export is pixels. The number that matters is pixels divided by printed inches.
So work backwards. Decide the printed width first, multiply by 300, and export at least that many pixels:
- at 1 inch wide, 300 px minimum
- 1.5 inches needs 450 px
- for 2 inches, 600 px
- a 4 inch code wants 1200 px
- 8 inches means 2400 px
Going above 300 costs nothing except file size, and for small codes it is a good habit. 600 DPI on a one-inch code is a 600 pixel file, which is trivial to handle.
The number underneath the number is module size
DPI is really a proxy. What determines whether a scan succeeds is how many printed pixels each module gets. A module is one small square in the grid, and the code's version sets how many fit across the width: version 1 is 21 modules across, and the scale climbs to 177 modules at version 40.
The arithmetic is short. Take the printed width, divide by the module count, multiply by the DPI.
A one inch code that is 33 modules wide at 300 DPI gives each module about 9 printed pixels. Comfortable. The same code at 100 DPI gives each module roughly 3 pixels. Now every module edge has to land on a third of an ink dot, ink spread rounds the corners, and the scanner's job turns into guesswork.
Around four printed pixels per module is where things begin to smear. Below that, the transitions between light and dark stop being crisp, error correction starts absorbing the damage, and at some point it runs out. Longer content means a higher version, which means more modules across the same physical width, so a code carrying a long URL needs more resolution than a short one at identical dimensions. Good argument for keeping printed URLs short.
Physical dimensions are a separate calculation against scan distance. The size guide handles that properly and those tables live there.
Two things that ruin a file before it reaches the press
Upscaling. Enlarging a 200 pixel PNG to 1200 pixels adds no detail. The interpolation invents soft gray pixels along every module edge, and soft edges are precisely what a scanner struggles with. Need a bigger file? Regenerate the code at the size you need. It takes seconds. Fixing blurry codes walks through the failure modes if you inherited a bad file.
Screenshots. A screenshot of a QR code is the worst possible source and it happens constantly. You get the screen's resolution, typically somewhere between 72 and 144 DPI, plus compression artifacts if it passed through a chat app, plus whatever antialiasing the browser applied while rendering. Three separate quality losses stacked on a file that had none to spare. When somebody sends you a code as a screenshot, ask for the original export. PNG export done correctly covers what a clean raster file looks like.
Color conversion quietly eats your contrast
RGB is additive light. CMYK is subtractive ink. A code designed in a saturated screen blue can convert to a duller, lighter printed blue, and if the light modules carry a tint too, the contrast between them narrows. Scanners need clear separation between light and dark areas, and a conversion that pulls both toward the middle is how a code that passed on screen fails on stock.
Convert to CMYK yourself and inspect the result before the printer does it silently. Then test the converted version on actual paper rather than on a monitor showing a CMYK preview.
Ask for 100% K on small codes
Designers often build black from all four inks, a rich black, because it looks deeper across large areas. On a QR code that is a trap. Four plates have to register perfectly for every module edge to stay sharp, and press registration drifts by fractions of a millimeter. At module sizes near half a millimeter, that drift shows up as colored fringing along each edge.
Specify 100% K, single plate, for the dark modules of any code under roughly two inches. Registration stops mattering when only one plate is involved. Say it to the printer explicitly instead of assuming somebody will catch it.
Quiet zone, bleed, and the trim line
The quiet zone is the blank margin around the code, four modules minimum. It is not decorative; scanners use it to locate the code's boundary. Two ways it gets destroyed at the press:
Placing a code close to a trim edge, so part of the margin gets cut off. Keep the full quiet zone plus your document's safety margin inside the trim line.
Letting a background image or colored panel run into the margin. The quiet zone has to match the light tone of the code's light modules, and a photo or gradient behind it counts as encroachment.
Before signing off a proof, print the file at final size on a plain office printer and scan it with two different phones under normal room lighting. Two minutes, and it catches nearly everything. More prepress checks are in the print guide.
