Text to Hex Converter — UTF-8 Bytes Both Ways

Real-world use cases

• Read and edit a hex dump while debugging a protocol

  You are staring at a packet capture and need to know what the bytes 48 65 6c 6c 6f actually say. Paste them in decode mode and read "Hello" back. Going the other way, type the reply you want, pick the space separator, and hand the bytes straight to your fuzzer or test harness — no mental ASCII-table lookups, and CJK payloads come out as correct multi-byte UTF-8 instead of mangled single bytes.

• Write a byte-literal string for source code

  You need "Hi" as an escaped literal for a C or Python string. Encode with the \x separator and get \\x48\\x69 ready to paste between quotes, or switch to 0x for an initializer list like 0x48, 0x69. The case toggle matches your project's style, lowercase for most code, uppercase if your linter wants 0xFF. Decode pasted literals back the same way to check what an obfuscated string contains.

• Verify how Chinese or emoji text is actually stored

  A form is double-encoding your Chinese names and you want proof of the real bytes. Paste 中文 and see e4 b8 ad e6 96 87 — the exact UTF-8 a correct database column holds. Compare that against what your API returns and the off-by-a-byte bug becomes obvious. The same works for emoji: 😀 is f0 9f 98 80, one code point spread over four bytes, which is why naive substring code splits it in half.

• Teach or learn how character encoding works

  Encoding clicks once you can watch it. Type one letter and see one byte; add an accent like é and watch it grow to two bytes (c3 a9); add a Chinese character and it jumps to three. Toggle separators and case to see that the bytes are the same, only the notation changes. Share the URL with a student and the exact example reopens for them.

Common pitfalls

• Encoding by character code instead of UTF-8 bytes. A tool that uses charCodeAt gives 4e2d for 中 — that is the Unicode code point, not a byte sequence. The real UTF-8 is e4 b8 ad. If your hex looks two bytes long for a Chinese character, it is wrong; CJK is three bytes each.

• Pasting an odd number of hex digits. Every byte is exactly two hex characters, so 414 cannot decode — one digit is missing, probably a dropped leading zero (09 typed as 9). The tool flags the odd count instead of guessing, so fix the source rather than trusting a partial result.

• Assuming all hex is UTF-8. Bytes captured from a Latin-1 or UTF-16 source will fail to decode here or come out wrong, because the byte boundaries differ. A lone ff or 80 is never valid UTF-8 on its own. Decode in the encoding the bytes were actually written in.

Privacy