How to Find Unicode Characters, Code Points, and UTF-8 Bytes Online

Overview

Unicode gives characters stable numeric identities called code points. A code point is written in hexadecimal form, such as U+00A9 for the copyright sign, U+20AC for the euro sign, or U+1F600 for the grinning face emoji. Looking up the visible character is often the fastest way to discover whether two strings only appear identical or are actually different.

A browser-based Unicode character lookup tool is useful when you need to:

• Identify an unfamiliar symbol or script.
• Find the exact Unicode code point and character name.
• Check the character’s Unicode block and general category.
• View the UTF-8 bytes sent through an API, file, or database connection.
• Copy a safe escape sequence for JSON, JavaScript, HTML, CSS, or another language.
• Investigate why searching, sorting, validation, or string length gives an unexpected result.

The important distinction is that a visible character, a Unicode code point, an encoded byte sequence, and a user-perceived symbol are related but not interchangeable. A good Unicode inspector lets you examine each layer separately.

Core framework: character, code point, and encoding

1. Start with the exact input

Paste the character directly into a Unicode inspector instead of relying on its appearance or typing a replacement from memory. This matters for punctuation, whitespace, emoji, accented letters, and characters from visually similar scripts. For example, a standard hyphen-minus (U+002D), en dash (U+2013), and em dash (U+2014) may look related but have different meanings and byte sequences.

For a useful result, inspect the smallest relevant unit first. If a full sentence produces several results, isolate the suspicious character and then inspect the surrounding text separately. This makes invisible characters, combining marks, and line separators easier to spot.

2. Read the code point and Unicode metadata

The code point is the primary identity to record. Most tools display it in hexadecimal notation, prefixed with U+. They may also show the official character name, Unicode block, script, and general category.

The block gives a broad range such as Basic Latin, Latin-1 Supplement, Currency Symbols, or a particular emoji-related range. A block is useful for orientation, but it is not a complete description of how a character behaves. For a deeper range-based lookup, see the Unicode block reference.

The general category can help distinguish letters, numbers, punctuation, symbols, marks, separators, and control characters. Combining marks deserve particular attention: they may appear attached to a preceding letter but remain separate code points.

3. Check UTF-8 bytes separately

UTF-8 is an encoding that represents Unicode text as bytes. The same character has one code point but can have a one-, two-, three-, or four-byte UTF-8 representation. For example:

• A is U+0041 and encodes as 41.
• © is U+00A9 and encodes as C2 A9.
• € is U+20AC and encodes as E2 82 AC.
• 😀 is U+1F600 and encodes as F0 9F 98 80.

These bytes are what you may see in a hex dump, network payload, or encoded file. They are not interchangeable with the code point. If an application displays replacement characters or rejects input, comparing the expected UTF-8 bytes with the bytes actually received can narrow down the problem.

4. Choose an escape format for the target context

Escape syntax depends on the language and context. For example, a JSON string can represent the copyright sign as \u00A9. JavaScript can use \u00A9 or, where supported by the syntax, the code-point escape \u{00A9}. An astral character such as the grinning face can be written in modern JavaScript as \u{1F600}. JSON commonly represents it with a UTF-16 surrogate pair: \uD83D\uDE00.

Do not copy an escape sequence without checking where it will be interpreted. A JSON escape, a URL percent-encoding, an HTML character reference, a CSS escape, and a programming-language string literal follow different rules. If the character is being placed in a URL, consult the guide to encoding and decoding non-ASCII URL characters.

Practical examples

Diagnosing two versions of “é”

The character é can be represented as a single precomposed code point, U+00E9, or as the letter e followed by a combining acute accent: U+0065 U+0301. They may render the same way, but they are different sequences before normalization.

An inspector helps you answer three questions:

1. Does the input contain one code point or two?
2. Do the UTF-8 bytes differ?
3. Should the application normalize the text before comparing or storing it?

If equivalent-looking text must compare consistently, read Unicode normalization explained before choosing NFC, NFD, NFKC, or NFKD. Normalization is a data-handling decision, not merely a display fix.

Finding an invisible character

Suppose two identifiers look identical but one fails a lookup. Paste each value into a Unicode inspector and compare every position. The difference might be a non-breaking space (U+00A0) instead of an ordinary space (U+0020), a zero-width character, a carriage return, or a different dash.

Record the character’s code point rather than copying it into a ticket or test case without explanation. A statement such as “the value contains U+00A0 between the words” is reproducible and easier for another developer to verify.

Checking an emoji or joined symbol

An emoji that appears to be one symbol may contain multiple code points. A family emoji, a skin-tone variant, or a flag can combine base characters, modifiers, variation selectors, and zero-width joiners. The inspector may therefore show several code points for one displayed symbol.

This explains why string length can vary by programming language and why slicing a string at an arbitrary index can split a displayed character. Treat the visible result as a grapheme cluster when the user experience matters, and use a Unicode-aware library or API for cursor movement, truncation, and deletion.

Using the result in a web project

For a web bug, capture the character at four levels: the displayed glyph, the code point sequence, the UTF-8 bytes, and the source representation. Then test the complete path through HTML, JavaScript, form submission, URL encoding, JSON serialization, storage, and rendering. For API and form checks, the Unicode validation guide provides a useful companion workflow.

Common mistakes

• Confusing a code point with UTF-8. U+20AC identifies the euro sign; E2 82 AC is its UTF-8 byte sequence.
• Assuming one visible symbol equals one code point. Combining marks, variation selectors, joiners, and emoji modifiers can create multi-code-point sequences.
• Using character count as a storage-size check. A string’s number of displayed symbols, code points, UTF-16 code units, and UTF-8 bytes can all differ.
• Copying the wrong escape syntax. An escape that works in JavaScript may not work in JSON, CSS, a regular expression, or an HTML attribute.
• Normalizing without understanding the requirement. Normalization can make equivalent text compare consistently, but compatibility normalization may change distinctions that an application needs to preserve.
• Trusting visual similarity. Confusable characters can come from different scripts or code-point ranges. Use a confusables check when identifiers, account names, or security-sensitive text are involved; see the Unicode confusables guide.

When to revisit your Unicode inspection workflow

Keep this workflow available whenever the input changes or a text path is modified. Recheck characters after changing a database connection, API serializer, frontend framework, form validator, URL builder, file export process, or text normalization step. A character that worked in a local fixture may expose a problem when it comes from a real multilingual user input.

It is also worth revisiting the workflow when your team adopts a new language runtime, changes string-handling libraries, adds internationalized routes, introduces new emoji or script support, or updates a browser-based developer tool. Tool interfaces and Unicode data can evolve, while the basic diagnostic sequence remains stable.

For a practical release check, follow these steps:

1. Copy the exact failing character or string.
2. Inspect each code point and note its name, category, and block.
3. Compare the expected and actual UTF-8 bytes if a file, API, or database is involved.
4. Record the correct escape form for the destination language.
5. Check normalization and grapheme behavior if comparison, length, cursor movement, or truncation is involved.
6. Save a minimal regression test containing the original input and the expected result.

Once you separate visible characters, code points, encodings, and escape syntax, Unicode bugs become much easier to describe and reproduce. A character lookup tool is not only a reference utility; it is a compact diagnostic step for text processing across the web stack.