Unicode Code Point Inspector

JJ Ben-Joseph headshot Editorial review by: JJ Ben-Joseph

Introduction

Unicode can feel abstract until you need to debug a real character problem. A symbol that looks simple on screen may also have a decimal value, a hexadecimal code point, a binary pattern, and a UTF-16 representation that uses one or two code units depending on where that symbol lives in the Unicode range. This calculator brings those views together so you can stop guessing and start seeing exactly how a character is identified.

The inspector accepts either a visible character or a code point value. If you know the glyph, such as A, é, €, or 😀, you can enter it directly and let the page derive its numeric forms. If you already have a value from documentation, source code, an API, or an error message, you can enter the code point instead and reconstruct the character from the number. The goal is the same in both directions: make Unicode easier to inspect and easier to reason about.

This is especially helpful when you are comparing what a specification says with what your program stores. Web developers often meet Unicode through JavaScript strings, HTML entities, JSON payloads, fonts, search, or regular expressions. In all of those places, the same underlying code point can appear in different notations. One practical note matters here: if you type only digits into the code point field, the tool interprets them as decimal. To force hexadecimal for a value that contains only digits, include the U+ or 0x prefix.

What this Unicode Code Point Inspector does

The Unicode Code Point Inspector lets you move back and forth between characters and their underlying numeric identifiers. For any valid Unicode character or code point it can show the normalized Unicode notation, the decimal and hexadecimal values, a grouped binary representation, the UTF-16 code units, and a basic category label such as letter, digit, whitespace, control, or symbol. That combination is useful because real encoding problems usually involve more than one of these views at once.

For example, an emoji that appears as one visible character may still occupy two UTF-16 code units in JavaScript. A space character may seem to be “nothing,” yet it still has a code point and category. A numeric reference copied from HTML may look different from a JavaScript escape, even though both name the same Unicode value. By putting those formats side by side, the inspector helps you confirm what character you actually have.

Show the code point in decimal, hexadecimal, and binary form.
Display the corresponding character, if it is printable.
Break the value into UTF-16 code units, including surrogate pairs for emoji and other non-BMP characters.
Provide a simple character classification such as letter, digit, whitespace, control, or symbol.

This is useful when you are debugging encoding problems, writing regular expressions with Unicode support, working with emoji, or simply learning how Unicode works internally.

How to use this inspector

The form accepts either a single character or a numeric code point. You can use whichever starting point is more convenient, and the calculator will translate it into the other representations.

1. Enter a character

In the Character field, type or paste a single character. Examples include 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 tool is best for single code points, not 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 the more reliable input 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?

Unicode assigns every character a unique number called a code point. Conceptually, the Unicode space is a numbered list from U+0000 to U+10FFFF. 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

Internally, computers still store bytes, not abstract code points. Encoding schemes such as UTF-8 and UTF-16 map each code point to one or more underlying code units, which are then expressed as bytes in memory or on disk. The inspector does not attempt to replace full encoding tables, but it gives you the key identifier you need before that next encoding step happens.

Formula for surrogate pairs (UTF-16)

For code points above U+FFFF, UTF-16 uses surrogate pairs. 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:

CP - 65536 = v

Then the high and low surrogates are:

high = 0xD800 + v / 1024

low = 0xDC00 + v mod 1024

In words:

Subtract 0x10000 (65536) from the code point.
Divide the result by 1024. The quotient, added to 0xD800, gives the high surrogate.
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: 😀 (U+1F600)

Suppose you paste 😀 into the Character field and click Inspect. The tool will find its code point and derive related data:

The Unicode code point is U+1F600.
In decimal, this is 128512.
In binary, it is a 21-bit value: 0001 1111 0110 0000 0000 when grouped for readability.
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 these UTF-16 units so you can see why JavaScript often reports this character as length 2, and why supplementary-plane characters require special care when you slice strings, count characters, or build escape sequences.

Interpreting the inspector output

Once you run the tool, you will see several fields that describe the same value in different ways. Reading them correctly is the key to using the result well.

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 these fields disagree with what you expected, you usually learn something important: perhaps you typed the wrong code point, perhaps a 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 representations compared

The same Unicode character can appear in different notations depending on context. The table below outlines some of the most common ways to express a code point and how they relate to the inspector’s outputs.

Common Unicode representations and how they map to the inspector
Context	Example notation	Relationship to inspector output
Unicode standard	`U+1F600`	Matches the inspector’s normalized code point field.
Hex literal in code	`0x1F600`	Same numeric value as the hex output, using a language-specific prefix.
Decimal code	`128512`	Matches the inspector’s decimal value.
JavaScript escape	`"\u{1F600}"` or `"\uD83D\uDE00"`	These are code representations derived from the same code point or its UTF-16 units.
HTML entity	`😀` or `😀`	These numeric character references are based on the decimal and hex outputs.
UTF-16 units	`D83D DE00`	Corresponds to the inspector’s UTF-16 code unit field.

Practical uses and limitations

This inspector is designed as a lightweight, browser-based helper. It is powerful enough for everyday development and learning tasks, but it also keeps a deliberately narrow scope so the result stays fast and readable.

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.

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 these limitations in mind will help you interpret the results accurately and avoid misdiagnosing encoding issues.

Code points vs. UTF-16 code units

This tool focuses on how a code point is represented in UTF-16, the encoding used by JavaScript strings and many APIs. That distinction matters because a code point is an abstract Unicode number, while a code unit is one piece of a concrete encoding.

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

Once you are comfortable with the numeric side of Unicode, you can apply what you learn here directly in code, markup, test fixtures, and debugging sessions. Use the inspector 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 character in another. A small amount of code-point awareness removes a surprising number of text bugs.

Enter a character or code point to see its properties.

Play: Unicode Decoder Rush

Need a faster way to build intuition? This optional mini-game turns the same ideas behind the inspector into a quick arcade challenge. You will match glyphs to code points, spot characters that need surrogate pairs, identify category labels, and recognize UTF-16 units before the timer runs out. It does not change the calculator’s answer; it simply gives you a fun way to practice reading Unicode from more than one angle.

Score0

Time75s

Streak0

ProgressP1 · R0

Best0

Optional arcade mini-game

Unicode Decoder Rush

Click to play. Match characters to code points, catch the moment when emoji switch into surrogate-pair territory, and build a streak before time runs out.

Tap or click the matching tile. On keyboard, press number keys 1 to 6.
Early rounds use characters and U+ notation. Later rounds add decimal values, categories, and UTF-16 pair missions.
Wrong picks cost time, hot streaks boost score, and rush phases make the board faster.

Educational note: the game reuses the same core idea as the calculator. A single Unicode code point can be viewed as a glyph, a decimal number, a hexadecimal identifier, or one or two UTF-16 code units.