Text to hex encoding produces the hexadecimal representation of each UTF-8 byte that makes up a string of text, and a reliable text to hex alternative must return those exact bytes rather than guess at the encoding. The browser-based Text To HEX tool follows the WHATWG Encoding Standard through the browser's built-in TextEncoder API, so ASCII becomes one byte, common Latin accented characters become two, most BMP characters become three, and supplementary Unicode scalars become four. Each byte is then written as two hexadecimal digits, with three formatting choices over the same byte array: continuous pairs such as 4869, space-separated pairs such as 48 69, or 0x-prefixed tokens such as 0x48 0x69. Letter case for a through f can be switched, no BOM is ever prepended, and every step including sizing, formatting, display and clipboard preparation runs locally in the current tab, so input and output never leave the browser.
Why people search for a text to hex alternative
Anyone who has converted strings of text to hexadecimal knows that the result is only as trustworthy as the encoding step behind it. Many online converters truncate large payloads, drop high-BMP or supplementary characters, prepend a byte order mark without saying so, or limit output to a few hundred bytes. Some upload the input to a remote server for processing, which is a non-starter when the payload is private. Command-line tools like xxd or hexdump behave differently across platforms, and Windows-1252 fallback tools can silently map characters that the caller expected to remain as plain UTF-8. A search for a text to hex alternative usually means the user has hit one of these problems and wants a deterministic, local, exact-UTF-8 path with predictable formatting options.
The same frustrations drive readers to look for a local alternative to remote API-based converters in adjacent categories. Whether the goal is binary, Base64 or hex, the underlying desire is the same: a converter whose behavior matches a published standard, whose limits are stated plainly, and whose output can be verified byte by byte.
What this alternative does differently
The Text To HEX tool is anchored to the standard TextEncoder.encode method defined by the WHATWG Encoding Standard, which means UTF-8 output is produced by the same code path that powers modern web platforms rather than by a custom codec. The encoder is pair-aware for JavaScript's UTF-16 strings: a valid high-plus-low surrogate pair represents one supplementary Unicode scalar and is encoded normally, while an isolated high or low surrogate is replaced with U+FFFD before UTF-8 encoding, producing the byte sequence EF BF BD. The result panel counts and visibly warns about those replacements, because decoding the bytes back cannot recreate the original isolated code units.
Three further behaviors distinguish this alternative from the average web converter. First, the encoder does not prepend a UTF-8 BOM; if the input contains a literal U+FEFF, those bytes are encoded as data. Second, input is not normalized: combining marks remain decomposed unless the input was already composed, so the sequence e followed by U+0301 produces 65 CC 81 rather than being silently rewritten to U+00E9. Third, the formatted output length is calculated up front and checked before the large string is built, so a one-code-unit overflow is rejected with an explicit message instead of producing a truncated result.
How to encode text with this text to hex alternative
- Open the Text To HEX tool and enter the text you want to convert in the input field, including any Unicode, whitespace or NUL data the browser field can hold.
- Pick an output style: continuous pairs such as 4869, space-separated pairs such as 48 69, or 0x-prefixed tokens such as 0x48 0x69.
- Select lowercase or uppercase hexadecimal digits. Case changes only the letters a through f; byte values and the lowercase 0x marker stay the same.
- Run the encoder and review the byte count, the formatted output length, and any isolated-surrogate replacement count shown in the result panel.
- Copy the complete hexadecimal output using the copy control. If clipboard access is denied, the read-only result remains available for manual selection.
- Edit the input, change the format or case, or start a new encode to clear the previous output, byte statistics, replacement warning and copy status.
Choosing the right output format
The three output formats are presentation choices over the same UTF-8 byte array, so changing format or letter case never changes the encoded bytes. They do change the formatted output length, which is calculated as 2n for continuous pairs, 3n minus 1 for space-separated pairs, and 5n minus 1 for 0x-prefixed tokens, where n is the number of UTF-8 bytes. For a two-byte input like Hi, that works out to four code units for plain (4869), five for spaced (48 69) and nine for prefixed (0x48 0x69). Plain is the most compact and is easy to paste into a single line of source code. Spaced is friendlier to visual scanning because each byte stands on its own. Prefixed is the safest choice for code generators, log analyzers and any consumer that expects literal 0xNN tokens.
| Format | Formula (n bytes) | Example for Hi | Best for |
|---|---|---|---|
| Continuous pairs | 2n | 4869 | Compact dumps, source-code literals |
| Space-separated | 3n − 1 | 48 69 | Visual scanning, debugging |
| 0x-prefixed tokens | 5n − 1 | 0x48 0x69 | Token-aware parsers, assembly, config files |
The same formulas govern the hard output budget. Because formatted output is capped at 4,999,999 UTF-16 code units, a request that exceeds the calculated length for the chosen format is rejected before any string is built. That is the difference between one million ASCII input characters in 0x-prefixed format, which produces exactly 4,999,999 output code units and is accepted, and one extra input code unit or output code unit, which is rejected with an explicit message.
Unicode edge cases other tools get wrong
Web text often contains characters that lie outside ASCII, and a hex encoder that fumbles those characters produces a result that cannot be decoded back. The four reference cases in this alternative's documentation show the expected behavior end to end: U+0041 becomes 41, U+00E9 becomes c3a9, U+4F60 becomes e4bda0, and U+1F600 becomes f09f9880. Each of those mappings is one, two, three and four bytes respectively, which matches the standard UTF-8 widths. Several online converters stop at three bytes and would corrupt U+1F600 or replace it with question marks; this alternative uses the standardized TextEncoder conversion to a scalar-value string defined by the WHATWG Encoding Standard, so supplementary characters survive intact.
Other edge cases are honored literally rather than normalized. NUL U+0000 becomes the byte 00, CR, LF, tabs and spaces are encoded in their supplied order, and editing the input or switching format does not trigger newline conversion, trimming, case folding, escape parsing or locale-aware rewriting. The tool is therefore a faithful recorder of the exact bytes the user typed. The only characters that do not round-trip exactly are an internal U+FEFF in the input and an isolated UTF-16 surrogate, both of which are flagged in the result panel so the caller can correct the input or accept the documented behavior of the chosen decoder.
Hard limits: what the tool accepts and rejects
Two budgets are explicit. The input field may contain at most 1,000,000 UTF-16 code units, and the formatted output may contain at most 4,999,999 UTF-16 code units. One input code unit or one output code unit over the corresponding validator is rejected with an explicit message, which means the tool never silently truncates or samples content. The full text is encoded before formatting, the required output size is calculated from the byte count and selected syntax, and that calculation is checked before the large formatted string is built.
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. Formatting then proceeds in bounded byte chunks and joins every chunk, which reduces temporary allocation spikes without changing or limiting output, and the final string length is checked against the validated prediction as a defensive invariant. The companion Hex to Text Converter 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 text not begin with U+FEFF. With well-formed Unicode and that one leading-BOM caveat, the text to hex to text round trip is exact.