QR Code Scanner and a URL: Reading the Address Before Opening It

Published 2026-08-19 · Updated 2026-08-19

When a QR code decodes to a URL, a scanner is reading a text string with the structure defined by RFC 3986: a scheme, an authority such as a domain, and a path. A trustworthy scanner shows that full string before opening it. Read the domain specifically — a long or unfamiliar path after a legitimate-looking domain is a different risk than an unfamiliar domain itself.

What a decoded URL actually looks like, piece by piece

Take the string https://example.org/menu?table=12 as a decoded result. RFC 3986 defines the generic structure every URL follows: a scheme (https), an authority that includes the domain (example.org), a path (/menu), and an optional query (?table=12). The domain is the piece that identifies who actually controls the destination; the path and query describe which specific page and parameters are requested once that destination is reached, and confusing the two is where a quick read of a decoded address tends to go wrong. A userinfo component and a port number can also appear before or after the domain in the full grammar RFC 3986 defines, though a QR code encoding a public web address rarely includes either; seeing an unexpected @ symbol or a colon followed by digits sitting inside what should be a simple domain is itself worth a second look, since that placement is unusual for an ordinary site link.

The difference between opening and previewing

A scanner that displays the full decoded string on screen before opening it gives a person one chance to read it before anything loads; a scanner that jumps straight into a browser the moment recognition succeeds removes that chance entirely. This single design choice, not the underlying decoding accuracy, is the main practical difference in how safely two scanners can be used, and it is worth checking which behaviour a particular app or camera setting actually follows before relying on it for an unfamiliar code. Most current phone camera implementations default to the safer, preview-first behaviour, but a downloaded third-party app is not guaranteed to match that default, and testing a known, harmless URL with any new scanning app before trusting it with an unfamiliar one is a cheap way to confirm which behaviour it actually follows.

Worked example: two decoded strings that look similar at a glance

Compare https://mybank-secure-login.example-payments.net/verify against https://mybank.com/login. The first has an unfamiliar domain, example-payments.net, dressed up with a misleading subdomain-style prefix that reads like the bank's name at first glance; the second shows the bank's actual domain directly. Finding the real domain means locating the authority component — the segment between the double slash after the scheme and the next single slash — rather than reading left to right and stopping at the first bank-sounding word. A second pair worth comparing side by side: https://example.org.mybank-alerts.com/update and https://example.org/mybank-alerts — the first has example.org sitting inside a longer domain actually owned by mybank-alerts.com, while the second genuinely belongs to example.org with mybank-alerts only as a path segment; the position of the first single slash after the authority is what separates these two very differently owned addresses.

Redirects: why the decoded address isn't always the final one

A QR code can point to a short link or an internal marketing redirect service that itself forwards the browser to a different final address once opened. The scanner only ever decoded and displayed that first hop, not wherever a server-side redirect sends it afterward. Opening the link in a way that shows the address bar update as it loads, rather than inside an embedded webview within a messaging app that hides that bar, reveals the actual final destination a static decode alone cannot show. A short link used on a printed poster for a one-month campaign is not inherently unsafe, and shortening services have legitimate reasons to exist — compact printing, click tracking, easier verbal sharing — but a shortened address is exactly the case where checking the destination after it loads matters more than usual, since the decoded string alone gives no information about where it actually leads.

What counts as a QR code encoding something other than a URL

QR codes also carry plain text, Wi-Fi network credentials, contact cards, and other structured data using their own recognised prefixes, such as WIFI: or MECARD:, rather than a web address at all. A scanner that recognises those prefixes should present the result differently from a web link, because joining a network and opening a website are different actions carrying different risks; this site's format-selector tool explains how those structures differ from a plain URL payload. A WIFI: payload, for instance, can carry a network password in plain sight of anyone who photographs the code, which is a materially different exposure than a URL that merely opens a public web page, and a scanner that flattens both into the same generic 'here's your result' screen makes that difference harder for a person to notice in the moment.

Mistakes people make reading a decoded address quickly

Treating a padlock icon or the letters 'https' alone as proof of legitimacy is a common error, since https only confirms an encrypted connection to whichever domain was decoded, saying nothing about whether that domain is the real, intended one. A second mistake is skimming only the first several characters of a long domain rather than locating exactly where the domain name ends, right before the first single slash, which is the part that actually identifies the destination's owner. A third mistake is judging a domain by whether it merely contains a familiar word anywhere in the string, when what actually matters is which organisation registered that exact domain — a familiar brand name appearing as a subdomain of an unrelated, unfamiliar domain is a common disguise precisely because the familiar word is still technically present, just not in the position that would make it meaningful.

Testing a URL QR code you created yourself

For someone generating rather than receiving a code, decoding the finished export and comparing the resulting string character by character against the address that was originally typed catches a copy-paste error, a dropped character, or an autocorrect change before the artwork is printed. This site's URL encoder and its independent decode page are built for exactly that pairing — create, then verify with a separate tool rather than trusting the same screen that generated it. For a batch of several URL codes generated for one campaign — say a dozen table cards each pointing to a different product page — checking each decoded result against a written list of the intended addresses, rather than eyeballing each printed square individually, is the more reliable way to catch the one card that was accidentally paired with the wrong page before the whole batch goes to print.

Reading the address correctly answers one question, not every question

Correctly identifying where a decoded code leads tells you the destination, not whether that destination remains trustworthy today or will stay that way after the linked page is later changed by whoever controls it. A legitimate, correctly identified domain can still be compromised after the fact, and a genuinely safe link at the moment it was printed can point somewhere different months later — judging that separate, ongoing question is covered in this site's guide to QR code safety and quishing. Reading the structure correctly is the skill that transfers to every code you will ever scan; judging a specific destination's trustworthiness on a given day is a separate, situational judgement that structure alone cannot make for you. RFC 3986: Uniform Resource Identifier (URI): Generic Syntax is the named source for the current external rule or product behaviour.