How do I test a QR code before printing it?

Not by scanning the preview on the generator's page: that tests the generator, which was never in doubt. Test the thing that will actually leave. Export the file, open the export and scan it from that; print one proof on the real stock and scan the proof from the real reading distance; and follow the scan all the way to the destination in a browser that is not logged in and not on your office wifi. Use two phones, one iPhone and one Android, with their built-in camera apps. If all three stages pass on both phones, print the run.

Is there a QR code checker that tells me if my code will scan?

Online checkers decode an image you upload and tell you what it contains. That is useful for confirming the encoded text, and useless for the question you are asking, because whether a code scans is a property of the printed object, the light and the phone, none of which are in the upload. A checker also cannot see that the quiet zone was cropped in the layout, that the export was a JPEG, or that the destination page 404s. The only checker that answers 'will it scan' is a phone pointed at the proof.

My QR code scans on my screen but not when printed. Why?

Because the screen and the print are different objects, and you tested the wrong one. Between the preview and the paper, the code went through an export (which may have compressed it), a layout (which may have trimmed its margin or recoloured it), a print dialog (which may have scaled it to fit) and a press (which may have spread the ink). Each stage can pass while the next fails. Scan the exported file, then scan the proof; whichever is the first to fail is where the damage happened.

Do I need to test a QR code on more than one phone?

Two is enough, one iPhone and one Android, and it matters more than most people expect. iOS and Android use different decoders with different tolerances for low contrast, inverted colours and styled modules, and the reader's phone will be whichever one you did not test. If the code will be read by dedicated hardware, a door scanner, a till or a warehouse gun, test that too, because it is stricter than either phone and does not upgrade itself.

Guides2026-08-28

How to test a QR code before you print it

Every guide in this cluster ends with 'test it before you print'. Most people do, and most of those tests are worthless, because they scan the preview on the generator's page, and the preview is the one thing in the whole chain that was never going to fail. A test is only as good as its distance from the source. Here is what to scan, from where, on what, and how to read the result.

The five-minute version

Never test the preview. Export first, open the exported file, and scan the code out of that.
Scan it with two phones, one iPhone and one Android, using the built-in camera app, not a special scanner app.
Follow the scan to the end. Tap through and check the page that loads is the right page, on mobile data, in a browser where you are not logged in.
Print one proof on the real stock, scan it from the real distance in the real light, and only then print the run.
If any stage fails, the previous stage tells you where: the last thing that passed is the last thing that was still correct.

Why scanning the preview proves nothing

The code on the generator’s page is rendered by the same program that made it, at whatever size fits your window, in perfect contrast, on a self-lit screen, six inches from a phone you are holding steady. If that scans, you have learned that the generator works. It did. Nobody searching “test qr code” was worried about the generator; they were worried about the five hundred flyers, and the flyers are on the other side of an export, a layout, a print dialog and a press, each of which is a well-documented way to kill a code that was fine a minute earlier.

So the useful test is not “does this code scan” but “does this object scan”, and there are four objects, in order: the preview, the exported file, the proof, and the installed piece. Each one can pass while the next one fails, which is exactly why the order matters. Test them in sequence and a failure points backwards at its own cause.

Stage one: the exported file

Export the artwork the way it will be sent, PDF for print, PNG or SVG for screen, and then open the export, not the design. Zoom until the code is at its real printed size on your monitor, and scan it from the distance the finished piece will be read. This catches the export-time failures: a JPEG that blurred the modules, a fit-to-page that shrank the artwork, a background layer that crept into the quiet zone, a brand colour that looked fine on the canvas and reads grey in the flattened file. The design guide lists all five; this is where you find out whether any of them happened.

If the export passes and the preview passed, the file is correct. Everything that goes wrong from here is physical, and no amount of re-exporting will fix it. That is worth knowing before you spend an afternoon regenerating a code whose only problem is the printer.

Stage two: the proof

Print one. Not on the office printer onto copier paper, unless that is what the run will be; on the real stock, from the real printer or the print shop’s proof, at 100% scale. Then take it to the place it will live, or as close as you can get, and scan it from there: the chair for a table tent, the pavement for a shop-window sign, the doorway for a poster. The size guide gives you the number the code should be; the proof tells you whether the press kept it, whether the ink spread into the modules, whether a gloss laminate is throwing the overhead light straight back at the lens.

If the proof is a sheet of labels, scan three: the first, the last, and one from the middle, because the failure on a sheet is usually alignment drift, and drift is invisible on the first label. The label guide covers why that happens; here the point is only that one label is not a test of a sheet.

Stage three: the destination

A code that decodes is not a code that works. Most testers stop when the phone shows a URL, and the URL is exactly where the remaining failures live. Tap through, every time, and check three things about the page that loads.

It is the right page. Not the homepage the shortener fell back to, not a “this link has expired” interstitial, not a login wall. Open it in a private window so your own cookies cannot hide a wall the reader will hit.
It loads on mobile data. Turn the wifi off before you scan. An internal address, a staging server, a file on the office share, all resolve perfectly on your network and nowhere else, and you will never see the failure from your desk.
It is the page you own. If the URL on the phone is a redirect domain you do not control, the code works today for as long as someone keeps paying. The expiry guide explains how to tell; the test here is just to look at the address bar before the redirect fires.

What to scan with

Two phones: one iPhone, one Android, each using the camera app that came with it. The two platforms use different decoders, and their tolerances for low contrast, inverted colours and rounded modules are not the same; whichever you own, the reader owns the other one. Do not test with a dedicated scanner app, which is usually more forgiving than the camera and tells you your code is fine when half your readers will get nothing. If you know the code will be read by hardware — a door, a till, a warehouse gun — test that hardware, because it is stricter than either phone and never updates itself.

Online “QR code checkers” answer a different question. They decode an uploaded image and show you the text inside. That confirms what you encoded, which is worth one glance, and says nothing about whether the printed object will scan, because the print, the light and the phone are not in the upload. Also note what you are doing: uploading a file that may contain a wifi password or a contact card to a site you have not read the privacy page of. A generator that shows you the decoded contents next to the code gives you the same check without the upload.

Reading a failure

The sequence is the diagnosis. If the preview scans and the export does not, the damage is in the layout or the export settings, and the design guide has the list. If the export scans and the proof does not, the damage is physical: size, ink, contrast, laminate, and the not-scanning guide walks the causes. If the proof scans and the destination is wrong, nothing about the code is at fault and regenerating it will change nothing; fix the page, or the redirect, or the network. Knowing which of the three you have is most of the repair, and it costs one extra scan per stage.

Testing static and dynamic codes

One asymmetry is easy to miss. A static code carries its destination in the pattern, so once it passes all three stages it has passed for good; the only thing that can change is the page at the other end, and that is yours. A dynamic code passes the same test and stays passed only while the redirect service keeps resolving it, which is to say while the subscription is current. The stage-three test is not a one-off for a dynamic code, it is a recurring obligation, and nobody schedules it. That is not an argument in the test procedure; it is an argument for not needing one.

The whole test, in order

Confirm the encoded contents once, in the generator, by reading them, not by scanning the preview.
Export. Open the export. Scan it at real size from the real distance, on both phones.
Tap through. Wifi off, private window. Right page, page you own.
Print one proof on the real stock at 100%. Scan it where it will live. Three from a sheet, not one.
Print the run. Then scan one from the run, because the run is a different print job from the proof, and the press knows that even if you do not.