Unicode Code Point Inspector

How to use this Unicode Code Point Inspector

To use this Unicode Code Point Inspector, start with whichever form of the character is easiest to enter, then let the page translate it into the other representations.

1. Enter a character

In the Character field, type or paste a single Unicode character. The inspector works well with ordinary letters, accented letters, symbols, and emoji:

• Latin letter: A, é, ß
• Emoji: 😀, 🎼, 🚀
• Non-Latin script: م, Ж, अ, 汉
• Common symbol: €, ©, →

The script normalizes the input and inspects the first code point it finds. That means the inspector is best for a single code point, not for long strings or full grapheme clusters made from multiple code points. If you need to inspect a literal space or another non-printing character, the code point field is usually more reliable because the character field trims surrounding whitespace.

2. Enter a code point

In the Code Point field, you can enter the numeric value directly in several common formats:

• Standard Unicode notation: U+1F600, U+00E9
• Hex with 0x prefix: 0x1F600, 0x41
• Plain hexadecimal when it contains letters A-F: 1F600, E9
• Decimal: 128512, 65

Digits-only values are treated as decimal, so a value like 0041 should be entered as U+0041 if you want hexadecimal rather than decimal 41. If you fill in both fields, the code point takes precedence, which makes it easier to correct accidental extra characters in the text box.

3. Run the inspection

After entering your value, activate the Inspect button. The result area will show:

• The normalized code point, such as U+1F600.
• Decimal, hexadecimal, and grouped binary values.
• UTF-16 code units, with one unit for BMP characters and two units for surrogate pairs.
• A basic category label derived from Unicode-aware property checks.

What is a Unicode code point?

A Unicode code point is the numeric identity assigned to a character, symbol, emoji, or control code in the Unicode repertoire. Conceptually, the Unicode space is a numbered list from U+0000 to U+10FFFF, and each position may represent a letter, digit, punctuation mark, symbol, emoji, or a special non-printing control code.

By convention, code points are written as U+HHHH where HHHH is a hexadecimal number. For example:

• A → U+0041
• é → U+00E9
• 😀 → U+1F600

Computers still store bytes rather than abstract code points, so encoding schemes such as UTF-8 and UTF-16 map each Unicode value to one or more underlying code units before the data is written to memory or disk. This inspector does not replace a full encoding reference, but it does give you the key identifier you need before that next encoding step happens.

Formula for surrogate pairs (UTF-16)

When the Unicode Code Point Inspector sees a value above U+FFFF, it uses the standard UTF-16 surrogate-pair rule. If CP is a code point in the range U+10000 to U+10FFFF, the transformation from CP to the two UTF-16 units can be expressed formally.

The core relationship can be written as:

Then the high and low surrogates are:

In words:

1. Subtract 0x10000 (65536) from the code point.
2. Divide the result by 1024. The quotient, added to 0xD800, gives the high surrogate.
3. The remainder, added to 0xDC00, gives the low surrogate.

The inspector applies this logic when it displays UTF-16 units for characters outside the Basic Multilingual Plane.

Worked example: 😀 as U+1F600

If you enter 😀 into the Character field, the Unicode Code Point Inspector reads it as U+1F600 and then derives the related numeric forms:

1. The Unicode code point is U+1F600.
2. In decimal, this is 128512.
3. In binary, it is a 21-bit value: 0001 1111 0110 0000 0000 when grouped for readability.
4. Because it is greater than U+FFFF, UTF-16 uses a surrogate pair.

Following the surrogate pair formula:

• CP = 0x1F600.
• v = CP − 0x10000 = 0xF600.
• high = 0xD800 + (v / 0x400) = 0xD800 + 0x3D = 0xD83D.
• low = 0xDC00 + (v mod 0x400) = 0xDC00 + 0x200 = 0xDE00.

The inspector presents those UTF-16 units so you can see why JavaScript often reports this character as length 2, and why supplementary-plane characters need special care when you slice strings, count characters, or build escape sequences.

Interpreting the Unicode Code Point Inspector output

After the Unicode Code Point Inspector runs, the table groups the same value into several different views so you can compare notation, storage, and classification at a glance.

