QR Code Resolution: How Many Pixels and How Much DPI a QR Code Actually Needs

Key points

• For print, a QR code needs 300 DPI at its final printed size. The pixel width is centimetres ÷ 2.54 × 300, so a 5 cm code needs about 591 pixels and a 20 cm code needs about 2,362 pixels.
• A vector file - SVG, PDF or EPS - has no resolution at all. It stores the code as geometry, so the same file prints at 2 cm or 2 m without softening.
• Resolution does not make a QR code scannable. Physical size and contrast do. Resolution only decides whether the module edges stay hard instead of turning grey.
• A raster QR code prints cleanly up to roughly pixel width ÷ 300 × 2.54 centimetres. A 1024 × 1024 PNG reaches about 8.7 cm; beyond that the edges soften.
• Never save a QR code as JPEG. JPEG compression adds ringing artefacts around exactly the kind of hard black-and-white edges a QR code is made of.

What resolution should a QR code be?

That formula covers raster files. A vector QR code has no pixel dimension to choose, because SVG, PDF and EPS store the code as shapes rather than as a grid of pixels. If the code is going to print, exporting vector removes the resolution question entirely, and it is the reason print shops ask for vector artwork.

The number that trips people up is DPI written into the file. A PNG carries a DPI tag in its metadata, but that tag does not change a single pixel. What matters is the effective resolution: the pixel width divided by the size the code is actually placed at in the layout. A 600-pixel code placed at 10 cm in InDesign is a 152 DPI code, whatever its metadata claims.

Resolution and size are different problems, and only one of them makes a code scan

Physical size decides whether a QR code can be scanned. Resolution decides whether the printed edges are crisp. A 1 cm code exported at 4,000 pixels still fails at arm's length, and a 20 cm code exported at 400 pixels scans fine from three metres despite visibly soft edges.

A phone camera decodes a QR code by resolving individual modules - the small black and white squares that carry the data. As a rule of thumb, the camera needs roughly two to three of its own pixels per module in the captured image, which is why distance and physical size dominate. Print resolution only affects how sharply each module boundary is reproduced on paper.

The practical consequence: fix size first, then resolution. A printed QR code needs about 1 cm of width for every 10 cm of scanning distance, with 2 × 2 cm as the working floor for close reading. Once the physical size is settled, the pixel count follows from the formula, and not the other way round.

The print formula, in both directions

At 300 DPI, one pixel is 0.0847 mm. To go from a printed size to a pixel count, multiply centimetres by 118.1. To go the other way, divide the pixel width by 118.1.

Going above 300 DPI rarely changes the printed result for a QR code. A QR code has no fine gradients or hairlines - it is a grid of solid blocks - so 600 DPI mainly produces a heavier file. The exception is a very small code, under about 1.5 cm, where doubling the resolution keeps the few pixels that form each module edge from rounding unevenly.

Include the quiet zone in the measurement. The quiet zone is the empty margin around a QR code that lets a scanner detect where the symbol begins and ends, and the standard specifies four modules on every side. If the 5 cm in a layout means the black artwork only, the true footprint is larger, and the pixel count has to cover the whole footprint.

How large can you print a PNG you already have?

A raster QR code prints cleanly up to roughly pixel width ÷ 300 × 2.54 centimetres. Past that point, each module edge is being reproduced by fewer than the dots the printer would like, and the black-to-white transition starts to spread.

This ceiling is the reason free-plan resolution caps on hosted QR platforms matter. A tool that exports a maximum of 1024 × 1024 pixels is a tool that stops at roughly A6-postcard scale for print work, regardless of what the code itself contains.

Soft edges do not fail gracefully in one visible step. A code with spread edges usually still scans on a clean white sheet under good light, then stops working on absorbent stock, in dim light, or at an angle - which is exactly the situation the printed run will meet.

Module size is the real minimum, and it is measured in millimetres

The smallest safe unit in a printed QR code is the module, not the pixel. As a rule of thumb, keep printed modules at 0.4 mm or larger for close scanning with a phone, and at 0.5 mm or larger on absorbent stock such as uncoated paper, cardboard or a receipt, where ink spread thickens the dark modules.

