Does Text To HEX add a UTF-8 BOM at the start of the output?

No. The TextEncoder API does not prepend a BOM. If your input actually begins with U+FEFF, those three bytes (ef bb bf) appear as data because the character is part of the text.

What happens to an isolated UTF-16 surrogate in the input?

The tool counts isolated surrogate code units with pair-aware scanning, replaces each one with U+FFFD before encoding, and reports the replacement count. U+FFFD encodes as ef bf bd.

Do the three output formats change the underlying bytes?

No. Continuous, space-separated, and 0x-prefixed outputs describe the same UTF-8 byte array. The uppercase option only changes the hex letters a through f.

Is my text or the hex output uploaded to a server?

No. Encoding, formatting, and clipboard preparation run in the current browser tab using the TextEncoder API. Nothing leaves the device.

Why is my hex string longer than my input?

Each UTF-8 byte is written as two hex digits, and characters outside ASCII use multiple bytes. A 50-character emoji string produces 400 hex digits in continuous format because each emoji is four bytes.

Text to Hex ASCII: Convert Strings to Hexadecimal Bytes

To convert text to hex ASCII, each character is encoded as its UTF-8 byte sequence and each byte is written as two hexadecimal digits — so "A" (U+0041) becomes 41, the digit "0" (U+0030) becomes 30, and a space (U+0020) becomes 20. Strings outside the ASCII range take more than one byte per character: é (U+00E9) becomes c3 a9, 你 (U+4F60) becomes e4 bd a0, and 😀 (U+1F600) becomes f0 9f 98 80. Tools that claim to convert text to hex ASCII can produce different outputs depending on which encoding they apply behind the scenes. An ASCII-only converter drops non-ASCII bytes or replaces them with placeholders; a Windows-1252 or locale code-page converter produces bytes that only match on systems that share the same code page; a UTF-8 converter follows the WHATWG Encoding Standard, which is the same encoder used by the browser TextEncoder API. The Text To HEX tool applies that standard in your browser, reports the byte count, and offers three presentation styles for the same underlying bytes so the output reproduces correctly anywhere UTF-8 is read.

ASCII vs UTF-8: What the Conversion Actually Does

Many people searching for "text to hex ASCII" expect a one-byte-per-character mapping, and for plain English input that expectation lines up with reality. The ASCII range covers 128 code points from U+0000 to U+007F, and each one fits into a single UTF-8 byte whose two hex digits you can read off a chart. The string "Hi" produces the bytes 48 and 69, so the ASCII-to-hex result is 4869.

The moment the input contains anything outside that 128-character window, the simple ASCII picture stops working. The Latin-1 supplement, including é, à, and ñ, lives at U+0080 and above and requires two UTF-8 bytes. Most characters in the Basic Multilingual Plane used for non-Latin scripts — Chinese, Japanese, Korean, Arabic, Cyrillic, Hindi — use three UTF-8 bytes. Supplementary characters, which include emoji and rare CJK ideographs, use four. Encoding with an ASCII-only fallback would either drop these characters or replace them with a question mark, so any tool marketed as "text to hex" should encode UTF-8 explicitly. Text To HEX uses the browser TextEncoder API, which is standardized by the WHATWG Encoding Standard and produces a well-defined UTF-8 byte array for any valid text input.

Three Output Formats for the Same Bytes

The conversion produces a fixed byte array; the format choice only changes how those bytes are written. The Text To HEX tool offers three layouts and an uppercase/lowercase toggle for the hex letters a through f.

Format	Example for "Hi"	When it fits best
Continuous	4869	Compact single-line copy, checksum pipelines, hex dumps
Space-separated	48 69	Manual inspection, debugging logs, pasting into shell commands
0x-prefixed	0x48 0x69	C-style byte literals, microcontroller code, JSON arrays

Switching between these three options never alters the encoded UTF-8 bytes. The plain format concatenates two digits per byte. The spaced format inserts one ASCII space between byte pairs. The prefixed format writes each byte as 0xNN and separates tokens with a single ASCII space, with no delimiter before the first token or after the last. Choosing uppercase only changes the letters a–f; the byte values and the lowercase "x" in the prefix remain identical. Formatted output length, however, does change: plain uses 2n characters, spaced uses 3n−1, and prefixed uses 5n−1, where n is the byte count.

Convert Text to Hex Step by Step