• Character — The visible representation of the code point. Non-printing values may appear as a label rather than a glyph.
• Unicode code point — The normalized U+HHHH form. This is the safest notation for documentation and standards references.
• Decimal value — The base-10 form of the same number, useful in APIs, logs, and numeric character references.
• Hex value — The base-16 representation commonly used in programming and Unicode charts.
• Binary value — The bit pattern of the code point, grouped for easier reading.
• UTF-16 units — One or two 16-bit values that show how the code point appears in JavaScript strings and many APIs.
• UTF-16 length — The number of UTF-16 code units used by that character.
• Category — A simplified label such as letter, digit, whitespace, control, or symbol.

When those fields do not match what you expected, the mismatch usually tells you something useful: perhaps you typed the wrong code point, perhaps the character is supplementary and therefore uses a surrogate pair, or perhaps a blank-looking result is actually a whitespace or control code rather than an empty value.

Common Unicode code point representations compared

Unicode code point inspection often means comparing one value across several notation systems, because the same character may appear differently depending on where you found it. The table below outlines some of the most common ways to express a code point and how they relate to the inspector’s outputs.

Practical uses and limitations of Unicode code point inspection

In day-to-day Unicode code point inspection, this page is useful whenever the character you see and the value your software stores do not line up cleanly.

Practical uses

• Debugging encoding problems — When a character does not display as expected, check whether the code point and UTF-16 units match what you intended to send or store.
• Working with emoji — See why emoji and other supplementary characters occupy two UTF-16 units, and verify that your tooling handles them correctly.
• Regular expressions with Unicode — Use the category information to decide whether patterns such as \p{L} for letters or \p{Nd} for decimal digits are appropriate in a Unicode-aware regex engine.
• Generating escape sequences — Convert a visible character into the numeric form required by HTML, JavaScript, or other languages.

Unicode code point limitations and assumptions

• Supported range — The tool targets the standard Unicode range from U+0000 to U+10FFFF. Values outside this range are invalid.
• Unassigned or deprecated code points — If you manually enter a code point that is not currently assigned to a character, the tool still treats it as a numeric value. Your system font may display nothing or show a replacement box.
• Non-printing characters — Control codes and formatting characters do not have a visible glyph. The numeric result may be more informative than the rendered character cell.
• No normalization analysis — The tool does not compare NFC, NFD, or other normalization forms. Canonically equivalent sequences can still appear as distinct inputs.
• Single code point focus — The inspection logic is oriented around one code point at a time. Grapheme clusters such as flags, family emoji, or letter-plus-combining-mark sequences are not unpacked into a full sequence report.
• Environment-dependent fonts — Whether a glyph appears correctly, shows in color, or falls back to a missing-glyph box depends on your browser and installed fonts, not on the inspector itself.

Keeping those limits in mind makes the Unicode Code Point Inspector easier to interpret and helps you avoid mistaking font behavior, normalization, or multi-code-point sequences for a bad code point.

Unicode code points vs. UTF-16 code units

The Unicode Code Point Inspector emphasizes UTF-16 because that is where abstract code points and concrete string storage diverge in JavaScript and many related APIs.

• The Unicode range is split into the Basic Multilingual Plane (BMP), from U+0000 to U+FFFF, and supplementary planes, from U+10000 to U+10FFFF.
• BMP characters use one 16-bit code unit. For example, A (U+0041) is stored as a single unit 0041.
• Supplementary characters, including most emoji, use two 16-bit code units called a surrogate pair.

JavaScript’s string.length property counts UTF-16 code units, not Unicode code points. That means a supplementary character can look like one symbol to a reader while still counting as length 2 in code. The inspector makes that visible by showing the UTF-16 units and their count directly in the result table.

Next steps for Unicode code point inspection

After using this Unicode Code Point Inspector a few times, the next step is to apply the same checks in your own code, content workflows, and debugging habits. Use it as a quick reference whenever you need to confirm a code point, generate an escape sequence, understand why a character has UTF-16 length 2, or verify that a value copied from one system still names the same Unicode character in another. A little code-point awareness removes a surprising number of text bugs.