Unicode to Text: Decode Code Points and Escape Codes

Converting Unicode to text usually means turning written character codes or escape sequences into the characters they represent. For example, U+004F U+004B becomes OK, while the JSON string "\u004F\u004B" represents the same two letters. The correct conversion depends on how those values are written.

Unicode already describes text. What looks unreadable is often a notation around that text: hexadecimal code points, JSON escapes, or HTML character references. Raw UTF-8 bytes are another kind of input and require a different operation.

A good conversion starts by identifying that format rather than trying random settings. This article explains how to recognize the common forms, use a suitable converter, decode JSON correctly, and check supplementary characters such as emoji. It also covers misleading number-base choices, missing glyphs, and situations where the output is valid but still looks wrong.

Read the Notation Before Converting

To convert Unicode codes into readable text, identify their notation, parse each value using the correct number base, and construct the corresponding characters. Decode complete JSON strings with a JSON parser. For U+ lists, validate Unicode scalar values before joining them. Byte sequences need their documented character encoding instead.

Match Each Input Format to Its Parser

A Unicode converter may accept several input formats, but those formats do not all follow the same grammar. These examples represent the euro sign:

U+ notation labels a code point; a JSON parser does not interpret it inside an ordinary string as an instruction. Likewise, JSON does not support JavaScript's braced \u{...} escape syntax.

Be especially careful with bare numbers. Decimal 100 represents lowercase d; hexadecimal 100 represents Ā. Both values are valid, so a converter cannot resolve that ambiguity from numeric validity alone. Set the base explicitly or retain the prefix.

HTML character references also have HTML-specific handling rules. They should not be treated as interchangeable with strict code-point lists, particularly for invalid or special numeric values. Choose a parser that matches the actual source format.

Convert Code Points into a Short Message

Consider this explicit U+ list:

U+004F U+004B U+0020 U+2713

A converter reads each hexadecimal value and returns the corresponding character in sequence:

The output is OK ✓. The space comes from U+0020; it is not merely a visual separator between codes.

Each entry should be interpreted as a complete code point. Do not split 2713 into byte pairs 27 13. That would describe two different values and lose the intended check mark.

Case within the hexadecimal digits does not change the number: U+20AC and U+20ac identify the same code point. However, syntax details such as accepted prefixes and separators depend on the converter. A tool may require spaces, while another accepts commas or preserves surrounding words.

For a code-point-only list, a useful check is to convert the resulting string back into code points and compare the sequence. This catches omitted spaces or reordered values that may be hard to notice in the rendered output.

Choose an Online Conversion Mode That Fits

When using a Unicode to text tool, select the input notation before pasting a long document. A mode designed for U+ lists may reject otherwise valid JSON escapes, and an escape decoder may deliberately leave U+ labels unchanged.

Use this workflow:

1. Identify whether the source contains code-point labels, escapes, character references, or bytes.
2. Choose the corresponding decode mode and number base.
3. Paste one known example to confirm the interpretation.
4. Convert the full input and inspect any rejected tokens.
5. Copy the output as plain text and check it in the destination application.

For example, test U+2713 before submitting a long U+ list. For a JSON document, use its actual parser rather than deleting braces, quotes, and backslashes by hand.

Mixed content needs special care. In Item 100: U+2713, the number 100 may be ordinary prose. A parser that decodes every bare number can change the sentence accidentally. Prefer explicit prefixes or a mode that recognizes only the specified escape forms.

Also check whether a tool preserves malformed tokens, skips them, or stops with an error. Silent omission can produce plausible but incomplete output. For sensitive material, verify the particular tool's processing behavior or use local code; privacy claims cannot be inferred from the converter's name.

Why Emoji Need More Than Four Hex Digits

The familiar \uXXXX form contains exactly four hexadecimal digits. In JSON, it represents one UTF-16 code unit. Characters beyond the Basic Multilingual Plane need two such escapes, called a surrogate pair.

For example, the rocket character has code point U+1F680. Its JSON escape representation is \uD83D\uDE80. A compatible JavaScript string can instead use \u{1F680}. Those notations refer to the same character through different syntax rules.

