"Text to hex code" means turning each character of your text into the hexadecimal digits that represent its UTF-8 bytes, with two hex digits per byte, so every character becomes a fixed-width, machine-readable token. For example, the string "Hi" becomes 4869 in continuous form, 48 69 when space-separated, and 0x48 0x69 in 0x-prefixed form, because 'H' is U+0048 (byte 0x48) and 'i' is U+0069 (byte 0x69). Text To HEX does exactly this in your browser, using the WHATWG-standard TextEncoder API to produce exact UTF-8 bytes, then formatting them in whichever of the three styles you pick. It adds no BOM, preserves NUL and whitespace, and shows a byte count plus any isolated-surrogate replacements so the conversion is auditable rather than a black box. Use the result directly to debug a payload, write a unit test, or paste bytes into source code: the hex string is the literal representation of the same UTF-8 byte array, styled for the destination.
What "Hex Code" Actually Means for Text
When you ask for the "hex code" of text, you are asking for the hexadecimal digits that represent each character's UTF-8 byte sequence, with exactly two hex digits per byte. ASCII characters such as 'A' (U+0041) and '0' (U+0030) each take a single byte, so they become two-digit pairs like 41 and 30. Accented Latin letters such as 'é' (U+00E9) take two bytes and become a four-digit pair (c3a9). Most characters in the Basic Multilingual Plane, including Chinese, Japanese, Arabic, and Greek, take three bytes. Supplementary characters, which include most emoji and rare historic scripts, take four bytes.
Because every byte maps to exactly two hex digits, the relationship between input size and output size is mechanical rather than approximate. The catch is that one input character can produce two, three, or four bytes, so the hex string grows with the byte count rather than the character count. A short sentence containing one emoji can produce a longer hex string than an entire paragraph of plain ASCII.
For a quick reference of how each Unicode range maps to bytes and hex digits, the Text to Hex cheat sheet lists the canonical examples side by side.
| Character class | Example | Code point | UTF-8 bytes | Hex digits |
|---|---|---|---|---|
| ASCII | A | U+0041 | 1 | 2 |
| Accented Latin | é | U+00E9 | 2 | 4 |
| Most BMP | 你 | U+4F60 | 3 | 6 |
| Supplementary (emoji) | 😀 | U+1F600 | 4 | 8 |
How to Convert Text to Hex Code
The Text To HEX tool follows the same three-step flow that the WHATWG TextEncoder spec describes, but it wraps the raw API in selectable formatting so you can paste the result directly into a test, a configuration file, or a code literal.
- Enter your text into the input field. Any characters the browser can hold are accepted: ASCII, accented letters, CJK, emoji, whitespace (spaces, tabs, line breaks), and NUL bytes. The tool does not strip, normalize, or trim the input.
- Pick an output style and letter case. Choose continuous for compact bytes (for example 4869), space-separated for human-readable bytes (48 69), or 0x-prefixed for C-style literals (0x48 0x69). Then choose lowercase or uppercase hex digits. Case only changes the letters a–f; byte values and the lowercase 0x marker are not affected.
- Encode, then review the byte count, the formatted output length, and any replacement warning for isolated UTF-16 surrogates. Copy the full result with the copy button. If clipboard permission is denied, the read-only output stays available so you can select and copy it manually.
Editing the input or changing any option clears the previous output, the byte and replacement counts, the replacement warning, and any in-progress copy state, so stale results never mix with a fresh encoding pass.
The Three Output Formats and When to Use Each
All three formats are presentation choices over the same UTF-8 byte array, per the MDN reference for TextEncoder.encode. The bytes do not change when you switch formats; only the punctuation and spacing around the digits do.
| Format | Example for "Hi" | Length formula (n = byte count) | Best fit |
|---|---|---|---|
| Continuous | 4869 | 2n | Compact payloads, hash digests, header values |
| Space-separated | 48 69 | 3n − 1 | Logs, debugging, quick visual inspection |
| 0x-prefixed | 0x48 0x69 | 5n − 1 | C/C++/Rust byte arrays, embedded test vectors |
For the worked example, n = 2 (the two UTF-8 bytes for "Hi"). Continuous length is 2 × 2 = 4 characters (4869). Spaced length is 3 × 2 − 1 = 5 characters (48 69). 0x-prefixed length is 5 × 2 − 1 = 9 characters (0x48 0x69). The same arithmetic scales to any input, which is why the tool checks the output budget against the predicted length before formatting the bytes.
How Letter Case and Format Choice Affect the Output
Switching between lowercase and uppercase hex only rewrites the letters a through f as A through F. Numeric digits 0–9, the byte values themselves, and the lowercase 0x marker are all preserved. A byte whose value is 0x3c becomes 3c in lowercase mode and 3C in uppercase mode; the byte it represents is identical either way, and the byte count does not change.
Switching formats has a larger visual effect because of the punctuation it adds. The continuous form places two characters per byte, the spaced form places three characters per byte (two hex digits plus one ASCII space between bytes, with no trailing separator), and the 0x-prefixed form places five characters per byte (four for the literal 0xNN plus one ASCII space between bytes, with no trailing separator). If you are matching a target output exactly, such as a checksum string in a spec or a fixed-width column, the format choice matters as much as the byte content.
The tool computes the required output length from the byte count and the selected syntax, then validates that value against the output budget before allocating the formatted string. This is the same arithmetic shown in the length formula column above, applied per format.
Edge Cases: NUL Bytes, Combining Marks, Surrogates, and BOM
Several edge cases look surprising the first time you see them. Knowing the rule up front avoids confusion when the hex output does not match what you expected.
- NUL bytes (U+0000) are preserved. They are encoded as the byte 00, not used as a terminator. The full text, including any embedded NUL characters, is encoded before formatting.
- Whitespace order is preserved. CR, LF, tabs, and spaces are encoded in the order they appear in the input. The tool does not convert line endings or trim trailing characters.
- Combining marks stay decomposed. The character 'e' followed by U+0301 (combining acute accent) becomes the three bytes 65 CC 81, not the precomposed U+00E9. Unicode normalization is not applied.
- No BOM is prepended. The WHATWG TextEncoder encode step produces UTF-8 bytes for the first character of the input with no leading EF BB BF. If the input itself starts with U+FEFF, those bytes are encoded as data.
- Isolated UTF-16 surrogates are replaced. A high or low surrogate code unit that is not part of a valid pair is replaced with U+FFFD before encoding, producing EF BF BD. The result panel counts and visibly warns about every such replacement, because the original surrogate code units cannot be recovered from the bytes.
- Exact round trips need well-formed Unicode. Decoding the bytes back to text can only restore the original when the input was well-formed and did not begin with U+FEFF. The companion Hex to Text tool consumes a leading BOM by its documented policy, so a leading U+FEFF in the original input would be consumed during decoding rather than returned as a character.
Input and Output Limits for Large Pastes
Two explicit budgets govern every encoding pass, and the tool checks both before it formats a single byte. This is what stops a 1,000,000-character paste from being silently truncated, switched to a different format, or sampled.
- Input budget: at most 1,000,000 UTF-16 code units. Empty input and input over this limit are rejected with a clear message before encoding starts.
- Output budget: at most 4,999,999 UTF-16 code units of formatted output. Because the formatted length depends on the byte count and the chosen format, multi-byte characters in a verbose format can hit this ceiling before the input budget does.
The accepted boundary is exact: one million ASCII input characters in 0x-prefixed format produce exactly 4,999,999 output code units (5 × 1,000,000 − 1). One input code unit or one output code unit over either validator is rejected with an explicit message. The tool does not switch formats, slice bytes, drop a suffix, or sample content to fit a budget — it reports the failure.
For long pastes where the verbose 0x format is the bottleneck, switching to continuous or spaced output often keeps the same input under the ceiling. Practical guidance for very large UTF-8 pastes, including chunked workflows and the exact boundary conditions, is covered in the bulk encoding guide.