Skip to content
Lizely

Hex to Text Converter

Parse hexadecimal bytes with explicit separator and 0x-prefix rules, then decode only complete valid UTF-8 without silent replacement.

Privacy: your files never leave your device. All processing happens locally in your browser.

How to use

  1. 1.Paste continuous even-length hex groups or exact 0xNN byte tokens, then choose which ASCII separators and prefixes are permitted.
  2. 2.Decode with fatal UTF-8 validation; correct any reported odd nibble, mixed syntax, invalid byte sequence, or budget error.
  3. 3.Review the decoded text and byte count, then copy the text if the browser grants clipboard access.

About Hex to Text Converter

Hex to Text converts hexadecimal byte notation into UTF-8 text entirely in the current browser tab. Paste continuous pairs such as 48656c6c6f, whitespace-separated groups such as 48 65 6c 6c 6f, or explicit per-byte tokens such as 0x48 0x65 0x6c 0x6c 0x6f. Choose whether ordinary ASCII whitespace separators and 0x prefixes are allowed, then decode. Successful text is displayed in a read-only field and can be copied. No source bytes, decoded characters, or clipboard content are uploaded to Lizely.

The accepted syntax is deliberately narrower than an arbitrary programmer expression. In plain mode, every group must contain only hexadecimal digits 0–9, A–F, or a–f and must have an even number of digits. A group may contain several bytes, so 4869 and 48 69 are both valid when whitespace separators are enabled. A separator never repairs an incomplete nibble: 4 8 is rejected rather than silently becoming 48. Odd-length input, commas, dashes, colons, brackets, escapes, comments, unit labels, and non-hexadecimal letters are errors. Uppercase and lowercase digits produce the same byte values.

Whitespace support is configurable and precisely scoped. Enabled separators are only ASCII space, horizontal tab, line feed, form feed, and carriage return. Other Unicode spacing characters, including a non-breaking space, are rejected instead of being invisibly normalized. When the option is disabled, any of those ASCII whitespace characters is also rejected. Raw input is never trimmed or rewritten before the 2,000,000 UTF-16 code-unit budget check. Enabled leading or trailing ASCII whitespace is accepted as separation around otherwise valid content, but whitespace-only input remains an error.

The 0x option uses a separate unambiguous mode. If any case-insensitive 0x prefix appears, every token must be exactly 0xNN, where NN is one byte, and tokens must be separated by enabled ASCII whitespace. Plain and prefixed forms cannot be mixed, so 0x41 42 fails. Concatenated prefixes such as 0x410x42, three-digit tokens such as 0x041, one-nibble tokens, commas between tokens, and a bare 0x all fail. If whitespace is disabled, prefixed mode can contain exactly one 0xNN token because there is no permitted token separator. Disabling prefixes rejects prefixed input instead of removing the prefix behind the user’s back.

After strict hexadecimal parsing, the complete byte array is decoded with the browser TextDecoder for UTF-8 and fatal error handling. Fatal mode matters: a default replacement decoder can insert U+FFFD when bytes are malformed, which makes damaged input look like successful text. This tool instead returns an error and no partial output for stray continuation bytes, truncated multibyte sequences, overlong encodings, UTF-8 encodings of surrogate code points, and values above U+10FFFF. It never drops a bad suffix, returns an earlier valid prefix, or inserts a replacement character.

UTF-8 supports one-byte ASCII and valid two-, three-, and four-byte scalar encodings. Golden cases include ASCII, U+00E9, two CJK characters, a supplementary emoji scalar, and the U+10FFFF maximum boundary. Invalid fixtures include a standalone continuation byte, the overlong C0 AF form, a truncated three-byte sequence, an encoded surrogate, a four-byte value above U+10FFFF, and a partial BOM. These checks follow the WHATWG UTF-8 decoder and RFC 3629 rather than a permissive byte-to-code-unit shortcut.