A Unicode escape decoder must recognize which grammar is being used. Reading \u1F680 as a five-digit JSON escape is incorrect: the four-digit escape ends after 1F68, leaving 0 as a separate character.

A high surrogate lies in D800–DBFF, and its matching low surrogate lies in DC00–DFFF. An isolated surrogate is not a Unicode scalar value. Some JSON parsers still accept unpaired surrogate escapes, so successful JSON parsing alone does not guarantee well-formed Unicode text.

There is another counting issue: one visible emoji can contain several code points. Joining characters, modifiers, and variation selectors may affect the final appearance. Converting code points correctly does not imply that every visible symbol corresponds to one number.

Turn Escaped JSON into Readable Values

JSON Unicode escapes should be decoded as part of a valid JSON string or document. This preserves the distinction between actual escape syntax and text that merely contains a backslash.

Python: Parse the Document, Then Read the Field

import json
source = r'{"label":"Total: \u20AC9"}'
data = json.loads(source)
label = data["label"]
print(label)  # Total: €9

The Python raw string preserves the backslash sequence for json.loads(). After parsing, the field contains the euro sign itself. For this example, no manual replacement or byte decoding is required.

For reliable Unicode interchange, check decoded strings for unpaired surrogates if the receiving system requires well-formed text. Apply that validation to every relevant string field, rather than assuming a parser enforces it automatically.

JavaScript: Use JSON.parse(), Not Code Evaluation

const source = String.raw`{"label":"Total: \u20AC9"}`;
const label = JSON.parse(source).label;
console.log(label); // Total: €9

JSON.parse() reads JSON data. There is no need to run pasted input as JavaScript with eval().

Distinguish One Escape Layer from Two

These JSON documents intentionally produce different strings:

{"label":"\u20AC"}
{"label":"\\u20AC"}

The first field becomes €. The second becomes the six literal characters \u20AC, because the doubled backslash represents a backslash character inside the value.

Do not repeatedly unescape until the result looks right. A literal escape may be documentation, a regular-expression fragment, or intended user content. Decode another layer only when the source contract says that the field contains another serialized representation.

Build a Strict U+ List Parser

For converting Unicode code points to text from a known U+ list, a small parser can make the accepted input explicit. This JavaScript function accepts whitespace-separated tokens such as U+004F U+004B U+0020 U+2713:

function decodeCodePointList(input) {
  const source = input.trim();
  if (!source) return "";
  return source.split(/\s+/).map(token => {
    if (!/^U\+[0-9a-f]{4,6}$/i.test(token)) {
      throw new Error(`Unsupported code-point token: ${token}`);
    }
    const value = Number.parseInt(token.slice(2), 16);
    if (value > 0x10FFFF || (value >= 0xD800 && value <= 0xDFFF)) {
      throw new Error(`Not a Unicode scalar value: ${token}`);
    }
    return String.fromCodePoint(value);
  }).join("");
}
console.log(decodeCodePointList("U+004F U+004B U+0020 U+2713"));
// OK ✓

The format check rejects unsupported punctuation instead of stripping it. The value check rejects numbers above U+10FFFF and the surrogate range. This is scalar-value validation, not proof that a value has an assigned visible character.

String.fromCodePoint() supports supplementary code points. Its built-in range checks do not exclude surrogate values, which is why this function adds that check itself. A function based on String.fromCharCode() would operate on UTF-16 code units instead.

This example deliberately does not accept decimal numbers, HTML references, JSON documents, or unprefixed hexadecimal. Add another clearly defined parser when the source requires one. Broadening a regular expression without defining the grammar can make ambiguous input harder to diagnose.

Separate Unicode Values from Encoded Bytes

A code point identifies a character within Unicode. A character encoding defines how its text is represented as code units or bytes. The euro sign makes the distinction visible:

For the code point, hexadecimal to decimal conversion gives:

20AC₁₆ = 2 × 4096 + 0 × 256 + 10 × 16 + 12 = 8364

