Unicode Homoglyph Checker — Compare Lookalike Domains Locally

Unicode Homoglyph Checker

Compare two domains for lookalike Unicode characters before you trust a login, source, or share link in an AI submission.

Local processing · No domain is contacted

This page contains no network-request code. It compares the text in browser memory and does not save it.

1. Add the expected and observed domains

Copy only the domain from a trusted source and the domain you want to inspect. Paths and fragments are ignored.

Comparison summary

Waiting for input

—

Add two domains to begin.

Skeleton matchNot checked

Mixed scriptsNot checked

Punycode labelNot checked

Invisible or bidi controlsNot checked

A low signal count is not proof that a domain, link, account, or file is safe.

Direct render of the approved working interface.

Before you upload an AI assignment, document, code bundle, or image, compare every login, source, and share-link domain that could expose private work or weaken your evidence trail. This Unicode Homoglyph Checker compares two domains for lookalike characters without contacting either domain. Its code makes no network request and does not save the text.

The interactive tool and its direct-render capture are included in this review edition. This limited comparison does not prove that a domain, link, account, or file is safe.

How to use it

1. Copy the expected domain from a known-good source.
2. Paste the domain from the message, document, code comment, or upload prompt you want to inspect.
3. Select Compare locally.
4. Review the normalized text, ASCII form, simplified skeleton, writing systems, and code points before you open a link or upload a file.

The 253-character input boundary follows the maximum full-domain length used by DNS tooling. Paths, query strings, and fragments are ignored so the comparison stays focused on the host.

What the checker reviews

• Simplified skeleton match: a deliberately limited local mapping for common Latin, Greek, Cyrillic, and full-width lookalikes.
• Mixed scripts: whether a domain combines more than one non-common writing system.
• Punycode labels: whether browser normalization produces an xn-- label.
• Invisible and bidirectional controls: selected format and control characters that need manual review.
• Character inventory: the visible character, Unicode code point, writing-system group, and configured skeleton mapping.

Unicode Technical Standard #39 defines confusable detection through skeletons and restriction levels. This candidate does not embed the full Unicode data set. A missed match can still be deceptive, and a match can belong to a legitimate internationalized domain.

Three examples

1. apple.com and аpple.com look similar, but the second form begins with Cyrillic а (U+0430). The candidate flags the skeleton match and mixed scripts.
2. A browser may display an internationalized domain while its normalized ASCII form contains xn--. Punycode is a review signal, not proof of abuse.
3. Two different domains may use only ordinary ASCII characters, such as example.com and examp1e.com. This candidate reports a difference but does not decide whether either domain is trustworthy.

Manual checks the browser cannot finish

• Open a known-good bookmark or type the expected domain yourself.
• Check the full destination, account, certificate warnings, and surrounding message.
• Verify source ownership and preserve the original link or message as evidence.
• Review the AI service's current privacy, retention, training, and sharing settings before upload.
• Inspect file properties, comments, tracked changes, hidden sheets, embedded links, and metadata in the original application.

Why this matters

Unicode UTS #39 describes mechanisms for detecting visually confusable identifiers and mixed-script risks. Unicode TR36 explains that visual spoofing can make different identifiers appear alike. The current Unicode security data supplies the confusable mappings used by conforming implementations. The browser URL parser also performs IDNA processing when it converts an internationalized host to an ASCII domain.

FAQ

Does “No configured match” mean the domain is safe?
No. The mapping is intentionally limited. It does not check reputation, registration, ownership, redirects, page content, certificates, or every Unicode confusable.

Does the tool contact either domain?
No. This candidate contains no network-request code. It compares the entered text in browser memory and does not save it. A future blog page may load normal theme resources, so the claim applies to the tool's handling of the entered domains.

Is every mixed-script or Punycode domain malicious?
No. Legitimate internationalized domains use non-ASCII scripts and Punycode. Treat these signals as prompts to verify the expected owner and context.

Does a matching skeleton prove impersonation?
No. It shows that the configured mapping reduces two different strings to the same comparison form. Intent and ownership still require external evidence.

Can I paste a full URL?
Yes. The candidate extracts the host and ignores the path, query, and fragment. Review the full URL separately before opening it.

Related tools

• Suspicious URL Risk Checker
• Disguised File Name Checker

Compare a suspicious domain locally, then verify the destination and your upload policy through a known-good source.

Primary references

• Unicode Technical Standard #39 — Unicode Security Mechanisms
• Unicode Security Considerations — Unicode Technical Report #36
• Unicode security data — current confusables.txt
• WHATWG URL Standard — IDNA

Verified evidence

• Four primary-reference URLs and two related-tool URLs: HTTP 200 on 2026-10-23 KST.
• Chromium 390, 760, and 1280 px: horizontal overflow, clipped visible elements, square characters, and replacement characters all 0.
• Example, boundary, Punycode, mixed-script, skeleton, and copy tests passed.
• Tool HTTP(S) requests during local comparisons: 0. Script non-ASCII characters: 0. Console and page errors: 0.
• Absolute security-expression matches: 0.