Module count depends on the symbol version, which is set by how much data the code carries. Version 1 is 21 × 21 modules, and each step adds four modules per side, up to version 40 at 177 × 177. More characters in the URL means a higher version, which means smaller modules at the same printed size.

The 2 cm minimum quoted for printed QR codes is this arithmetic, not a convention. A short URL with medium error correction lands around version 3 or 4, and a version 4 symbol at 0.5 mm modules is 20.5 mm wide including its quiet zone. Shorten the URL and the symbol drops a version or two, which buys back real millimetres at the same printed size.

Export a whole number of pixels per module

Divide the export width by the module count including the quiet zone. If the result is not a whole number, some modules will be rendered one pixel wider than others and every module edge will pick up a grey anti-aliased fringe. Choosing an export width that divides evenly removes both problems.

A worked example: a version 3 code is 37 modules wide including its quiet zone. Exporting at 591 pixels - the exact figure for 5 cm at 300 DPI - gives 15.97 pixels per module. Exporting at 592 pixels instead gives exactly 16, every module is identical, and the printed size changes by a third of a millimetre.

Grey fringes matter because scanners binarise the image before decoding: every pixel is forced to black or white against a threshold. A hard edge lands on the same side of that threshold under any lighting. A soft grey edge shifts sides as the light changes, which moves the apparent module boundary and eats into the decoder's margin for error.

This is a raster-only concern. A vector export has no pixel grid, so the module edges are mathematically exact at every size and the question does not arise.

Which file format to export

Choose vector whenever the code will be printed, and raster whenever it will be shown on a screen. That single rule resolves most resolution problems before they start, because the print side is where resolution ceilings cause damage and the screen side is where a fixed pixel size is what the medium wants anyway.

JPEG deserves the hard rule. JPEG compresses by discarding high-frequency detail, and a QR code is almost entirely high-frequency detail: thousands of abrupt black-to-white transitions. The result is faint ringing around every module, which survives into print and reduces contrast exactly where the decoder measures it. KoloQR, a free QR code generator with circular and custom-shaped QR codes, exports SVG and PNG for this reason and does not offer JPEG at all.

Watch out for transparent backgrounds in PNG exports. A transparent quiet zone is not a white quiet zone: dropped onto a dark or patterned background, the margin disappears and the scanner loses the boundary of the symbol. Export on solid white unless the layout genuinely places the code on a light, flat surface.

Resolution for screens, slides and video

On a screen, aim for at least 4 CSS pixels per module and export at twice that for high-density displays. For a version 3 code at 37 modules including the quiet zone, that is roughly 150 CSS pixels displayed, exported at 300 pixels so it stays sharp on a 2× device.

• Website and email: 300–600 px PNG, displayed at 150–300 px. Anything smaller starts to lose module definition on standard-density screens.
• Presentation slides: size the code for the room, not the slide. A code read from ten metres away needs about 1 metre of projected width by the distance rule, which is usually impractical - put the URL on the slide as well.
• Video and broadcast: the code has to survive the stream's compression and stay on screen long enough to be scanned. Keep it large, keep it static for at least eight to ten seconds, and expect motion-compensated compression to soften it.
• Screen-to-screen scanning: a code shown on a phone and scanned by another phone works, but glare and refresh-rate banding cause more failures than resolution does. Raise the display brightness first.

Resolution for thermal printers, engraving and embroidery

Match the module size to the device's dot pitch instead of picking a DPI. A thermal receipt printer typically prints at 203 DPI, where one dot is 0.125 mm, so a module of exactly 4 dots is 0.5 mm and every module lands on a whole number of dots. Three dots gives 0.375 mm, which is below the practical floor on receipt paper.

Receipt paper is the harshest common substrate for QR codes. It is absorbent, low-contrast, thermally uneven, and it fades. Keep receipt codes at 2 cm or larger, use the shortest possible URL so the symbol version stays low, and print a plain text URL underneath - a faded code with no fallback is a dead end for the customer.

