ASCII table and UTF-8 converter

How to use

1. Choose what you are starting from. Text encodes the characters you type into UTF-8. Code points takes Unicode scalar values such as U+1F600 (also 0x or \u{...} forms), separated by spaces or commas. UTF-8 bytes in hex or binary decodes bytes into text.
2. For text and code points the tool lists, per character, its code point, UTF-8 bytes in hex and binary, byte count and UTF-16 code units, then draws the bit layout for the first few distinct characters: the template (110xxxxx 10xxxxxx) with your payload bits in place of the x's.
3. For bytes the tool decodes strictly, following the well-formed byte ranges in Unicode Table 3-7 (reproduced below). Every problem is listed with its offset, the bytes involved and the reason, and each bad byte or maximal bad run is replaced by U+FFFD the way the Unicode standard recommends.
4. Use the table at the bottom of the page for control characters (names and RFC 20 meanings), printable characters, and decimal, hex and binary codes.

Worked examples

Each result is recomputed by an automated test from the tool's engine. The bit-level derivations below were done by hand from RFC 3629 and compared with the browser's TextEncoder in the tests.

One, three and four bytes: A, euro sign, grinning face

A is U+0041, below U+0080, so it is the single byte 41. The euro sign U+20AC is 0010 0000 1010 1100 in 16 bits. The three-byte template is 1110xxxx 10xxxxxx 10xxxxxx, so the bits split as 0010 | 000010 | 101100, giving 11100010 10000010 10101100 = E2 82 AC. The grinning face U+1F600 is 21 bits, 0 0001 1111 0110 0000 0000; the four-byte template 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx gives 11110000 10011111 10011000 10000000 = F0 9F 98 80.

Two spellings of café

The precomposed é is U+00E9 = 000 1110 1001 in 11 bits; the two-byte template 110xxxxx 10xxxxxx gives 11000011 10101001 = C3 A9.

Typed as the letter e plus the combining acute accent U+0301 it looks identical but is different data: 65 for the e, and U+0301 = 011 0000 0001 gives 11001100 10000001 = CC 81.

From code points

From bytes to text

Reference: the well-formed UTF-8 byte sequences (Unicode Table 3-7)

A byte sequence is valid UTF-8 only if it matches one row. The tool's decoder is tested against this table and against the replacement examples in Tables 3-8 to 3-11.

Reading the rows: after E0 the second byte must be A0 to BF (anything lower would be an overlong form), after ED it must be 80 to 9F (anything higher would be a surrogate), after F0 it must be 90 to BF, and after F4 it must be 80 to 8F (anything higher would be beyond U+10FFFF).

Control characters (0 to 31) and DEL (127)

Names and meanings are from RFC 20 sections 4 and 5.2 (shortened and reworded). The caret notation and C escape columns are common conventions, not part of RFC 20.

Printable characters (32 to 126)

The same 95 characters, in table order. Names follow RFC 20 section 4.2 (a few reworded, for example "Slant" is the slash).

What goes wrong

Real byte sequences that break decoders. The results are the tool's exact output, and the replacement counts for the first four match the examples printed in the Unicode Standard (Tables 3-8 to 3-11), which the tests also run.

C0 AF, an overlong slash

C0 can only begin an overlong two-byte form; AF is then a continuation byte with no lead. Unicode Table 3-8 lists exactly two U+FFFD for C0 AF.

Latin-1 bytes read as UTF-8

The Latin-1 text "é café" is E9 20 63 61 66 E9. E9 would start a three-byte sequence, but the next byte (20) is not a continuation byte, so E9 is replaced alone; the same happens at the end, where E9 is truncated.

An emoji cut off after three bytes

F0 9F 98 is the first three bytes of F0 9F 98 80. It is the start of a valid sequence, so the standard replaces the whole truncated prefix with a single U+FFFD, not three (Table 3-11).

A surrogate encoded as three bytes

ED A0 80 is what a naive encoder writes for the surrogate code point U+D800. UTF-8 forbids surrogates (RFC 3629; after ED the second byte must be 80 to 9F), so each of the three bytes becomes its own U+FFFD (Table 3-9).

A lone surrogate in text

JavaScript strings can hold a lone surrogate code unit, but it is not a Unicode scalar value, so it cannot be written in UTF-8. TextEncoder (which takes a USVString) substitutes U+FFFD, bytes EF BF BD, and so does this tool; it also counts it so you notice.

A code point beyond Unicode

Mojibake in the other direction

