Hex Encoder Decoder
Encode UTF-8 text as hexadecimal bytes and decode valid UTF-8 hex without silent replacement.
Decode accepts compact hex, spaced bytes, colon or hyphen separators, a single 0x prefix, repeated 0xHH bytes, and \\xHH byte notation.
Output
Encoded hex or decoded UTF-8 text will appear below.
Encoded or decoded output will appear here.
Hex is a notation for bytes; readable text still needs an encoding
One hexadecimal digit represents four bits, so two hex digits describe one byte from 00 through ff. That byte does not inherently mean a letter. The meaning appears only when software interprets the byte sequence using an encoding. Encoding and decoding here both use UTF-8: text is first encoded to UTF-8 bytes, and decoded hex must form a valid UTF-8 byte sequence before it is shown as text.
That distinction matters when you inspect network payloads, log dumps, file signatures, database blobs, or debugger memory. Hex can faithfully represent arbitrary bytes, while only some byte sequences are text. A PNG header, compressed buffer, encrypted payload, or random binary value should not be expected to decode into meaningful UTF-8.
Watch the bytes grow beyond ASCII
ASCII characters occupy one byte in UTF-8, while other code points use multi-byte sequences. Reading the groups as bytes makes the difference visible:
A U+0041 → 41 é U+00E9 → c3 a9 ✓ U+2713 → e2 9c 93 😀 U+1F600 → f0 9f 98 80
The spaces in encoded output are presentation separators only. Removing them leaves the same byte sequence: c3a9 andc3 a9 describe the same two bytes.
Valid hex and valid UTF-8 are two separate checks
ff is perfectly valid hexadecimal, but a lone ff byte is not valid UTF-8 text. A replacement-mode decoder could silently show U+FFFD instead, hiding the fact that the original bytes did not decode cleanly. Decoding uses the browser's UTF-8 TextDecoderin fatal mode so malformed UTF-8 becomes an explicit error rather than altered output.
Encoding behavior: WHATWG Encoding Standard — TextDecoder.
Two strings can look identical and still produce different hex
Unicode allows some visible text to be represented by more than one sequence of code points. For example, composed é (U+00E9) becomesc3 a9 in UTF-8, whilee followed by COMBINING ACUTE ACCENT (U+0065 U+0301) becomes65 cc 81. They can render the same, but byte comparisons, signatures, hashes, cache keys, and protocol fields can see different data.
The encoder does not normalize your text before converting it. When a system requires a normalization form, apply that rule explicitly and consistently. See Unicode Standard Annex #15 — Normalization Forms.
Hex is not encryption or redaction
Hex only changes how bytes are written. Anyone can reverse it without a key. Converting an API token, password, session value, or private payload to hex does not protect the underlying data, and decoding an unfamiliar dump may reveal sensitive text. Treat the output with the same confidentiality as the original bytes.