A hexadecimal byte always uses two digits, so the ASCII letter A (U+0041) becomes 41 in UTF-8 hex, the lowercase é (U+00E9) becomes c3 a9, the CJK character 你 (U+4F60) becomes e4 bd a0, and the emoji 😀 (U+1F600) becomes f0 9f 98 80. This text-to-hex cheat sheet maps the most common characters to their UTF-8 byte values, explains the byte width you should expect for each Unicode range, and shows how the Text to HEX converter produces these byte sequences locally in the browser without uploading your input or output. When the goal is to debug a payload, verify a hash input, or learn how the bytes line up, the conversion rules stay the same and the byte boundaries are predictable from the code point value itself. ASCII letters and punctuation take a single byte, common Latin extensions take two, most of the Basic Multilingual Plane takes three, and supplementary Unicode scalars such as the grinning face emoji take four bytes.
UTF-8 Hex Values for Common Characters
The fastest way to read a hex dump is to recognize a few landmarks. NUL U+0000 is the byte 00. A printable ASCII byte begins with 2 (space) through 7 (~), so any byte in 20–7e decodes as a single visible ASCII code point. Bytes 80–bf never start a UTF-8 character on their own; they are continuation bytes following an earlier lead byte. Bytes c0–c1 are not legal as UTF-8 leads, which is why a hex dump that begins with c0 is a flag that something went wrong upstream.
| Character | Code point | UTF-8 bytes (hex) | Width |
|---|---|---|---|
| NUL | U+0000 | 00 | 1 byte |
| Space | U+0020 | 20 | 1 byte |
| 0 | U+0030 | 30 | 1 byte |
| A | U+0041 | 41 | 1 byte |
| a | U+0061 | 61 | 1 byte |
| ~ | U+007E | 7e | 1 byte |
| © | U+00A9 | c2 a9 | 2 bytes |
| é | U+00E9 | c3 a9 | 2 bytes |
| ñ | U+00F1 | c3 b1 | 2 bytes |
| € | U+20AC | e2 82 ac | 3 bytes |
| 中 | U+4E2D | e4 b8 ad | 3 bytes |
| 你 | U+4F60 | e4 bd a0 | 3 bytes |
| 𝄞 | U+1D11E | f0 9d 84 9e | 4 bytes |
| 😀 | U+1F600 | f0 9f 98 80 | 4 bytes |
The hex values above use lowercase letters for a through f and follow the spaced presentation. Switching the tool to uppercase changes only those letters, so é becomes C3 A9 and 😀 becomes F0 9F 98 80. The byte values themselves do not change.
UTF-8 Byte Widths by Code Point Range
The encoding standard defines UTF-8 byte widths from the code point value, which is why a hex dump is a reliable way to verify that a string was encoded the way you expected. ASCII characters U+0000 through U+007F occupy one byte each. Many common Latin extensions and other scripts in U+0080 through U+07FF occupy two bytes. Most of the Basic Multilingual Plane, U+0800 through U+FFFF, occupies three bytes. Supplementary Unicode scalars U+10000 through U+10FFFF occupy four bytes.
The lead byte pattern reflects the width directly. One-byte leads fall in 00–7f, two-byte leads in c2–df, three-byte leads in e0–ef, and four-byte leads in f0–f4. Lead bytes c0 and c1 are illegal because no Unicode scalar needs them, and lead bytes f5–fd are illegal because no defined scalar is above U+10FFFF. Seeing a hex dump begin with c0 or f5 is a strong sign that the input was not valid UTF-8 before encoding, which is why the Text to HEX tool uses the standardized TextEncoder conversion described in the WHATWG Encoding Standard rather than a code-page fallback.
Combining marks do not get folded into their precomposed counterpart by the encoder. The sequence e followed by U+0301 stays decomposed and encodes as 65 cc 81 rather than being normalized to é (c3 a9). If your workflow requires precomposed output, run the input through a normalizer first; the converter itself does not apply Unicode normalization, case folding, trimming, newline conversion, escape parsing, or locale-aware rewriting.
How to Convert Text to Hex With the Text to HEX Tool
- Open the Text to HEX converter in your browser and paste or type the text into the input field. The field accepts Unicode, whitespace, and NUL U+0000; ordinary input begins directly with the first character's bytes because the encoder does not add a UTF-8 BOM.
- Pick the output format: continuous pairs such as 4869, space-separated bytes such as 48 69, or per-byte 0x-prefixed tokens such as 0x48 0x69. The three are presentation choices over the same byte array.
- Choose lowercase or uppercase hexadecimal digits. Uppercase mode changes only a through f; byte values and the lowercase 0x marker stay the same.
- Run the encoder. The result panel shows the formatted hexadecimal output alongside the UTF-8 byte count, the formatted output length, and the number of isolated-surrogate replacements performed during encoding.
- Copy the complete result to your clipboard. Clipboard writes use generation, mounted-state, and timer-identity guards, so a late success or failure from an older permission request cannot restore stale status after an edit, a newer encode, or another copy attempt. If clipboard access is denied, the complete read-only result stays available for manual selection.
Continuous, Spaced, and 0x-Prefixed Output Compared
| Format | Example for "Hi" | Output length formula | Typical use |
|---|---|---|---|
| Continuous | 4869 | 2n characters | Paste into a hex search, embed in a payload |
| Spaced | 48 69 | 3n − 1 characters | Human-readable dumps, documentation |
| 0x-prefixed | 0x48 0x69 | 5n − 1 characters | Source code, register listings, C-style byte arrays |
The variable n in the formulas is the UTF-8 byte count. For n = 2, continuous is 4 characters (4869), spaced is 5 characters (48 69), and 0x-prefixed is 9 characters (0x48 0x69); that matches the table above. No delimiter is placed before the first token or after the last, so the n − 1 separator slots explain the 3n − 1 and 5n − 1 expressions. The Text to HEX tool calculates the required output size from byte count and selected syntax and rejects the encode before formatting if the prediction exceeds the output budget.
Byte Counts, Replacement Warnings, and Output Limits
Every encode reports two counts that you can use as ground truth. The UTF-8 byte count is the number of bytes that came out of the TextEncoder API. The replacement count is the number of isolated UTF-16 surrogate code units that were replaced with U+FFFD before encoding, because an isolated surrogate is not a Unicode scalar and the standardized conversion replaces each one with the bytes EF BF BD. The result panel surfaces that count and renders a warning because decoding EF BF BD cannot recreate the original isolated code units.
Limits are explicit and applied before the large formatted string is built. The input field accepts up to 1,000,000 UTF-16 code units; one code unit over the limit is rejected with an explicit message. The formatted output must fit in 4,999,999 UTF-16 code units, with the exact boundary accepted: one million ASCII characters in 0x-prefixed format produce exactly 4,999,999 output code units, because n = 1,000,000 and 5n − 1 = 4,999,999. Multi-byte Unicode in a verbose format can reach the output budget before the input budget, and the tool reports that failure rather than switching formats, slicing bytes, or sampling content.
Editing text, changing format or case, or starting a new encode clears the previous output, error, byte statistics, replacement warning, copy status, and copy timer. Formatting proceeds in bounded byte chunks and joins every chunk; this is internal handling that does not change or limit the visible output, only how it is constructed in memory.
Round-Trip Rules for Going Hex Back to Text
An exact text-to-hex-to-text round trip requires well-formed Unicode and a careful eye for a leading U+FEFF. JavaScript strings are UTF-16, and a valid high-plus-low surrogate pair represents one supplementary Unicode scalar that the encoder handles normally. An isolated high or low surrogate code unit becomes U+FFFD before encoding, which is irreversible: the bytes EF BF BD cannot be turned back into the original isolated code unit. Watch the replacement count in the result panel; a non-zero count means the round trip will not be exact.
If your input begins with U+FEFF, those character bytes are encoded as data EF BB BF because they are data, not because the encoder added a BOM. TextEncoder does not prepend a UTF-8 byte order mark. The companion Hex to Text tool consumes a leading EF BB BF under its documented BOM behavior, so an exact round trip through that specific tool also requires the original to not begin with U+FEFF. An internal U+FEFF somewhere in the middle of the string remains part of the text. For background on the reverse direction, see how to convert hex to readable text in plain and 0xNN form.
The browser API behind the converter is standardized. MDN documents the TextEncoder interface and the Uint8Array it returns; the WHATWG Encoding Standard defines the scalar-value conversion and the UTF-8 encoder. Hexadecimal is a display encoding for those bytes, not encryption, hashing, compression, or secret protection; anyone who has the bytes and the UTF-8 rules can recover the original text subject to the documented leading-BOM behavior of a chosen decoder.