Reverse Text Generator

Text to Binary and Hex: Inspect UTF-8 Bytes

Compare binary and hexadecimal views of the same UTF-8 bytes and decode only complete valid sequences.

Binary and hexadecimal are two ways to print numeric byte values. This site first encodes text as UTF-8, then displays each byte as eight binary digits or two hexadecimal digits separated by spaces. The units are bytes, not visible characters or Unicode code points. That distinction matters as soon as a non-ASCII symbol appears.

In this guide

Compare one character in both bases

The letter “A” is UTF-8 byte 65 in decimal, shown as “01000001” in binary and “41” in hex. The character “é” in its precomposed form is encoded as two UTF-8 bytes, C3 A9, or 11000011 10101001 in binary. A combining-accent version of the same visible letter has a different byte sequence.

These representations contain equivalent byte information but use different digits and lengths. Hex is compact for byte inspection; binary makes individual bits visible. Neither form by itself explains what the bytes mean without an agreed character encoding.

Input
A
Output
Binary: 01000001; Hex: 41

Decode complete bytes

Decode mode requires space-separated groups: exactly eight bits per binary byte or two hexadecimal digits per hex byte. It then decodes the resulting byte sequence as UTF-8 with fatal error handling. A partial group, invalid digit, or invalid UTF-8 sequence produces an error.

For example, “C3 A9” in hex decodes to “é.” A lone C3 is incomplete UTF-8 and should fail. This is preferable to silently substituting a replacement character when you are diagnosing an encoding problem.

Keep bytes distinct from code points

Unicode Inspector shows a character’s U+ code point. Text to Hex shows the bytes produced by UTF-8 encoding that character. For ASCII letters the values can look similar, which makes the distinction easy to miss. For “é,” U+00E9 is a code point label, while C3 A9 is its UTF-8 byte sequence.

Character Counter adds another view: grapheme clusters, code points, and UTF-16 units. Choose the representation that matches the protocol or bug you are investigating instead of comparing unlike units.

Use byte views for debugging

Paste a short sample, record its code points and UTF-8 bytes, and test the reverse conversion. If a round trip fails, check whether the source bytes actually use UTF-8 and whether every byte was included. Binary and hex output are representations, not encryption or compression.

When comparing two byte dumps, first check whether they represent the same normalization form. A visually identical accented word can have different UTF-8 sequences when one source uses a precomposed character and another uses a combining mark. The hex tool makes that difference visible. Do not “fix” it by editing bytes blindly; inspect the code points and normalize text only when the receiving system’s contract calls for it.

Hexadecimal output is also easy to confuse with a Unicode escape. The string “C3 A9” is two byte values in this tool, while “U+00E9” names one code point. Both can refer to the same precomposed character through UTF-8, but they are not interchangeable inputs. Label byte dumps and code-point lists clearly when sharing a debugging example.

  • Binary: eight digits per byte.
  • Hex: two digits per byte.
  • Both decode to UTF-8 text here.

Frequently asked questions

Why does é use more than one byte?

UTF-8 encodes that precomposed non-ASCII code point as two bytes, C3 A9.

Can I enter unspaced hex?

No. This decoder expects two-digit bytes separated by whitespace.

Is a Unicode code point a byte?

No. A code point is an abstract character number; UTF-8 encodes it into one or more bytes.

Try the related tools

Further reading