What you are seeing
This fix makes the code deliver what the material beside it promises. You will check what the link points at, how the server serves it, and what the visitor sees, then change the link or the serving behaviour. If a download is intended, say so beside the code so visitors are not surprised.
Likely causes
1.
Link points straight at a file — Quick test: open the URL in a browser and see whether it downloads.
2.
Server sends a download header — Quick test: check how the same file behaves when opened from a plain link on a page.
3.
File type the phone cannot display — Quick test: try the file on a second phone or in a different browser.
4.
Wrong link copied — Quick test: compare the encoded URL with the intended page address.
5.
Redirect lands on a file — Quick test: follow the redirect chain and note where it ends.
Step-by-step fix
Step 1: Decode the payload and write down the exact URL it contains.
Step 2: Open that URL in a phone browser and confirm whether it downloads or displays.
Step 3: Decide whether the visitor should get a page or a file, and check what the material beside the code promises.
Step 4: If a page is intended, replace the link with the page address and regenerate the code.
Step 5: If a download is intended, confirm the file type is one phones can open, and add a note beside the code that it downloads a file.
Step 6: If the server forces a download where a display was intended, change the serving behaviour or link to a viewer page.
Step 7: Retest the journey on two phones and confirm it delivers what the material promises.
Putting this into practice
In practice, prefer linking to a page that describes the file and offers the download as a choice. That gives visitors context, a chance to confirm, and a way back, instead of a bare download prompt from a code they just scanned. Record the before-and-after behaviour with the job file, so the fix is provable rather than anecdotal. When the same failure appears again, that record tells you whether the old fix held or a new cause appeared.
Common mistakes to avoid
- Linking a code straight at a file while the poster promises a web page.
- Reprinting the full run before a single proof passes, which turns one failure into many.
- Testing on one phone in ideal conditions instead of two phones in the real conditions where a code that downloads a file instead of opening a page will be used.
- Changing the artwork and the placement at the same time, so you cannot tell which change fixed a code that downloads a file instead of opening a page.- Skipping the proof test because the change looked small, when small changes cause most repeat failures.
Quick checklist
- The code delivers what the material beside it promises
- A page link opens a page and a file link is labelled as a download
- The journey passes on two phones
- The corrected proof passes on two phones in the real conditions
- The fix is recorded in the job file so the next reprint starts from a proven setup
- Every printed copy is checked against the approved proof
- The proof is retested after any later change to the link, design, or placement
Related tools and guides
- [QR expiry checker](/qr-expiry-checker)
- [QR redirect chain viewer](/qr-redirect-chain-viewer)
- [QR payload inspector](/qr-payload-inspector)
- [QR scan log](/qr-scan-log)
- [QR safety checker](/qr-safety-checker)
- [PDF QR code generator](/pdf-qr-code-generator)
