Why your QR code won't scan: a troubleshooting guide

First, describe what fails

It won't scan can mean that the camera sees no code, that a preview appears but is not opened, or that a website fails after recognition. Those are different problems. Ask the person testing what appeared on the screen and at which step they stopped. Record the device, whether they used a screen or a printed sample, and whether the failure repeats. Avoid collecting private editing URLs or account details in the troubleshooting notes.

Try the same public QR URL directly in the phone's browser if you know it safely. If the URL works but the camera cannot recognize the print, concentrate on the image and its surroundings. If the typed URL fails too, investigate the web journey. For a code whose destination seems suspicious, stop troubleshooting toward a successful visit and use the quishing guidance instead.

No link appears in the camera

Clean the lens, hold the phone steadily and allow it to focus. Frame the whole code with its surrounding border rather than filling the camera view with only the central pattern. Change distance gradually instead of assuming closer is always better. Check whether the particular camera or trusted reader supports QR recognition and whether that feature is enabled. Use the device maker's instructions rather than following an invented menu path for every phone.

Compare devices and samples. If several phones recognize the downloaded original on a screen but none recognize the printed copy, inspect the production chain. A messaging-app screenshot, stretched image, cropped margin or blurred export can be different from the original download. If only one device has trouble with both screen and print, check that device's settings and try an appropriate built-in or otherwise trusted reader before redesigning all the artwork.

The print looks fine, but the placement is working against it

Look for glare on a glossy cover, shadows, creases, a curved surface or nearby graphics entering the clear border. Move the same sample to a flat, evenly lit position without changing the file. If that helps, the physical presentation needs attention. Remove an unnecessary protective layer for comparison only if it is your own sample and safe to handle; do not alter someone else's sign or equipment while investigating.

Then compare a larger proof of the same code, preserving its proportions and quiet zone. Do not enlarge a small screenshot until its edges blur and call that a valid test. Use the original export. The size and quiet-zone guide explains the complete footprint, and the printing checklist helps you reproduce the actual viewing distance, finish and lighting before another production run.

A preview appears, but the visitor stops there

Some scanning experiences show a preview or prompt before opening a URL. That is a useful opportunity to inspect the destination, not necessarily a failure. Tell the tester what to expect from their actual device without encouraging them to dismiss security warnings. If the surrounding label promises a menu but the preview or next page suggests an unrelated organization, verify the code with the publisher through an independent channel.

If your own design gives people no clue what the code does, improve the label and offer an alternative address. Do not solve uncertainty by hiding the destination behind more instructions or by requiring a special app when a normal web page would meet the task. Camera recognition is only one part of usable navigation; a person should be able to decide whether opening the link is appropriate.

The QRSwivo page says paused, deleted or unavailable

Those messages mean the code has been recognized well enough to request its public URL. A paused record needs its owner to save a valid destination and resume it. A deleted identifier is reserved and cannot be reassigned. An unavailable or blocked destination requires review, not a print adjustment. Check that the public identifier matches the code you intend to manage; a similar-looking filename is not proof that two images encode the same URL.

Use the saved private management link or the owning account. The public QR image does not provide editing authority. If a guest code was claimed, its old guest credential is revoked and the owner account is required. Follow the destination-update guide for a controlled edit. Do not create a replacement code unless you are prepared to replace every physical and digital copy of the original.

The final website fails after a successful redirect

Try the destination directly and compare a second network if practical. A private document, expired event page, removed PDF or incorrect branch URL can be a valid-looking address that does not serve the intended audience. Test without the organizer's logged-in session. An editor may see a file because they own it while a guest sees an access request. Updating QRSwivo cannot grant permissions on that external service.

An old browser tab is another frequent source of confusion. A destination change affects a fresh visit through the QR public URL; it does not navigate a tab already sitting at the previous website. Scan the original code again or open the public URL in a fresh tab. If the final website has its own caching, routing or availability problem, investigate that website separately rather than assuming QRSwivo has cached a permanent redirect.

Keep a useful handover note

A concise failure record lets the next person continue where you stopped. Include the public URL, sample dimensions, material, device, network, visible error and which comparison changed the result. Separate camera-recognition observations from browser or account errors. Keep an unmodified original export and the physical proof if possible. A fresh generator test can provide a control, but it should not quietly replace the live code while people are still using it.

• Does the camera recognize the full code and show a plausible URL?
• Does that public URL work when opened directly?
• Is the record active, and does the owner still have valid access?
• Does the destination work for a guest on an ordinary mobile connection?
• Which one-factor comparison changed the outcome, and what still needs verification?