Homoglyph Detector

What This Tool Does

This tool scans an input string for homoglyphs — characters that share an indistinguishable visual form with ASCII letters but live at entirely different Unicode codepoints. The classic case substitutes the Cyrillic small letter a (U+0430) for the Latin small letter a (U+0061): both render as a in every common font, yet they are different characters with different bytes on the wire. A URL like аpple.com built from a single Cyrillic a renders identically to the legitimate apple.com but resolves to xn--pple-43d.com in Punycode — an entirely different domain that an attacker controls.

The detector covers the highest-risk confusable pairs from Cyrillic, Greek, Armenian, Latin small script variants, and a handful of look-alike symbol blocks. Every flagged character is reported with its full codepoint (in U+XXXX form), the source script, and the Latin codepoint it impersonates. The tool runs in three modes: Detect highlights confusables in a pasted string, Generate takes ASCII input and produces a homoglyph-encoded variant for authorized security testing, and Compare performs a column-by-column codepoint diff between two strings to surface hidden differences. All processing happens in your browser — no text is uploaded, stored, or logged. 🔒

How to Use It

The interface defaults to Detect mode. Paste a suspected URL, email address, or block of text into the input area. Suspicious characters are highlighted with a yellow background and an underline immediately; below the highlighted text, a table appears listing every flagged character along with its codepoint, source script, and the Latin character it impersonates.

Detect Mode

Type or paste the text you want to scan. Detection runs live with a 200-millisecond debounce — there's no Submit button. Each confusable character is wrapped in a yellow span, and the table below shows the actual codepoint (e.g. U+0430 CYRILLIC SMALL LETTER A), the source script label (Cyrillic а), and the Latin equivalent (Looks like "a" (U+0061)). Hovering a highlighted character also shows the same info as a tooltip. The status bar at the bottom reads No confusable characters detected. Text appears safe. in green when clean, or switches to red with a count when matches are found.

Generate Mode

Switch to Generate mode to produce a homoglyph-encoded version of an ASCII string — useful for authorized security testing, phishing simulation exercises, or building test fixtures for code that should detect homoglyph attacks. Type ASCII text on the left, and the tool substitutes each replaceable character with its first available confusable on the right. Use the Copy button to grab the result. Do not deploy generated strings in production-impersonating contexts without explicit authorization.

Compare Mode

Compare mode takes two short strings and produces a position-by-position diff table. Each row shows the character at that index in each string, both codepoints in U+XXXX form, and a verdict: SAME if the codepoints match, HOMOGLYPH if they differ but one is a known confusable for the other, or DIFFER for any other mismatch. This is the fastest way to confirm whether two visually identical strings are actually equal at the byte level — a common need when investigating a suspect email or comparing a copied URL against a trusted source.

How Many Confusable Pairs Each Script Contributes

Not all scripts are equally dangerous as homoglyph sources. The Unicode Consortium's confusables.txt file (current as of UCD 15.1) enumerates thousands of single-character confusable mappings against the Latin script. The chart below shows approximate confusable pair counts contributed by each major source script — these are the codepoints that map to Latin lowercase or uppercase letters in the standard skeleton normalization.

Raw count is not the right measure of risk. The Mathematical Alphanumeric Symbols block dominates the absolute count because every Latin letter has a styled twin in each of bold, italic, bold-italic, script, fraktur, double-struck, and sans-serif variants, plus uppercase versions of each — well over a thousand codepoints. In practice, these styled forms are rarely rendered without their distinguishing style (a math-italic 𝑎 reads visibly differently from a regular a in most fonts), so they pose less phishing risk per pair. Cyrillic and Greek lowercase letters are the highest operational risk because their default rendering is indistinguishable from Latin in nearly every standard font.

Common Use Cases

Phishing Email Detection

The single most common homoglyph deployment is in phishing campaigns that need to defeat URL-scanning gateways and human vigilance simultaneously. Attackers register a domain that visually mirrors a brand — раypal.com with Cyrillic р in place of Latin p — and send mail using that domain as the From address and as link text in the body. A user who copies the link, pastes it into this tool, and looks at the highlighted character map sees immediately that the sending domain is not the brand it claims to be. Security teams use the tool the same way during incident response, pasting suspect senders from quarantine queues to confirm the script-mixing fingerprint before escalating.

Suspicious Domain Analysis for Threat Intelligence