The UTF-8 bytes of é are C3 A9. Reading them as windows-1252 or Latin-1 shows é; re-encoding that text as UTF-8 gives C3 83 C2 A9, four bytes, which is the classic "double-encoded" form. In the browser, new TextDecoder("windows-1252").decode(new Uint8Array([0xC3, 0xA9])) returns é.

Limits & gotchas

• UTF-8 only. The tool encodes and decodes UTF-8 (and shows UTF-16 code units for reference). Latin-1, windows-1252, Shift_JIS and other legacy encodings are not converted; the page only explains how reading UTF-8 bytes with them goes wrong.
• Code points, not glyphs. The tool lists code points. What a reader sees as one "character" may be several (a letter plus a combining accent, or an emoji sequence joined with U+200D). Each code point is shown separately on purpose.
• No normalisation. The tool does not convert between composed and decomposed forms; it shows the bytes of exactly what you typed. Names and categories are not looked up for every code point; only the ASCII table has names (from RFC 20).
• Input size. At most 20,000 characters or 20,000 bytes. The per-character table shows the first 200 characters and the byte-by-byte table the first 300 entries.
• Pasted text may change. Browsers and editors can convert line endings or replace characters when you paste. If a byte count looks off, paste into the "UTF-8 bytes" mode instead, or check for a hidden trailing newline (LF, 0A).
• Replacement follows Unicode's recommended practice. Other decoders may produce a different number of U+FFFD characters for the same bad bytes; the Unicode Standard says it does not require this practice for conformance. This tool's decoder agrees with the browser's TextDecoder on 20,000 random byte strings in the tests.
• Browser. Tested in a current Chrome only.

FAQ

Sources

• IETF: RFC 3629: UTF-8, a transformation format of ISO 10646 Used for: The byte layouts for one to four bytes, the code point range U+0000 to U+10FFFF, surrogates not allowed, and that decoders must protect against decoding invalid sequences such as the overlong C0 80.
• Unicode Consortium: The Unicode Standard 16.0, chapter 3 (Conformance): Table 3-7 and Tables 3-8 to 3-11 Used for: The well-formed UTF-8 byte ranges (Table 3-7), the definition of ill-formed sequences, and the U+FFFD replacement examples (Tables 3-8 to 3-11) the decoder is tested against.
• Unicode Consortium: UnicodeData.txt, Unicode 16.0.0 Used for: Official character names and the canonical decompositions of U+00E9 (0065 0301) and U+00DC (0055 0308), used for the e + combining acute example.
• IETF: RFC 20: ASCII format for network interchange Used for: The 7-bit code table, the control character names and meanings, and the definition of each control code.
• Wikipedia: ASCII Used for: C and Unix use the null character to terminate strings; Control-Z (SUB) was used as an end-of-file marker; caret notation for control characters.
• WHATWG: Encoding Standard: TextEncoder and TextDecoder Used for: TextEncoder.encode takes a USVString, and TextDecoder returns a USVString, so lone surrogates cannot be encoded. The labels "latin1", "iso-8859-1" and "us-ascii" all name the windows-1252 encoding on the web platform (the table of names and labels).
• WHATWG: Web IDL: the USVString type Used for: USVString corresponds to scalar value strings, which exclude surrogate code points.
• Ecma International / TC39: ECMAScript Language Specification: Number type, bitwise shift operators and BigInt operations Used for: Number is IEEE 754 binary64; Number shifts convert with ToInt32 or ToUint32 and take the count modulo 32; BigInt left and right shift act on an infinite two's complement string; BigInt::unsignedRightShift throws a TypeError; strings are sequences of 16-bit code units.
• MDN Web Docs: TextEncoder Used for: TextEncoder always encodes with UTF-8. Used in the unit tests as an independent oracle for the UTF-8 encoder.

Every document above was opened and read on 2026-10-02. Documentation changes; if a page here disagrees with the current docs, trust the docs and tell us.

The ASCII table's names and control-character meanings are shortened and reworded from RFC 20 sections 4 and 5.2. Caret notation and C escapes (such as \n) are common conventions, not part of RFC 20, and are labelled so.

Related tools

• Hex converter

  Hex, decimal and binary with byte views, big- and little-endian order and byte-list input.

• Number base converter

  Convert between any bases from 2 to 36, with fractions, repeating expansions and the division and weight steps.

• Bitwise calculator

  AND, OR, XOR, NOT and shifts in fixed widths, JavaScript Number and BigInt rules, shown bit by bit.

• Two's complement calculator

  Encode and decode signed integers in 8, 16, 32 and 64 bits, with overflow, sign extension and addition flags.