Unicode-LE

Unicode-LE: The Characters That Are Not What They Look Like

Find the Unicode that hides meaning in the current file or the whole workspace

Bidi controls, invisibles, homoglyphs, mixed scripts, non-NFC text, spaces that are not the space

---

Useful? A star or rating is how other developers find it —

★ GitHub ·

★ Open VSX ·

★ Marketplace

What it does

Open a file, run Unicode-LE: Detect Unicode Risks, and every character in it that is not what it looks like lands in a report beside the editor: the bidirectional controls behind CVE-2021-42574, zero-width and other invisibles, homoglyphs, words no single script accounts for, lines that are not in Normalization Form C, spaces that are not U+0020, and codepoints with no agreed meaning. Scan Workspace does the same for every file on disk. Works in VS Code and in VS Code–based editors like Cursor and VSCodium (installable from Open VSX).

• Review a pull request for Trojan Source — a right-to-left override that makes the code a reviewer reads differ from the code that runs
• Screen for forged names — a Cyrillic а in an otherwise Latin pаypal is a finding; a word written wholly in Cyrillic is not
• Explain the string that never matches — a zero-width space or a decomposed é between two values a hash calls different and a person calls identical

The report never contains a character it found. Every finding is written as U+202E, never as the character itself, and a file path or key path from the document is escaped to . A report that pasted one raw would reorder the screen of whoever read it, and the tool would become the delivery mechanism for the thing it detects. It rewrites nothing: not a normalization, not a stripped space.

Install

Use it from an AI agent

The same engine runs as an MCP server, so an agent can call it directly instead of you running a command. It matters more here than for most tools: a model that pasted a document into its own reasoning has already been handed the bidi controls in it, and what comes back from this server is U+XXXX and English, so the answer cannot carry them on into a commit message or a review comment.

detect_unicode_risks(content, kinds?, scripts?, format?, filename?, maxResults?)

Returns each finding with its kind, severity, 1-based line and column (UTF-16, as an editor counts), byte offset, the codepoints, the script and, where the format allows, the key path it sits under — plus any refusal, both structured and as a warning, so an empty finding list is never mistaken for a clean document. Every non-ASCII character in a reply leaves as \uXXXX. Capped at 500 by default with meta.truncated.

The server takes content and returns data — it reads no files and makes no network requests of its own. Published as unicode-le-mcp on npm and as io.github.nolindnaidoo/unicode-le in the MCP registry. It answers exactly as the Rust CLI's server does: one corpus runs against both, a differential test feeds both thousands of generated documents, and both read the same Unicode tables — written out by the crate — rather than whatever version the host's JavaScript engine carries.

Configuring it by hand — any host with an MCP config file

{

"mcpServers": { "unicode-le": { "command": "npx", "args": ["-y", "unicode-le-mcp"] } } }

Or install it once with npm install -g unicode-le-mcp and point at unicode-le-mcp. It needs no environment variables, no API key and no configuration of its own. To check it:

echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | npx -y unicode-le-mcp

What it finds

It runs on translated code without drowning you

A naive confusable check flags every letter of every Russian and Chinese string in a workspace — thousands of findings on exactly the codebases that most need the check, so it gets switched off, and the Trojan Source screen goes off with it.

• A word is judged, never a file. Привет is wholly Cyrillic and is Russian. Japanese mixes Han, Hiragana and Katakana in one word constantly, and UTS #39 knows that is Japanese.
• A file plainly written in another script is not judged for homoglyphs, and the report says so — at least 10% of its letters in a script nobody declared. Every other check still runs on it.
• Declaring a script turns the check on, never off. Name your workspace's scripts in unicode-le.detection.scripts — Han, Cyrillic, Hira — and a Latin product name inside a Chinese string is a translation, while a Cyrillic letter in a Latin word in the same file is still caught.

It says where in the document, not just where in the file

In JSON, YAML, TOML, INI and .properties, .env, CSV and TSV a finding also carries the key path it sits under — metrics.headline.eyebrow rather than line 412 of a five-thousand-line catalogue. The format never decides whether a finding exists, only how it is addressed: a file whose format cannot be parsed is still scanned and still reports everything in it.

It refuses rather than guessing

The workspace scan reads every file as bytes. A UTF-16 or UTF-32 file, a binary file and a file that is not valid UTF-8 are refused by name rather than decoded as something else, because a wrong decode invents findings: read UTF-16 as UTF-8 and every second byte becomes an invisible character that is not in the file.

Across a folder or a workspace

Detect reads the document you have open. A scan reads many files from disk and gives one report.

• The whole workspace: run Unicode-LE: Scan Workspace for Unicode Risks from the command palette.
• One folder: right-click it in the Explorer and choose Scan Folder for Unicode Risks, or run Unicode-LE: Scan Folder for Unicode Risks and pick one.

The report has a section for each file with a finding, and for each file that could not be judged:

# Unicode-LE report

3 finding(s) in 4 file(s) scanned; 2 file(s) not fully judged.

latin1.txt

• Not judged (binary_or_undecodable): not valid UTF-8 at byte 3: the encoding is unknown and is not guessed

notes.txt

• Not judged (encoding_unknown): a UTF-16LE byte-order mark: this reads UTF-8 only, and decoding UTF-16LE as UTF-8 would invent invisible and unassigned characters that are not in the file

src/login.ts

• 1:7 · mixed-script · high · U+0430
• 1:8 · confusable · high · U+0430 (resembles U+0061)
• 1:17 · bidi-control · high · U+202E

Each finding also carries a sentence saying why it matters, left out here.

What a scan reads. Files come from disk, so an unsaved edit is not seen. A file over the safety size is left unread. A text file that is not UTF-8 is named in the report with the reason, never guessed at and never passed over. It stops at 5,000 files or 10,000 listed findings. The report ends with a line for each thing it left out.

A scan that skips is not a clearance. By default a scan does not read dependency folders, files the project's .gitignore leaves out, or binary files. A character hidden in one of those is not reported. To screen everything, turn the three switches off.

What it skips, and how to change that. Three switches are on by default, and each can be turned off on its own in Settings:

Two lists adjust the result without turning a switch off. To skip more, add a pattern to scanExcludes. To read something a switch would skip, add it to scanAlwaysInclude:

{

// Also skip the test fixtures. "unicode-le.workspace.scanExc