How to read a QR redirect chain without being fooled
A QR code rarely points at a final page directly. Marketing links pass through redirect services, tracking domains, and campaign routers before landing somewhere. Each hop is a chance for the destination to change, and the address bar a scanner shows you is only the first hop, not the last. The discipline is to treat the first URL as a claim and verify where it actually leads before trusting it with anything valuable, especially a password or payment details.
Start with the static structure, because it never lies about itself. Read the host from the right: in shop.example.com the registrable domain is example.com, and everything to its left is a subdomain the owner controls. A host such as example.com.attacker.com is attacker.com, not example.com, no matter how convincing the left-hand part looks. Check the scheme — a login or payment page served over plain HTTP is a stop sign. Look for credentials embedded before an @ sign, for raw IP addresses instead of domain names, and for punycode that can make a lookalike domain render like a familiar brand. None of these alone proves harm, but each one raises the bar for what you should believe next.
Next, consider what a browser can and cannot tell you. When a page on one origin fetches a URL on another, the destination may refuse to be read — cross-origin resource sharing rules are designed to stop exactly that. A failed fetch therefore proves nothing about whether the site is alive, dead, or dangerous. What a browser fetch can tell you is the final URL after redirects and whether a redirect was reported at all. That is useful but incomplete: the intermediate hops stay hidden from web pages by design, which is why this tool is explicit about its limits instead of inventing a chain.
For a full chain, use a tool that is allowed to see it. From a terminal, a request with redirect-following and header output shows each hop, each status code, and each Location header in order. Watch for hops that cross from a trusted domain to an unrelated one, hops that downgrade HTTPS to HTTP, and chains that bounce through several unrelated tracking domains before landing. A short chain that stays on one organisation's domains is ordinary. A long chain that ends somewhere unexpected is reason to stop.
The practical rule is simple: never authenticate through a chain you did not expect. If a QR code in a restaurant, poster, or email promises your bank, your inbox, or your payment provider, type the address yourself or use a bookmark instead of following the chain. And if you publish QR codes, keep your own chains short, keep them on domains you own, and check them on a schedule — because a redirect you set up two years ago may now point somewhere you no longer control.