Threat intelligence analysts working through newly-registered domain feeds (NRDs) routinely encounter strings that look like legitimate brand names. Pasting the Punycode form into this tool's Compare mode against the legitimate brand reveals exactly which characters differ and which script the homoglyph came from — a useful provenance signal because certain attack groups have known script preferences. Cyrillic-heavy substitutions correlate with Russian-speaking actors using familiar input methods; Math Alphanumeric substitutions often indicate automated kits generating large domain inventories.

Code Review and Supply-Chain Defense

The Trojan Source attack class published by Boucher and Anderson in 2021 demonstrated that homoglyph identifiers and bidirectional control characters can hide malicious changes inside otherwise-clean-looking source files. A variable named uѕer (Cyrillic s) compares not-equal to user at the language level, so an attacker can declare a shadow variable that passes code review and diverges at runtime. Pasting a suspicious diff into Detect mode immediately highlights any non-ASCII characters in identifiers — pair it with the Unicode Inspector to drill into the underlying codepoints.

Trademark and Brand Research

Trademark attorneys and brand-protection teams use homoglyph analysis to identify domain squatters and counterfeit-product listings before they become operationally significant. The Compare mode is particularly useful here: paste the brand name and a suspect domain side-by-side and the position-by-position diff produces clean evidence suitable for a UDRP or URS filing. The combination of glyph-identical visual form plus byte-different underlying codepoints is exactly the pattern that arbitration panels recognize as bad-faith confusable registration.

Social Engineering Defense Training

Security awareness teams use Generate mode to produce realistic homoglyph training material — a phishing-simulation email that uses a Cyrillic-a domain pushes employees to read URLs character-by-character rather than accept the visual form as ground truth. Always pair generated training material with an authorized use policy. Generating homoglyph variants of third-party brands for unauthorized distribution may violate computer-misuse laws in your jurisdiction.

Edge Cases and Limitations

Homoglyph defense is a layered problem with several adjacent concerns that this tool intentionally treats differently. Knowing where the lines fall avoids both false confidence and false alarms.

Confusables vs. Full Homoglyphs

A homoglyph in the strict sense is a character whose glyph is rendered identically to another character by the font. A confusable is the broader UTS #39 term covering any pair that's likely to be visually mistaken — including cases where the glyphs are similar but not pixel-identical. The detector here treats both categories together because the operational distinction is rarely useful at security-decision time; a confusable that is 95% visually identical produces the same phishing outcome as one that's 100% identical. UTS #39 includes mapping for both classes in confusables.txt.

Digit-Letter Confusables (1 vs l vs I)

The Latin digit one (1 U+0031), the Latin small letter L (l U+006C), and the Latin capital I (I U+0049) are all ASCII characters that frequently confuse readers in sans-serif fonts. These aren't strictly homoglyphs — there's no cross-script substitution involved — but they create exactly the same phishing outcome (g00gle.com, paypa1.com, microsoft1.com). The detector does not flag these because doing so would generate constant false positives on legitimate ASCII text. Pair the homoglyph scan with a typosquat-aware DNS check for full coverage.

Mathematical Alphanumeric Symbols (U+1D400+)

The Mathematical Alphanumeric Symbols block at U+1D400 through U+1D7FF contains bold, italic, bold-italic, script, fraktur, double-struck, sans-serif, and monospace variants of every Latin letter — well over a thousand codepoints. 𝐚𝐩𝐩𝐥𝐞 (math bold) and 𝑎𝑝𝑝𝑙𝑒 (math italic) and 𝒶𝓅𝓅𝓁𝑒 (math script) all render visibly differently from regular ASCII, so they're less weaponizable in phishing, but they do show up in social-engineering attacks against platforms that strip styling (chat messages, plain-text logs). The detector currently focuses on default-rendering homoglyphs and does not flag the entire math block by default.

Cherokee, Coptic, and Armenian Uppercase

Cherokee (U+13A0-U+13FF) contains many uppercase Latin look-alikes — Ꮯ (U+13E0) for C, Ꭰ (U+13A0) for D, Ꭼ (U+13BC) for E, and others. Armenian uppercase letters and a handful of Coptic codepoints map to Latin uppercase as well. These attacks target acronyms and proper nouns more than lowercase domain names. Browser IDN policies typically flag any mixed-script label so display-layer defense covers most of the risk, but if you're parsing user-supplied content directly (chat, comments, code identifiers) you'll want to expand detection.

Browser Display Normalization

