The ASCII-compatible encoding (RFC 3492) that represents non-Latin domain names — the xn-- labels behind internationalized domains — critical for spotting homograph phishing in QR URLs.
Punycode is the encoding defined by RFC 3492 that represents Unicode domain names using only ASCII characters, producing the distinctive xn-- labels you see in internationalized URLs. The German domain münchen.de becomes xn--mnchen-3ya.de under the hood; the DNS system, which only understands ASCII, resolves the punycode form while browsers display the Unicode form to users. Every non-Latin domain on the internet — Arabic, Chinese, Cyrillic, Urdu — reaches you via punycode.
Why QR security cares about punycode
QR codes hide their destinations, and internationalized domain names hide in plain sight. The homograph attack exploits Unicode lookalikes: a phishing domain like "аpple.com" with a Cyrillic 'а' renders almost identically to "apple.com" with a Latin 'a' in most fonts, but resolves to the attacker's server. In punycode the deception is visible — xn--pple-43d.com is obviously not apple.com — which is why security-conscious QR scanners display the punycode or ASCII form of URLs rather than the pretty Unicode rendering. If your scanner shows you xn-- labels, that is a feature, not a bug.
How the encoding works
Punycode compresses a Unicode string into ASCII by separating the basic (ASCII) characters, which pass through unchanged, from the non-basic characters, which are encoded as deltas from insertion positions using a variable-length integer scheme with bias adaptation. The result is prefixed with xn-- (the ACE prefix for IDNA) and is case-insensitive. The algorithm is deterministic and compact for the common case — a domain that is mostly ASCII with a few non-Latin characters encodes nearly as short as the ASCII original — which matters when the URL must fit in a QR payload budget.
IDNA and the display rules
Punycode is the codec; IDNA (Internationalized Domain Names in Applications) is the framework governing when and how it is used. Modern browsers apply IDNA2008 with contextual rules and often refuse to display Unicode for mixed-script domains that look like homograph attacks, falling back to punycode display. QR scanner apps should follow the same principle: decode the URL from the code, convert any internationalized domain to its ASCII/punycode form for the confirmation screen, and let the user see what the DNS will actually resolve.
Guidance for QR publishers
If your brand uses a non-Latin domain, be aware that security-aware users and scanners will see the xn-- form — consider also maintaining an ASCII domain for QR-encoded links to avoid confusion and homograph suspicion. Never mix scripts within a single domain label in QR destinations; it triggers homograph heuristics in browsers and scanners alike. And when reviewing QR safety reports, read the punycode: the ASCII form is the ground truth of where the code actually goes.
Diagram description: A homograph attack visualized: “аpple.com” (Cyrillic a) versus “apple.com” (Latin a) rendered identically, with their punycode forms xn--pple-43d.com and apple.com shown below revealing the difference.