That calculation changes the written number base. Producing the character requires the additional step of interpreting 8364 as a Unicode code point. Decoding E2 82 AC requires UTF-8 byte rules instead.

For a related number-base query, “hexagon to binary” may be intended to mean hexadecimal to binary. A hexagon is a shape, so the correct conversion term is hex-to-binary. For example, 2F becomes 0010 1111 when each hex digit is expanded to four bits. That operation does not, by itself, decode Unicode characters.

Keep the original representation attached to the data. A bare string such as AC20 does not tell you whether it is one hexadecimal number, two bytes, or a field inside a larger format. The source specification supplies that meaning.

Diagnose Output That Looks Incorrect

A readable-text conversion can fail at parsing, validation, or display. It can also succeed while preserving characters that are intentionally invisible.

A replacement character, U+FFFD, is not the same as a font's missing-glyph box. It can indicate earlier decoding substitution, or it may already be part of the source. Neither changing the font nor decoding escapes again can reliably recover information already discarded.

Combining marks explain some unexpected comparisons. A letter and a following accent can look like a precomposed character while using a different sequence. Unicode normalization can standardize equivalent sequences for a defined task, but normalization is a separate operation from decoding.

Do not apply compatibility normalization such as NFKC merely to make the output look ordinary. It can remove distinctions that matter. Preserve the original string and choose a normalization policy suited to matching, search, or display requirements.

Likewise, decoding does not translate another language into English or guarantee ASCII-only output. If the decoded text is Arabic, Greek, or Chinese, a correct converter preserves those characters rather than replacing them with English letters.

Answers to Common Unicode Conversion Questions

How do I turn Unicode codes into readable text?

Identify the code notation first. Convert U+ values using a code-point parser, decode JSON escapes with a JSON parser, and handle HTML character references with an HTML-aware decoder. If the input is encoded bytes, use the source encoding. Confirm a known sample before applying the same method to a large file.

Is Unicode the same thing as UTF-8?

Unicode defines characters and code points; UTF-8 is one encoding used to represent Unicode text as bytes. A value such as U+20AC identifies the euro sign, while E2 82 AC is its UTF-8 byte sequence. A code-point converter and a UTF-8 decoder therefore solve different input problems.

Can I convert Unicode into English or ASCII?

Decoding reveals the characters represented by the source. Translation changes language, while transliteration approximates writing in another script. Neither happens automatically during decoding. An ASCII-only export also cannot preserve every Unicode character directly, so choose an explicit escaping or replacement policy if the destination truly requires ASCII.

Why do Unicode escapes remain after JSON parsing?

The source may intentionally contain an escaped backslash, leaving literal escape-looking text in the parsed field. Alternatively, the visible value may be a debugging representation rather than the actual string. Inspect the original JSON and the resulting character sequence. Parse a second layer only when the field's documented format requires it.

Can I convert emoji from Unicode codes?

Yes. Use a converter that supports supplementary code points or valid UTF-16 surrogate pairs, depending on the input notation. A single four-digit escape cannot represent every emoji. Some displayed emoji also require several code points, so preserve the entire sequence, including any joiners, modifiers, or variation selectors.

Why does a valid Unicode character appear as a box?

A missing-glyph box often means the font or rendering environment lacks support, even though the underlying value is preserved. Inspect the code point and test a suitable font or application. Unassigned and private-use values need additional context, so a valid scalar value does not guarantee a recognizable symbol on every device.

Should I normalize text after converting it?

Only when the downstream task calls for a defined normalization form. NFC can help compare canonically equivalent sequences, while compatibility forms can change distinctions beyond canonical equivalence. Keep an original copy when exact preservation matters. Normalization does not repair a wrong encoding choice, translate text, or restore characters lost before conversion.

Keep Characters and Their Representation Distinct

Reliable Unicode to text conversion begins with the input grammar. Recognize the notation, use the matching parser, validate the values, and inspect the resulting sequence when appearance is misleading. Keeping those steps separate lets you recover the intended text without accidentally changing its language, character boundaries, or serialization layers.