Skip to content
Lizely

Text To HEX

Encode text into exact UTF-8 hexadecimal with continuous, spaced, or 0x-prefixed output and explicit Unicode replacement warnings.

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

How to use

  1. 1.Enter text, including any Unicode, whitespace, or NUL data that the browser field can hold.
  2. 2.Choose continuous, space-separated, or 0x-prefixed output and lowercase or uppercase hex digits.
  3. 3.Encode, review byte and replacement counts, then copy the complete hexadecimal output.

About Text To HEX

Text to Hex converts browser text into the hexadecimal representation of its UTF-8 bytes. Enter text, choose continuous pairs such as 4869, space-separated bytes such as 48 69, or per-byte tokens such as 0x48 0x69, and select lowercase or uppercase hexadecimal digits. The complete result includes its UTF-8 byte count and formatted output length and can be copied without uploading input or output to Lizely.

Encoding uses the browser TextEncoder API, which produces UTF-8. ASCII characters occupy one byte, many common Latin characters occupy two, most BMP characters occupy three, and supplementary Unicode scalars occupy four. A hexadecimal byte always uses two digits, so U+0041 becomes 41, U+00E9 becomes c3a9, U+4F60 becomes e4bda0, and U+1F600 becomes f09f9880. Uppercase mode changes only hexadecimal a through f; byte values and the lowercase 0x marker remain the same.

The three formats are presentation choices over the same byte array. Plain format concatenates two digits per byte. Spaced format inserts one ASCII space between byte pairs. Prefixed format writes each byte as 0xNN and separates tokens with one ASCII space. No delimiter is placed before the first token or after the last. Changing format or letter case never changes the encoded UTF-8 bytes, but it does change formatted output length.

TextEncoder does not prepend a UTF-8 byte order mark. Ordinary input begins directly with the first character's bytes. If the input itself contains U+FEFF, that actual character is encoded as EF BB BF because it is data, not because the encoder added metadata. The companion Hex to Text tool consumes a leading EF BB BF under its documented TextDecoder BOM behavior, so an exact round trip through that specific tool also requires that the original not begin with U+FEFF. An internal U+FEFF remains part of the text.

JavaScript strings are UTF-16. A valid high-plus-low surrogate pair represents one supplementary Unicode scalar and TextEncoder encodes it normally. An isolated high or low surrogate is not a Unicode scalar. The standardized conversion replaces each isolated surrogate code unit with U+FFFD before UTF-8 encoding, producing EF BF BD. The result panel counts and visibly warns about those replacements because decoding the bytes cannot recreate the original isolated code units. Exact text-to-hex-to-text round trips require well-formed Unicode, plus the leading-U+FEFF caveat above.

Other data is not normalized or treated as a terminator. NUL U+0000 becomes byte 00. CR, LF, tabs, and spaces are encoded in their supplied order. Combining sequences remain decomposed unless the input was already composed; for example, e followed by U+0301 becomes 65 CC 81 rather than being changed to U+00E9. The tool does not apply Unicode normalization, newline conversion, trimming, case folding, escape parsing, or locale-aware rewriting.

Budgets are explicit. Input may contain at most 1,000,000 UTF-16 code units. Formatted output may contain at most 4,999,999 UTF-16 code units. The exact output boundary is accepted: one million ASCII input characters in 0x-prefixed format produce exactly 4,999,999 output code units. One input code unit or one output code unit over its corresponding validator is rejected with an explicit message. Multi-byte Unicode in a verbose format can reach the output budget before the input budget, and the tool reports that failure instead of switching formats, slicing bytes, dropping a suffix, or sampling content.

The full text is encoded before formatting, then the required output size is calculated from byte count and selected syntax. The limit is checked before the large formatted string is built. Formatting proceeds in bounded byte chunks and joins every chunk; this reduces temporary allocation spikes without changing or limiting output. The final string length is checked against the validated prediction as a defensive invariant.

Editing text, changing format or case, or beginning a new encode clears the previous output, error, byte statistics, replacement warning, copy status, and copy timer. Clipboard writes use generation, mounted-state, and timer-identity guards. A late success or failure from an older permission request cannot restore stale status after an edit, a newer encode, another copy attempt, or unmount. If clipboard access is denied, the complete read-only result stays available for manual selection.

This tool represents UTF-8 bytes; it does not use UTF-16 code-unit values, ASCII-only fallback, Windows-1252, a locale code page, or arbitrary numeric character codes. Hexadecimal is an encoding display, not encryption, hashing, compression, or secret protection. Anyone with the bytes and UTF-8 rules can recover well-formed text, subject to the documented leading-BOM behavior of a chosen decoder.

The WHATWG Encoding Standard defines the UTF-8 encoder and TextEncoder conversion to a scalar-value string. MDN independently documents the browser API and Uint8Array output. Ten executable external golden cases cover ASCII, two-, three-, and four-byte scalars, U+10FFFF, NUL, explicit U+FEFF, combining marks, and line endings. Additional tests cover all formats and cases, isolated-surrogate replacement counts, exact input and output limits, invalid options, and well-formed Unicode round trips.

Methodology & sources

Reject empty input and input above 1,000,000 UTF-16 code units before encoding. Count isolated surrogate code units with pair-aware UTF-16 scanning, then use TextEncoder.encode for standardized scalar-value conversion and UTF-8 bytes. Calculate formatted length as 2n for plain, 3n−1 for spaced, or 5n−1 for 0x-prefixed bytes; reject values above 4,999,999 before building output. Format every byte in bounded chunks with lowercase or uppercase digits and assert actual length matches the validated prediction. Report byte count and isolated-surrogate replacements. Editing options invalidates result and copy state; clipboard completion uses generation, mounted-state, and timer-identity guards. TextEncoder adds no BOM, while explicit U+FEFF is data.

Frequently asked questions

Does TextEncoder add a UTF-8 BOM?
No. It adds no BOM. If the input actually begins with U+FEFF, those character bytes are encoded as data; the companion decoder consumes a leading BOM by its documented policy.
What happens to an isolated UTF-16 surrogate?
The standard TextEncoder conversion replaces each isolated surrogate code unit with U+FFFD, whose UTF-8 bytes are EF BF BD. The result shows a visible replacement count.
Do the three output formats change the bytes?
No. They present the same UTF-8 bytes as continuous pairs, space-separated pairs, or space-separated 0xNN tokens. Case changes only hex letters A–F.
Is my text or hexadecimal uploaded?
No. TextEncoder, sizing, formatting, display, and clipboard preparation all run locally in the current browser tab.

Related tools

Encoding & Crypto guides

View all