For laser engraving, dot-peen marking and embroidery, the constraint is the marking head, not DPI. Send vector artwork, confirm the minimum feature size the machine can hold, and keep the module at or above it with margin. Engraved and stitched codes also lose contrast rather than sharpness, so test a physical sample under the light the code will actually be read in.

Large-format printing: when 300 DPI is a waste

Large-format printers usually work at 100–150 DPI because the output is read from a distance, and QR codes follow the same logic. A 60 cm code exported at 300 DPI is a 7,087-pixel file that no banner printer will reproduce at that fidelity, while the same code at 150 DPI is 3,543 pixels and prints identically.

Send vector for anything above roughly 30 cm. At that scale the raster file becomes large enough to be awkward, and a print shop will usually ask for SVG, PDF or EPS anyway. Vector also survives the rescaling that happens when a banner size changes late in production, which raster artwork does not.

Size a large code for the closest realistic scanning position, not the furthest. People walk up to a poster. A code sized for a three-metre read still scans at one metre, but a code sized for one metre cannot be read from three, so the closer figure is the safe error.

Why a printed QR code looks blurry - and which causes actually break scanning

The last row is the important one. Most QR codes that fail in the field are perfectly sharp. They are too small for the distance, printed in a colour pair without enough contrast, or laid out with the quiet zone cropped away by a designer who needed the space. Resolution is the visible problem and rarely the actual one.

Colour separation is a related trap that no amount of resolution fixes. A dark code printed in a rich black or a spot colour that registers slightly off will pick up coloured fringes at the module edges in CMYK. Use a single flat dark colour and keep the background genuinely light.

Can you enlarge a QR code you already have?

Regenerate it rather than enlarging it. Upscaling a raster QR code interpolates new pixels from existing ones, which turns hard module edges into gradients - the exact defect that lowers scanning margin. The original data is gone and no filter recovers it.

Two rules cover the cases in practice:

• If you can regenerate the code, do that and export vector. Regenerating takes less time than any repair, and the result has no ceiling. In KoloQR the SVG export is free and carries no watermark, so there is nothing to weigh up.
• If you cannot regenerate it - the code came from a client, a supplier or an old print file - upscale by a whole-number factor with nearest-neighbour interpolation, never bicubic or "smart" AI upscaling. Nearest-neighbour at 2× or 4× duplicates pixels and keeps the edges hard; smoothing algorithms blur them and can invent detail that was never in the symbol.

Vectorising an existing code by hand is the last resort and it is more reliable than it sounds, because a QR code is a grid of identical squares. Trace it at integer scale, verify that the module grid is uniform, and scan the result on both an iPhone and an Android phone before it goes anywhere near a print run.

Decoding the old code and rebuilding it from the URL is better than either. Scan the existing code, read out the destination, and generate a fresh symbol from that string - the new code is mathematically clean and you have also verified where the old one actually points, which is worth knowing before reprinting it.

Pre-print resolution checklist

1. Set the physical size. Decide the physical size from the scanning distance - about 1 cm of code width per 10 cm of distance, and never below 2 cm.
2. Check the module size. Printed width ÷ modules including quiet zone. Aim for 0.4 mm or more, 0.5 mm on uncoated stock.
3. Choose the format. Export vector for print, raster for screens.
4. Calculate the pixels. If exporting raster, calculate the pixels: cm ÷ 2.54 × 300, then round up to a whole number of pixels per module.
5. Confirm the effective DPI. Check it in the layout file, not the DPI tag in the image metadata.
6. Verify the quiet zone survived the layout. Four modules of clear space on all four sides.
7. Check the file format. Confirm the file is PNG or vector, never JPEG, and that nothing in the workflow re-saved it as JPEG.
8. Print and scan a proof. Print one proof at final size on the real stock, and scan it with an iPhone and an Android phone in the lighting where the code will live.

The last step is the one that catches what the arithmetic misses. Ink spread, lamination gloss, substrate colour and ambient light are all invisible on screen and all decide whether the code works in the room.