Unicode Character Converter — Code Points, HTML Entities & JS Escapes

This Unicode character converter breaks down any string into its individual characters and shows each one's real Unicode code point — as U+XXXX, plain decimal, hexadecimal, HTML numeric entity, and JavaScript escape sequence — all at once. Switch direction and it works the other way too: paste a list of code points and get back the actual rendered characters, correctly reconstructing emoji and other characters outside the Basic Multilingual Plane.

Arb Digital built this as one of a set of free browser-based developer tools because Unicode inspection is a recurring, genuinely fiddly task: debugging mangled emoji in a database column, tracking down an invisible character breaking a regex, or just understanding why "😀".length returns 2 in JavaScript instead of 1. This tool answers all of that directly, without writing a line of code yourself.

What This Unicode Character Converter Does

Every character you can type or paste — a letter, digit, punctuation mark, emoji, or symbol from any writing system — is assigned a unique numeric identifier by the Unicode Standard, called a code point. This tool walks through your input one code point at a time (not one raw JavaScript string index at a time, which matters enormously for emoji, as explained below) and displays five representations for each: the character itself, its code point in the conventional U+ notation, the same value in plain decimal and hexadecimal, the HTML numeric character entity you could paste into a webpage, and the JavaScript escape sequence you'd use in source code.

In reverse mode, you supply code points — in U+XXXX format, as 0x-prefixed hex, or as plain decimal numbers — separated by spaces, commas, or line breaks, and the tool reconstructs the actual text those code points represent, correctly building surrogate pairs for any character above the Basic Multilingual Plane (which includes the vast majority of emoji).

How to Use the Unicode Character Converter

1. Choose a direction. "Text → Code points" analyzes text you type; "Code points → Text" builds text from code point values you supply.
2. Enter your input. Type or paste any string, including mixed scripts and emoji, or a list of code point values.
3. Read the breakdown. Each character or code point gets its own labeled line showing all five representations.
4. Check the summary stats. Code point count, UTF-16 code unit count, surrogate pair count, and estimated UTF-8 byte size are calculated automatically — useful for debugging length mismatches.
5. Copy the full breakdown with one click to paste into documentation, a bug report, or a support ticket.

How Code Points Are Calculated — Why "Length" Lies to You

JavaScript strings are internally sequences of UTF-16 code units, not Unicode code points. For characters in the Basic Multilingual Plane (roughly the first 65,536 code points, covering Latin, Cyrillic, Greek, most CJK ideographs, and more), one code unit equals one code point, so naive character-by-character iteration works fine. But characters outside that range — most emoji, many historic and mathematical scripts, and some rarer CJK ideographs — require two UTF-16 code units, called a surrogate pair, to represent a single code point. This is exactly why "😀".length returns 2 in JavaScript: the string engine sees two 16-bit surrogate code units, not one logical character.

Iterating with a plain for loop over string indices splits surrogate pairs apart, corrupting emoji and other supplementary characters into two meaningless "unpaired surrogate" glyphs. This tool avoids that bug entirely by using the modern iteration methods built for exactly this purpose — String.prototype.codePointAt() combined with spread-operator or for...of iteration, which JavaScript engines implement to walk a string by code point rather than by raw code unit. As MDN's documentation for String.codePointAt() explains, this method correctly returns the full code point value (up to 0x10FFFF) for a surrogate pair, not just the value of the leading surrogate half. This tool's summary stats explicitly show you the code point count alongside the raw UTF-16 unit count, so any surrogate-pair characters in your input are immediately visible as a discrepancy between the two numbers.

HTML Entities and JavaScript Escapes Explained