Enter or paste the text into the input field, including any Unicode characters, whitespace, tabs, line breaks, or NUL (U+0000) data that the browser field can hold.
Pick a presentation format — continuous pairs, space-separated bytes, or 0x-prefixed tokens — and choose lowercase or uppercase hex digits.
Run the encode. The tool reports the UTF-8 byte count and the formatted output length, and shows a replacement warning if any isolated UTF-16 surrogates were replaced.
Copy the complete hexadecimal output. If clipboard access is denied, the read-only result remains on screen and can be selected by hand.

For the two-character ASCII string "Hi", the conversion is direct. H is U+0048, so its hex byte is 48. i is U+0069, so its hex byte is 69. Concatenating gives 4869 in continuous format, 48 69 in spaced format, and 0x48 0x69 in prefixed format. The byte count is 2, the formatted output length matches the formula for the chosen style, and no replacement warning appears because the input contains no isolated surrogates.

Byte Length by Character Range

The byte cost of a character depends entirely on its Unicode code point, not on how it looks on screen. The table below uses the same examples documented for the Text To HEX tool so the mapping is easy to verify.

Character	Code point	Bytes	Hex (continuous)
A	U+0041	1	41
é	U+00E9	2	c3a9
你	U+4F60	3	e4bda0
😀	U+1F600	4	f09f9880

These byte lengths explain why some "text to hex ASCII" tools give surprising results: a 50-character emoji string is not 100 hex digits in continuous format, it is 400 hex digits, because each emoji is four bytes. Planning hex output for a buffer, a wire protocol, or a database column should be based on byte count, not character count.

Edge Cases Worth Knowing

Text To HEX does not normalize or rewrite your input. Combining marks stay decomposed, so the input "e" followed by the combining acute accent U+0301 encodes as 65 cc 81 rather than being collapsed into the precomposed U+00E9. Line endings are encoded in the order you supply them; CR, LF, and CRLF each have their own byte sequences and the tool does not convert between them. NUL (U+0000) becomes byte 00, so a leading NUL in the input produces a leading 00 in the output. Other data is not treated as a terminator.

A leading U+FEFF in the input is encoded as ef bb bf, because TextEncoder adds no BOM. If you then take that output to the companion Hex to Text tool, that decoder consumes a leading BOM by its documented policy, which means a round trip through both tools requires the original text to not start with U+FEFF. An internal U+FEFF, anywhere except the first code unit, stays part of the text.

JavaScript strings are UTF-16, and isolated high or low surrogate code units are not valid Unicode. The Text To HEX tool counts these isolated surrogates with pair-aware UTF-16 scanning and replaces each one with U+FFFD before encoding. U+FFFD encodes as ef bf bd, and the result panel reports how many replacements happened, because the bytes cannot be decoded back into the original isolated code units.

Input and Output Limits

The tool enforces explicit budgets. Input may contain at most 1,000,000 UTF-16 code units, and formatted output may contain at most 4,999,999 UTF-16 code units. Empty input and input above the input cap are rejected before any encoding happens. The formatted-length cap is checked against the formula for the selected format — 2n, 3n−1, or 5n−1 — so the tool knows exactly when an output choice will exceed the budget. One million ASCII characters in 0x-prefixed format produce exactly 4,999,999 output code units, which the tool accepts as the boundary.

If a multi-byte Unicode string in a verbose format would push the output past the cap, the tool reports the failure rather than switching formats, slicing bytes, dropping a suffix, or sampling the content. The full text is encoded first, the required output size is calculated, the limit is checked, and only then does formatting proceed in bounded byte chunks that are joined together. The final string length is checked against the predicted value as a defensive invariant. Editing the input, changing format or letter case, or starting a fresh encode clears the previous output, error, byte statistics, replacement warning, and copy status.

Local Processing and Privacy

Encoding, byte counting, replacement detection, formatting, display, and clipboard preparation all run locally in the current browser tab using the TextEncoder API. Nothing is uploaded, so text that contains secrets, personal data, or proprietary strings stays on the device. Clipboard writes are guarded against stale results from older encode attempts or unmounted components, and a denied permission keeps the read-only result available for manual selection.

Hexadecimal is an encoding display, not encryption, hashing, or compression. Anyone with the bytes and the UTF-8 rules can recover well-formed text, subject to the documented leading-BOM behavior of the decoder they choose. For more on how this differs from running the encoder inside your own scripts, see the Text to Hex: Encode UTF-8 Strings the Right Way guide.