Your translations are perfect, and your app still breaks in other languages: a name field rejects "José", a truncated notification ends in a broken emoji, a search for "resume" misses "Résumé", and a sorted list puts "Äpfel" after "Zebra." These are string-handling bugs, not translation bugs. This guide covers the seven Unicode mistakes that show up in nearly every JavaScript codebase that goes international, with the fix for each.
JavaScript strings are sequences of UTF-16 code units, and .length counts code units. But what a user sees as one character, called a grapheme cluster, can be made of several code points, and each code point can take one or two code units.
"a".length; // 1
"👍🏽".length; // 4 (thumbs up + skin tone, 2 code units each)
[..."👍🏽"].length; // 2 (code points)
"👨👩👧".length; // 8 (man, ZWJ, woman, ZWJ, girl)
[..."👨👩👧"].length; // 5
"नमस्ते".length; // 6 (Hindi "namaste": 3 visible clusters)
Three different units, three different answers. Spreading a string into an array ([...str]) fixes the surrogate-pair problem but still splits emoji sequences and combining marks. For what users perceive as characters, you need Intl.Segmenter.
str.slice(0, n) cuts at a code-unit boundary. When that boundary lands inside an emoji or a combined character, you get half a character:
"Hello 👋".slice(0, 7);
// "Hello \ud83d" (a lone surrogate that renders as �)
"Family: 👨👩👧 trip".slice(0, 10);
// "Family: 👨" (the family emoji became a single man)
encodeURIComponent("Hi 👋".slice(0, 4));
// URIError: URI malformedThat last one is a real production crash: truncate a string for a URL slug or analytics event and the encoder throws. Segment by graphemes instead:
export function truncate(text, max, locale = "en") {
const segmenter = new Intl.Segmenter(locale, { granularity: "grapheme" });
const graphemes = Array.from(segmenter.segment(text), (s) => s.segment);
if (graphemes.length <= max) return text;
return graphemes.slice(0, max - 1).join("") + "...";
}
truncate("Family: 👨👩👧 trip", 10); // "Family: 👨👩👧..."
export const graphemeLength = (text, locale = "en") =>
[...new Intl.Segmenter(locale, { granularity: "grapheme" }).segment(text)].length;
graphemeLength("👨👩👧"); // 1
graphemeLength("नमस्ते"); // 3
For visual truncation, prefer CSS (text-overflow: ellipsis or line-clamp). The browser truncates on rendered width, which handles every script correctly and adapts to the longer strings translations produce. Reserve JavaScript truncation for places CSS cannot reach, such as push notifications, SMS, meta descriptions, and database fields.
HTML maxlength counts UTF-16 code units, so a 280-character limit allows only 70 four-unit emoji. If your counter shows "characters remaining," compute it with graphemeLength() so the number matches what the user sees, and enforce the real storage limit separately on the server.
"é" can be stored as one code point (U+00E9) or as "e" followed by a combining acute accent (U+0301). They render identically and compare as different:
const composed = "é"; // é
const decomposed = "é"; // é
composed === decomposed; // false
composed.normalize("NFC") === decomposed.normalize("NFC"); // truemacOS file names, copy-paste from PDFs, and some mobile keyboards produce decomposed text. If you deduplicate usernames, look up tags, or compare translation keys, two visually identical values will not match. Normalize to NFC on input, at the point where text enters your system, and store the normalized form:
const clean = (input) => input.trim().normalize("NFC");For security-sensitive identifiers such as usernames, look at NFKC normalization and confusable-character detection too. "аdmin" with a Cyrillic "а" is not "admin," and normalization alone will not catch it.
Array.prototype.sort() without a comparator orders by UTF-16 code unit, which puts every uppercase letter before every lowercase one and every accented letter after Z:
["Zebra", "apple", "banana", "Äpfel"].sort();
// ["Zebra", "apple", "banana", "Äpfel"] (wrong in every language)
["Zebra", "apple", "banana", "Äpfel"].sort(new Intl.Collator("de").compare);
// ["Äpfel", "apple", "banana", "Zebra"]"Alphabetical" also differs between languages. Swedish treats "å", "ä", and "ö" as separate letters at the end of the alphabet, after Z:
["Zebra", "apple", "zoo", "Ångström", "Äpfel"].sort(new Intl.Collator("sv").compare);
// ["apple", "Zebra", "zoo", "Ångström", "Äpfel"]Collator options handle two other common needs:
// Natural sort: file2 before file10
["file10", "file2", "file1"].sort(new Intl.Collator("en", { numeric: true }).compare);
// ["file1", "file2", "file10"]
// Case- and accent-insensitive equality
const base = new Intl.Collator("en", { sensitivity: "base" });
base.compare("resume", "Résumé"); // 0 (equal)
localeCompare() uses the same machinery, but it creates a collator on every call. For sorting a large list, construct one Intl.Collator and pass its compare method. And remember that your database sorts too: ORDER BY name uses the column's collation, which should match the user's language for sorted lists to be consistent between server-side pagination and client-side sorting.
Users type "creme brulee" and expect to find "Crème Brûlée." Decompose with NFD and strip the combining marks to build a search key:
const searchKey = (text) =>
text.normalize("NFD").replace(/\p{M}/gu, "").toLocaleLowerCase();
searchKey("Crème Brûlée"); // "creme brulee"Use this for matching and indexing, never for display. And be aware it is a language-specific simplification: in Spanish, "ñ" is a separate letter from "n," and in German, users may type "ae" for "ä." For anything beyond simple filtering, a search engine with per-language analyzers is the right tool.
"I".toLowerCase(); // "i"
"I".toLocaleLowerCase("tr"); // "ı" (dotless i in Turkish)
"i".toLocaleUpperCase("tr"); // "İ" (dotted capital I)
"ß".toUpperCase(); // "SS" (one character becomes two)
Two rules follow. For user-facing text, use toLocaleUpperCase(locale) and toLocaleLowerCase(locale) with the content's language. For machine identifiers such as enum values, HTTP headers, and keys, use plain toLowerCase(), so a Turkish user's environment never turns "TITLE" into a key that does not exist.
And avoid uppercasing translated strings in code at all. Use CSS text-transform: uppercase with a correct lang attribute, which lets the browser apply the language's rules, or let translators supply the uppercase form when it matters.
/^[A-Za-z]+$/ rejects "Zoë," "José," "Nguyễn," and "李." People should not have to misspell their own names to sign up. Use Unicode property escapes, which require the u flag:
/^[A-Za-z]+$/.test("Zoë"); // false
/^\p{L}+$/u.test("Zoë"); // true
/^\p{L}+$/u.test("李"); // true
// Without the u flag, "." matches half an emoji
/^.$/.test("😀"); // false
/^.$/u.test("😀"); // trueFor names, the safest validation is almost none: required, trimmed, normalized, and within a length limit. Names can contain spaces, hyphens, apostrophes, and characters from any script. Many people have one name only, and many have no concept of "first" and "last."
Splitting on spaces to count words or highlight terms fails for Japanese, Chinese, and Thai, which do not separate words with spaces. Intl.Segmenter handles word segmentation too:
const words = (text, locale) =>
[...new Intl.Segmenter(locale, { granularity: "word" }).segment(text)]
.filter((s) => s.isWordLike)
.map((s) => s.segment);
words("Hello, world! It's 2026.", "en"); // ["Hello", "world", "It's", "2026"]
words("สวัสดีครับ", "th"); // ["สวัสดี", "ครับ"]
words("東京都に住んでいます", "ja"); // ["東京", "都", "に", "住", "んで", "い", "ます"]Word counts for CJK text are usually measured in characters instead, which is worth knowing if you enforce length limits by word count in a review or content tool.
Storage limits are usually in bytes, not characters, and UTF-8 uses one to four bytes per code point:
new TextEncoder().encode("hello").length; // 5
new TextEncoder().encode("héllo").length; // 6
new TextEncoder().encode("日本").length; // 6
new TextEncoder().encode("👋").length; // 4utf8 charset (an alias for utf8mb3) stores at most three bytes per character and cannot store emoji. Use utf8mb4.<meta charset="utf-8">, send Content-Type: ...; charset=utf-8, and save translation files as UTF-8 without a byte order mark. Text such as é where é should be is UTF-8 that something decoded as Latin-1.Intl.Segmenter graphemes, or let CSS truncate.Intl.Collator for the user's locale.\p{M} removal.\p{L} and the u flag, and validate names minimally.utf8mb4 in MySQL and UTF-8 everywhere else.String handling and formatting go together. For numbers, dates, and currency, see our guide to the JavaScript Intl API, and to catch these bugs before your users do, run your UI through a pseudo-locale.
JavaScript's length property counts UTF-16 code units. The thumbs-up emoji and the skin-tone modifier are each outside the Basic Multilingual Plane, so each needs two code units, for a total of four. Use Intl.Segmenter with grapheme granularity to count the single visible character.
Split the string into grapheme clusters with new Intl.Segmenter(locale, { granularity: "grapheme" }), take the first N segments, and join them. Slicing by index can cut a surrogate pair or an emoji sequence in half.
Create an Intl.Collator for the user's locale and pass its compare method to sort(). The default sort orders by code unit, which places uppercase before lowercase and accented letters after Z.
Normalization converts equivalent sequences of code points, such as a precomposed "é" and "e" plus a combining accent, into one consistent form. Normalize user input to NFC before storing or comparing it so that visually identical text compares as equal.
Yes. Intl.Segmenter is supported in current versions of Chrome, Edge, Safari, and Firefox, and in Node.js, so it is safe to use without a polyfill for modern browser targets.
A character is not a code unit, equality needs normalization, alphabetical order depends on language, and ASCII regex rejects real people. Use Intl.Segmenter, normalize("NFC"), Intl.Collator, and \p{L}, and most of these bugs disappear before your first non-English user signs up.
Robust string handling makes your code ready for every language. Babelize takes care of the other half, translating and syncing your UI strings in every locale as part of your Git workflow.
--- - [All articles](https://www.babelize.co/blogs)