Text ↔ Unicode

How to use this text-to-Unicode converter

1. Type any text — including emoji and non-Latin scripts — in the top box.
2. Its Unicode code points (U+XXXX) appear below automatically.
3. Or paste code points in the bottom box to convert back to text.

What is a Unicode code point?

Unicode assigns a unique number to every character in every writing system, plus emoji and symbols — over 149,000 characters as of recent standards. Unlike ASCII's 8-bit limit, Unicode can represent virtually any character used in any language.

Unicode's planes — why code points can range all the way up to U+10FFFF

Unicode organizes its entire space of possible characters into 17 separate "planes," each capable of holding up to 65,536 individual code points. Plane 0, formally called the Basic Multilingual Plane (BMP), covers code points U+0000 through U+FFFF and contains the vast majority of characters used in everyday, common writing — essentially all common Latin, Cyrillic, Greek, Chinese, Japanese, and Korean characters, along with most frequently used symbols. The supplementary planes above it (reaching all the way up to the maximum possible U+10FFFF) hold less commonly needed characters — most emoji actually live in Plane 1, along with historic and rarely used scripts, and specialized mathematical and musical notation symbols. This is exactly why some Unicode characters require more storage space than others even in Unicode's own internal numbering scheme, independent of whatever specific byte-encoding format (like UTF-8) is ultimately used to actually store or transmit that specific character.

Code points versus code units — a subtle but genuinely important technical distinction

A Unicode code point (the abstract number identifying a character, like U+1F600 for a grinning-face emoji) is conceptually distinct from a code unit (the actual concrete storage chunk a specific encoding uses to represent that number). JavaScript strings internally use UTF-16 encoding, where each code unit is 16 bits — which is exactly enough to directly represent any BMP character in a single code unit, but genuinely not enough to represent any supplementary-plane character (like most emoji) in just one. Those specific supplementary characters instead require a surrogate pair — two 16-bit code units combined together representing one single code point — which is exactly why naive JavaScript string operations that assume "one code unit always equals one visible character" can incorrectly split an emoji into two broken, meaningless, disconnected pieces, exactly as covered in more depth on this site's Emoji Picker tool.

Why Unicode had to exist — the genuine, real chaos of competing character encodings it replaced

Before Unicode's creation and widespread adoption, computing genuinely suffered from dozens of separate, mutually incompatible character encoding standards, each one covering only a specific, limited language or region — a text file encoded for Japanese, for instance, was frequently completely unreadable garbage when opened on a system expecting Cyrillic or Western European encoding instead, since the exact same specific numeric byte value meant a genuinely different character depending entirely on which specific encoding scheme was actually being assumed at the time. Unicode was deliberately created specifically to solve this exact interoperability problem once and for all — a single, unified numbering system covering literally every writing system in current and even many historical uses, so that text could finally, genuinely be exchanged reliably between any two systems anywhere in the world without this kind of encoding-mismatch corruption ever silently happening again.

Why the exact same visible character can sometimes have more than one valid code point sequence

A genuinely subtle but real Unicode complexity: some visually identical characters can actually be represented by more than one different, equally valid sequence of underlying code points. The character "é," for instance, can be represented either as one single, pre-composed code point (U+00E9), or alternatively as two separate combined code points — a plain "e" (U+0065) followed immediately by a separate combining acute accent mark (U+0301) — with both sequences rendering as the exact same visible character on screen. Unicode defines specific, formal "normalization forms" (commonly NFC, which prefers the single pre-composed form, and NFD, which prefers the decomposed multi-code-point form) specifically to let software reliably determine that two strings that look visually identical, but happen to use different underlying code point sequences, should still correctly be treated as equal, matching values.

Limitations of this tool

This tool converts text to and from its raw Unicode code points (in standard U+XXXX notation) entirely within your browser, correctly handling supplementary-plane characters like most emoji, as explained above. As the FAQ notes, it shows raw code points specifically, not any particular byte-level encoding like UTF-8 or UTF-16 — for converting text into an actual byte-level encoded format, this site's Base64 tool handles that related but genuinely distinct specific task instead. It also doesn't currently apply Unicode normalization (NFC/NFD conversion as described above) — it shows a code point sequence exactly, precisely as your specific input text is already composed, without altering or normalizing that particular sequence in any way.