When Fancy Names Collapse to One Search Key: Testing NFKC Collisions

As of 2026-10-15

A directory may contain Alice, Ａlice and 𝐀lice. They look related, but a literal string comparison treats them as different text. Making them searchable under the same query is a product decision. Making them the same account is a much larger decision, and should not happen as an accidental side effect of a search helper.

We build the free fancy text generator at fancyfont.fyi. Its page offers Unicode text styles, copying and a profile preview, and advises keeping searchable words plain. This article looks at a separate developer problem: how an application of your own can search stylized display names without destroying their original spelling.

Keep a second key

Store the display text and the search key separately. The display value is what the person entered. The key expresses your chosen matching policy. The durable account ID should be independent of both.

Unicode provides canonical and compatibility normalization. NFC can bring canonically equivalent forms together while retaining compatibility distinctions. NFKC also folds compatibility distinctions, so fullwidth and mathematical styled letters can become ordinary letters. Unicode cautions that compatibility normalization loses information; see its normalization FAQ and normalization specification.

For a casual directory, that may be a useful search behavior. For mathematical text, a distinct styled letter may carry meaning. Applying NFKC to every stored document would be a much broader change than adding a forgiving name search. Keep the transformation close to the feature that needs it.

Value	Purpose	Can several records share it?
Account ID	Stable record identity	No
Display name	Presentation chosen by the person	Often yes
Normalized search key	Match candidates	Yes, by design
Unique handle	Product-defined public identifier	Depends on a separate policy

Run a collision fixture before building the index

Save the following as names.cjs and run it with Node.js. The sample uses NFKC and lowercase as a deliberately limited directory-search policy. It does not claim to implement full Unicode case folding or an identifier security standard.

const assert = require("node:assert/strict");

function searchKey(value) {
  if (typeof value !== "string") throw new TypeError("Expected text");
  return value.normalize("NFKC").toLowerCase().normalize("NFKC");
}

const people = [
  { id: "u1", display: "Alice" },
  { id: "u2", display: "Ａlice" },
  { id: "u3", display: "𝐀lice" },
  { id: "u4", display: "Alicé" }
];

const index = new Map();
for (const person of people) {
  const key = searchKey(person.display);
  if (!index.has(key)) index.set(key, []);
  index.get(key).push(person);
}

assert.equal("Ａ".normalize("NFC"), "Ａ");
assert.equal("Ａ".normalize("NFKC"), "A");
assert.equal("𝐀".normalize("NFKC"), "A");
assert.equal(searchKey("Cafe\u0301"), searchKey("Café"));
assert.notEqual(searchKey("Café"), searchKey("Cafe"));
assert.notEqual(searchKey("Straße"), searchKey("STRASSE"));
assert.notEqual(searchKey("a"), searchKey("\u0430"));

const matches = index.get(searchKey("ALICE")) ?? [];
assert.deepEqual(matches.map(person => person.id), ["u1", "u2", "u3"]);
assert.equal(people[2].display, "𝐀lice");
console.log(matches);

The search for ALICE returns three candidates. That is the intended result: three records share a key. If the index stored a single person per key, each insertion would overwrite the previous match. A normalization improvement would then quietly become a data-loss bug.

Notice what the assertions refuse to collapse. An accented letter is not automatically the unaccented letter. The German sharp s is not converted to ss by this lowercase pipeline. A Cyrillic small a is not the Latin a, despite their appearance in many typefaces. These examples are executable boundaries for this particular helper.

Decide what a collision means in each workflow

In a search box, a collision can produce several results. Show enough context to help the user choose without exposing private details. In an invitation flow, accept a stable identifier or require selection of the intended record. A display-name match alone is weak evidence of the recipient's identity.

In account registration, the same collision may require rejection if the product promises unique handles under this matching rule. That uniqueness must also be enforced where records are stored. Checking in the browser and then inserting without a shared constraint leaves a race between simultaneous registrations.

The key lesson is not to use one helper indiscriminately. Searching, displaying, authenticating and reserving a handle are separate operations. A convenient search result should not authorize access to somebody else's account or silently rename their profile.

Version the policy before changing existing data

Suppose a directory originally indexed exact lowercase text and later adds NFKC. Previously distinct keys can now collide. Rebuild into a new index, inspect the collision groups, and decide how each affected feature should behave before switching traffic.

Keep the old display values during that migration. Normalization is not a reversible encoding: once several inputs have become the same output, the output cannot tell you which original was used. Storing only the normalized value would make it impossible to restore the original presentation accurately.

A migration report can list the policy version and measured collision groups without exposing private names.

Test the UI as well as the helper

The sample verifies string behavior, but a useful search interface also needs tests for empty queries, pasted whitespace, sorting and selection. Decide whether trimming is part of your policy. This helper intentionally does not remove punctuation or trim a person's display name.

Run the fixtures in the runtimes that will produce and consume the key. If your database applies a different collation, compare its uniqueness behavior with the application helper. Compare actual strings, not policy labels.