The HTML numeric character entity format (&#NNNN; for decimal, or &#xHHHH; for hex) lets you embed any Unicode character in an HTML document using only ASCII source characters — useful when your file encoding is uncertain, when a character might get mangled by a copy-paste pipeline, or when you deliberately want the literal escaped form to appear in a code sample rather than render as the actual glyph. This tool shows the decimal entity form for every code point so you can drop it straight into markup.

The JavaScript escape sequence works similarly but has two forms depending on whether a code point fits in one UTF-16 unit or needs a surrogate pair. Code points up to U+FFFF use the simple \uXXXX form. Code points above that (again, most emoji) technically require either two chained \uXXXX escapes representing the surrogate pair, or the newer, cleaner ES6 code point escape syntax \u{XXXXX}, which JavaScript engines expand directly to the correct character regardless of whether it needs one or two UTF-16 units internally. This tool displays the appropriate escape for each code point so you can paste it directly into a JavaScript string literal.

Why Surrogate Pairs and Emoji Trip Up Developers

Beyond the .length surprise, surrogate-pair characters cause a long list of subtle bugs: regular expressions without the Unicode flag can match half a surrogate pair and corrupt output; database columns sized in UTF-16 code units (common in some legacy systems) can silently truncate a string mid-character; naive substring or truncation logic can split an emoji in half, rendering it as a broken glyph or a replacement character; and string reversal functions that operate on raw indices scramble multi-unit characters into garbage. Modifier sequences make this even more layered — a family emoji or a skin-tone-modified emoji is frequently not one code point at all but several joined with zero-width joiner characters, meaning even correct code-point iteration shows you multiple entries for what renders as a single visual glyph. Understanding the difference between a code point, a grapheme cluster (what a user perceives as one character), and a UTF-16 code unit is essential for anyone doing serious text processing, and this tool's decomposition makes the distinction directly visible.

Common Mistakes to Avoid

• Using string length to count "characters." Use code point count (or better, grapheme cluster count) for anything user-facing — raw .length counts UTF-16 units and overcounts emoji and other supplementary characters.
• Splitting strings by index without checking for surrogates. Always iterate with for...of, the spread operator, or explicit codePointAt() logic rather than a plain indexed loop when correctness matters.
• Forgetting that some emoji are multiple code points. Flag emoji, skin-tone modifiers, and ZWJ sequences (like a family or profession emoji) are often built from several code points joined together — a single visual emoji does not guarantee a single code point.
• Mixing up decimal and hex when constructing HTML entities. A (decimal) and A (hex, note the x) both produce "A" — but A without the x or A written as &#0x41; will not render correctly.

Unicode Planes and the Structure of the Standard

The full Unicode code space is organized into 17 "planes" of 65,536 code points each, for a maximum possible range of U+0000 through U+10FFFF. Plane 0, the Basic Multilingual Plane, holds nearly every character used in modern everyday computing — Latin, Greek, Cyrillic, Hebrew, Arabic, most CJK ideographs, and general punctuation — and is the only plane representable with a single UTF-16 code unit. Plane 1, the Supplementary Multilingual Plane, is where most emoji actually live (roughly U+1F300 through U+1FAFF covers the bulk of modern emoji blocks), alongside historic scripts, musical notation, and mathematical alphanumeric symbols. Plane 2 holds rarer, less-common CJK ideographs used mainly in specialized dictionaries and historical texts. Because everything from Plane 1 onward sits above U+FFFF, every character in those planes requires a surrogate pair in UTF-16-based systems like JavaScript strings — which is the direct, structural reason emoji so consistently trigger the length and iteration bugs discussed above. Knowing which plane a code point falls in is often the fastest way to predict whether a piece of code handling "just ASCII" or "just BMP text" will choke on it.

It's also worth noting that Unicode code points and character encodings are two different layers. A code point is an abstract number; an encoding (UTF-8, UTF-16, or UTF-32) is a concrete rule for representing that number as bytes in memory or on disk. UTF-8, the dominant encoding on the modern web, uses a variable-length scheme of 1 to 4 bytes per code point, which is why this tool's UTF-8 byte count for a string full of emoji or non-Latin script is typically larger than either the code point count or the UTF-16 unit count — each of those three numbers is measuring the same text through a genuinely different lens.

Related Free Tools From Arb Digital

Working with character encoding often means checking multiple representations. Try our Base64 Encoder & Decoder for binary-safe text encoding, the Text to Binary Converter for raw binary representation, the Morse Code Translator for a classic character-substitution scheme, the CRC32 Hash Generator for checksum verification, and the Hash Generator for cryptographic hashing. Browse everything in our free online tools hub.

Frequently Asked Questions

This tool runs entirely in your browser — nothing you type or convert is uploaded or stored anywhere.