How Hex Encoding Works — Why Developers Convert Strings to Hexadecimal

Core Concepts

What hex encoding actually does

Hex encoding takes raw bytes and represents each byte as a two-character hexadecimal number. A byte is 8 bits (values 0-255), and two hex digits can represent exactly 256 values (00-FF). So the mapping is 1:1 (1 byte → 2 hex chars). For example, the ASCII letter 'A' (decimal 65, binary 01000001) becomes '41'. The Unicode character '中' (UTF-8: e4 b8 ad, 3 bytes) becomes 'e4b8ad'.

Why UTF-8 matters for string → hex conversion

Old tools that only do 'ASCII to hex' produce garbage for any character outside code points 0-127 (every accent, emoji, CJK character, and non-Latin script). A proper string-to-hex converter uses UTF-8 encoding first, then maps each resulting byte to hex. That's why '😀' (4 UTF-8 bytes: f0 9f 98 80) has different hex output than if you used ASCII (which would just fail).

Common hex use cases

1) Debugging network protocol dumps — hex shows the raw bytes your server actually received. 2) Reading SHA-256 hashes — hashes are output as hex because it's the most human-readable dense representation of arbitrary bytes. 3) Memory and disk hex dumps in crash reports and forensics. 4) Embedding binary data in text-only formats (hex is less compact than Base64 but easier to read for small payloads). 5) C/C++ array literals — hex with 0x prefix (0x41, 0x42, ...) is the standard way to embed byte arrays in source code.

Hex vs Base64: compactness vs readability

Base64 encodes 3 bytes into 4 characters (~33% overhead). Hex encodes 1 byte into 2 characters (~100% overhead). Hex is twice the size of Base64 for the same input, but each hex pair maps directly to one byte — you can mentally decode '41' → 'A' without a table. Use hex for hashes, memory addresses, and debugging small binary payloads. Use Base64 for API responses, file transfers, and JWT encoding.

Frequently Asked Questions