Text to Hex

This tool converts text to its hex byte representation in your browser; nothing leaves your machine. For the inverse direction, see hex to text.

How the conversion works

Input:  Hi
Step 1: encode as UTF-8 bytes
         H = 0x48
         i = 0x69
Step 2: each byte as 2 hex digits
         0x48 → "48"
         0x69 → "69"
Output: 48 69

Each byte is 2 hex characters. ASCII characters are one byte each; non-ASCII characters (in UTF-8) are 2-4 bytes each.

What the output looks like

"Hello"
→ 48 65 6c 6c 6f

"café"
→ 63 61 66 c3 a9
   c  a  f  é (UTF-8: c3 a9)

"こんにちは"
→ e3 81 93 e3 82 93 e3 81 ab e3 81 a1 e3 81 af
   こ (3 bytes)   ん     に     ち     は

Common formats (the tool above outputs the first; the others are a find-and-replace away):

• Space-separated bytes — 48 65 6c 6c 6f — readable.
• Continuous string — 48656c6c6f — compact.
• 0x-prefixed comma-separated — 0x48, 0x65, 0x6c, 0x6c, 0x6f — for C/JavaScript array literals.
• Backslash-escaped — \x48\x65\x6c\x6c\x6f — for escape-sequence string literals.

Where you’d use this

Hex byte representation is the practical default for:

• Hex dumps. xxd, hexdump -C — Unix tools that show file contents byte-by-byte. The tool above is a small-input equivalent.
• Network protocol inspection. Wireshark, tcpdump, Postman raw view — all show payloads as hex.
• Embedding bytes in code. \xHH in Python/JavaScript string literals, 0xHH in C arrays.
• Hash digests. SHA-256 of "Hello" is shown as 64 hex characters.
• Color values. CSS colors are 3-byte hex (#RRGGBB). See color converter.
• Cryptographic key material that needs human-readable display.

Hex vs other byte representations

Input: "Hi" (2 bytes)

Decimal:  72 105
Hex:      48 69
Binary:   01001000 01101001
Base64:   SGk=

Hex is the right balance for most byte-level work:

• More compact than binary (2 chars per byte vs 8).
• More readable than decimal (fixed 2-char width vs variable 1-3).
• Less compact than base64 but easier to read and unambiguous.
• Case-insensitive — 48 and 4A and 4a all parse identically.

For machine-to-machine byte transit where size matters, base64 wins. For human inspection, hex wins.

UTF-8 multi-byte sequences

Non-ASCII characters expand to 2-4 bytes:

The first byte’s high bits encode the byte count:

• 0xxxxxxx → 1 byte (ASCII)
• 110xxxxx → 2 bytes
• 1110xxxx → 3 bytes
• 11110xxx → 4 bytes

The tool above always emits UTF-8. For other encodings (Latin-1, UTF-16), bytes differ.

Format conventions in different ecosystems

The tool above emits space-separated lowercase pairs; hex to text reads that form, the continuous form and 0x-prefixed bytes back.

Common pitfalls

• Wrong encoding. Latin-1 vs UTF-8 gives different bytes for characters above U+007F. UTF-8 is the modern default; ensure your input/output align on encoding.
• Mixed case in bytes that should match. 48 and 4a are valid hex; 4A and 4a are equivalent. For comparisons, normalize case first.
• Single-byte assumption. A function that reads “the first byte” of a UTF-8 string and decodes it as text gets the partial first byte of multi-byte characters. Decode as UTF-8 across the full sequence.
• Forgetting separators. 48656C6C6F is one continuous string; some parsers expect spaces. Pick the format the consumer expects.
• Endianness. Hex bytes have no endianness — they’re a byte-by-byte dump. But interpreting four bytes as a 32-bit number requires knowing the byte order. For text encoding, this doesn’t apply.

For the inverse direction, see hex to text. For the alternate compact form, base64 encode. For the binary representation, text to binary.