Hexadecimal ↔ Text Converter

Features

• Both directions: text to hex, and hex back to text
• Accepts spaces, colons, hyphens, commas, and 0x or \x prefixes on input
• Output separators: spaces, colons, none, or the 0x prefix, with optional uppercase
• UTF-8 throughout, so Chinese, Japanese and emoji round-trip correctly
• Shows the byte count, making multi-byte characters obvious
• Invalid UTF-8 byte sequences are reported instead of silently replaced
• Input that reads as hex is decoded as hex, and the direction can be pinned manually
• Every result line copies on its own, so taking just the hex is one click

How to use

1. Paste a hex string or some text
2. The result appears as you type — hex-looking input is decoded as hex, and the result says so
3. Switch the direction to Text → Hex or back if you need the other reading
4. Pick an output separator and copy the line you need

FAQ

Why does an input like beef fail?

Because it reads both as two bytes (0xBE 0xEF) and as a piece of text. The tool tries the former by default, and those two bytes are not valid UTF-8 — so it reports the problem and points out the alternative. Switch the direction to Text → Hex and you get 62 65 65 66, the hex form of those four letters.

Why is the hex form of Chinese text so long?

A CJK character takes three bytes in UTF-8, and each byte is two hex characters — six characters per character. The byte count row exists so you can check this directly: six hex characters per CJK character, eight per emoji (four bytes).

Can it decode hex that came from GBK or GB2312?

No — decoding is UTF-8 only. Most GBK byte sequences are not valid UTF-8, so the tool tells you exactly that instead of showing mojibake. Falling back to replacement characters would leave you with text that looks fine and is in fact corrupted.

Is my input uploaded anywhere?

No. The conversion happens in the browser and the page sends no requests — hex strings often carry keys, tokens or protocol data, and none of it leaves the machine.