Modern browsers apply IDNA2008 plus UTS #46 plus script-mixing detection before deciding how to display an IDN. A pure single-script Cyrillic domain (every label is Cyrillic, no Latin mixed in) is displayed in its native form; a mixed-script label is displayed in Punycode (xn--). Chrome enabled this defense in 2017 and Firefox in 2018. This means the most dangerous homoglyph attacks are now the ones that use a single-script TLD plus single-script labels (all-Cyrillic.рф style), bypassing the script-mixing fallback. The detector still flags these because operationally they're indistinguishable from Latin to a casual reader, but be aware that the browser may render them natively.

Behind the Scenes

Unicode Technical Standard #39

UTS #39 (Unicode Technical Standard #39: Unicode Security Mechanisms) is the Unicode Consortium's authoritative document on identifier and visual-spoofing defense. It defines two foundational concepts: identifier profiles (Highly Restrictive, Moderately Restrictive, Minimally Restrictive, Unrestricted, ASCII-Only) that limit which characters and script combinations are permitted in security-sensitive contexts, and skeleton equivalence, a normalization that replaces each codepoint with a representative confusable codepoint and then NFKC-normalizes the result. Two strings are confusable under UTS #39 if their skeletons are equal. The companion data file confusables.txt ships with each Unicode Character Database (UCD) release and contains thousands of single-character mappings derived from glyph rendering analysis.

IDNA2008 (RFC 5891)

Internationalized Domain Names in Applications, 2008 revision (RFC 5891), governs how non-ASCII characters appear in domain names. It defines two algorithms: ToASCII converts a Unicode label to its Punycode encoding (the xn-- form) for DNS resolution, and ToUnicode reverses that for display. IDNA2008 superseded IDNA2003 to add a stricter validity model — characters are partitioned into PVALID (always allowed), DISALLOWED, CONTEXTJ/CONTEXTO (allowed only in specific contexts), and UNASSIGNED categories based on derived properties. UTS #46 layers on top to provide a compatibility mapping for legacy IDNA2003 inputs.

Browser Punycode Display Rules

Chrome's IDN display policy (introduced 2017, refined in subsequent releases) checks several conditions before showing a domain in native Unicode form: the entire label must come from a single script with limited exceptions; the script must be in a trusted set; the label cannot mix digit-only and letter forms in a confusable way; and the registry of the TLD must permit IDNs. If any check fails, the browser falls back to Punycode display. Firefox uses a similar policy with per-script whitelisting controlled by network.IDN.whitelist.* preferences. Safari and Edge use related but not identical heuristics. The result is a moving target: a domain that displays as Unicode in one browser may display as Punycode in another.

Visual Confusables vs. Semantic Equivalents

It is important to distinguish visual confusables (different codepoints rendering as the same glyph) from semantic equivalents (different codepoints with related linguistic meaning). The Latin a and Cyrillic а are visual confusables: their glyphs match but their semantics are entirely separate (one is a Latin vowel, the other a Cyrillic vowel). The half-width katakana ka ｶ and full-width katakana ka カ are semantic equivalents — different codepoints for the same character with different display widths. UTS #39 skeleton normalization treats both categories but for different reasons: visual confusables for spoofing defense, semantic equivalents for canonicalization. The detector here is focused on visual confusables — semantic equivalence is a separate concern handled by NFKC normalization in upstream input processing.

This Tool vs. Other Homoglyph Defenses

The detector here covers a specific layer of the homoglyph problem — codepoint inspection of user-supplied text. Other defenses operate at different layers and catch different things. The table below maps each tool to the cases it catches and the cases it misses.

Related Tools

Homoglyph analysis often requires drilling deeper into codepoint structure, byte-level encoding, or invisible character residue that a high-level scan misses. The Unicode Inspector exposes every codepoint in a string along with its name, block, category, and combining class — useful when the homoglyph detector flags something and you want the full Unicode profile. The Unicode Search works in the opposite direction: search the Unicode Character Database by name or block to find the exact codepoint of a glyph you suspect is being used as a homoglyph source.

Homoglyphs frequently travel with invisible companions — zero-width characters, bidirectional overrides, and other formatting controls that don't render but affect string equality. The Zero-Width Char Detector surfaces those characters specifically, complementing the visible-character focus of the homoglyph scan. For verifying that a suspect string matches an expected length at the byte and codepoint level, the String Length Calculator reports separate counts for UTF-8 bytes, UTF-16 code units, and Unicode codepoints — a useful sanity check when comparing two visually identical strings.