What you are seeing
The code scans, but instead of opening a web page the phone starts downloading a file. The visitor expected a page and got a download prompt, which feels wrong and often gets cancelled. The cause is usually the destination: the link points straight at a file, the server serves the file as a download, or the page address is actually a file address. The fix is to decide what the visitor should get, a page or a file, and to make the link and the server behaviour match that promise.
Likely causes
1.
Link points straight at a file — A link to a document or media file, rather than to a page that contains it, triggers a download in many phone browsers. Test: open the URL in a browser and see whether it downloads.
2.
Server sends a download header — A server can be configured to send a file as a download even when a browser could display it. Test: check how the same file behaves when opened from a plain link on a web page.
3.
File type the phone cannot display — Some file types have no in-browser viewer on a phone, so the phone falls back to downloading them. Test: try the file on a second phone or in a different browser.
4.
Wrong link copied — A download link copied from a file manager or a sharing dialogue can replace the intended page link. Test: compare the encoded URL with the intended page address.
5.
Redirect lands on a file — A redirect rule or shortener can send visitors to a file instead of the page. Test: follow the redirect chain and note where it ends.
Step-by-step fix
1. Decode the payload and write down the exact URL it contains.
2. Open that URL in a phone browser and confirm the download behaviour.
3. Decide whether the visitor should get a page or a file.
4. If a page is intended, point the code at the page that contains or describes the file.
5. If a download is intended, keep the file link and say so beside the code.
6. Retest the journey on two phones and confirm it matches the promise.
Putting this into practice
In practice, the surprise is the problem more than the download itself. Visitors who expect a page and get a download feel tricked, while visitors who were told to expect a file accept it. Match the link to the promise, and put the promise in words beside the code. Keep a short note of what you tested, what failed, and what you changed, so the next person starts from evidence rather than guesswork. A fix that is written down survives staff changes and reprints; a fix that lives only in memory gets repeated.
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)
