What you are seeing
This fix removes the warning at its source so visitors reach the page without fear. You will check the certificate, the scheme, the redirects, and the domain reputation, then repair whichever one triggers the warning. Never tell visitors to click through a warning; fix the destination instead.
Likely causes
1.
Certificate missing, expired, or mismatched — Quick test: open the destination in a desktop browser and inspect the certificate details.
2.
Encoded URL uses plain HTTP — Quick test: decode the payload and check whether the scheme is HTTP or HTTPS.
3.
Redirect passes through an insecure hop — Quick test: follow the redirect chain and check the scheme at every hop.
4.
Mixed content on the destination page — Quick test: open the page and look for insecure-content notices in the browser.
5.
Domain flagged by a reputation or blocklist — Quick test: check the domain with a safety checker and compare it with your real domain.
Step-by-step fix
Step 1: Decode the payload and write down the exact URL, including the scheme and domain.
Step 2: If the URL uses HTTP, change it to HTTPS and regenerate the code.
Step 3: Open the destination in a desktop browser and inspect the certificate: valid, unexpired, and matching the domain.
Step 4: Renew or replace the certificate if it is expired or mismatched, then retest.
Step 5: Follow the redirect chain and make every hop HTTPS, with no insecure hop in the middle.
Step 6: Fix mixed content on the page so every script, image, and frame loads over HTTPS.
Step 7: Retest the corrected code on two phones and confirm the page opens with no warning.
Putting this into practice
In practice, never ask visitors to click through a security warning. Every click-through teaches them to ignore the warning that protects them, and most will simply leave instead. Fix the destination so no warning appears. 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
- Telling visitors to ignore or click through a security warning instead of fixing the destination.
- 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 shows a security warning will be used.
- Changing the artwork and the placement at the same time, so you cannot tell which change fixed a code that shows a security warning.- Skipping the proof test because the change looked small, when small changes cause most repeat failures.
Quick checklist
- The encoded URL uses HTTPS and the correct domain
- The certificate is valid, unexpired, and matches the domain
- Every redirect hop uses HTTPS and the page shows no warning
- 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 safety checker](/qr-safety-checker)
- [QR typosquat checker](/qr-typosquat-checker)
- [QR phishing pattern trainer](/qr-phishing-pattern-trainer)
- [QR allowlist builder](/qr-allowlist-builder)
- [QR tamper evidence planner](/qr-tamper-evidence-planner)
- [QR scan log](/qr-scan-log)