A leading UTF-8 byte order mark EF BB BF is consumed by the standard TextDecoder wrapper because ignoreBOM remains at its default false value. Therefore EF BB BF 41 returns A. The same bytes in the middle of text decode as the actual U+FEFF character and are not removed. A BOM by itself is a valid decode whose visible output is empty, and the interface explains that outcome. Byte 00 is also valid UTF-8 data and becomes U+0000; it is not treated as a C-style string terminator. The copy button is disabled only when the decoded text has no code units.

Budgets are explicit and independent. Raw input may contain at most 2,000,000 UTF-16 code units. Parsed output may contain at most 1,000,000 bytes, and decoded text may contain at most 1,000,000 UTF-16 code units. Each exact limit is accepted and one unit beyond it is rejected with wording that nothing was decoded, returned, or truncated. The parser calculates the byte count before allocating the output array. It never slices an oversized source, ignores extra complete bytes, samples the text, or caps a number silently. Prefixed notation contains more source characters per byte, so it can reach the raw-input budget before the byte budget; that is expected and reported.

Editing the hex input, changing either syntax option, or starting a new decode immediately clears the previous output, error, copied state, and copy timer. Clipboard writes are asynchronous, so every attempt receives a generation number. A late permission success or failure cannot update the interface after input or option changes, a newer copy starts, or the component unmounts. Failed clipboard access leaves the valid decoded text selectable and shows a manual-copy instruction. Clipboard permission depends on the browser and secure-context policy.

This tool decodes UTF-8 only. It does not guess Windows-1252, ISO-8859-1, UTF-16, Shift_JIS, or another legacy encoding, because silent guessing can change byte meaning. It does not interpret integer literals, reverse byte order, remove nulls, evaluate escapes, parse a hex dump with addresses, decrypt data, or execute decoded text. For a formatted memory dump, first extract only its byte column using an appropriate trusted workflow. For binary rather than hexadecimal input, use Binary to Text; for Base64 transport data, use Base64 Encode and Decode.

The WHATWG Encoding Standard is the primary source for the browser UTF-8 decoder, fatal error mode, BOM wrapper behavior, and TextDecoder API. RFC 3629 independently defines the valid UTF-8 sequence ranges and Unicode scalar ceiling. MDN cross-checks the TextDecoder constructor options exposed in browsers. Ten executable external golden cases cover ASCII, multibyte characters, supplementary planes, BOM positions, and NUL, while adversarial tests cover syntax mixing, odd nibbles, Unicode whitespace, invalid UTF-8 boundaries, and exact budget edges.

Methodology & sources

Check the 2,000,000-code-unit raw budget before parsing. Detect prefixed mode when a case-insensitive 0x occurs. Plain mode accepts only even-length hexadecimal groups separated by optionally enabled ASCII HT, LF, FF, CR, or space. Prefixed mode requires every token to be exactly 0xNN and forbids mixing. Calculate and validate the 1,000,000-byte output budget before Uint8Array allocation. Decode the complete array with new TextDecoder('utf-8', { fatal: true }) so invalid sequences return no partial or replacement text; retain the default leading-BOM behavior. Validate the 1,000,000-code-unit text budget. On any edit or option change, invalidate result, error, copy job, and timer. Guard Clipboard API completion with generation and alive refs.

Frequently asked questions

Which hexadecimal formats are accepted?
Plain groups must contain an even number of hex digits. When enabled, ASCII whitespace may separate groups. If any 0x prefix is used, every whitespace-separated token must be exactly 0xNN.
What happens when the bytes are invalid UTF-8?
The entire decode fails. Fatal TextDecoder mode prevents replacement characters and prevents a valid prefix from being returned as partial success.
Why did a leading EF BB BF disappear?
The standard UTF-8 TextDecoder wrapper consumes a leading byte order mark by default. The same U+FEFF sequence in the middle of text is preserved.
Is my hexadecimal or decoded text uploaded?
No. Hex parsing, byte allocation, fatal UTF-8 decoding, display, and clipboard preparation all happen locally in the current tab.

Related tools

Encoding & Crypto guides

View all