Text to hex on a Mac converts pasted text into the hexadecimal representation of its UTF-8 bytes, and the Text To HEX tool performs that conversion locally in a browser without a Terminal command. Open the Text To HEX page in your Mac’s current browser, enter the source text, choose how the byte pairs should be displayed, and run the encoder. The result can be continuous hexadecimal, space-separated pairs, or space-separated 0x-prefixed tokens, with lowercase or uppercase A–F digits. Because the conversion follows UTF-8 rather than a legacy system code page, accented letters, CJK characters, emoji, spaces, tabs, line breaks, and NUL data are represented by their actual encoded bytes. The tool also reports the UTF-8 byte count and the length of the formatted result. It does not silently add a byte order mark; bytes for U+FEFF appear only when that character is genuinely present in the source. For malformed UTF-16 data containing an isolated high or low surrogate, the result panel makes the standardized replacement visible instead of pretending that an exact round trip is possible. Everything from encoding and sizing to formatting and clipboard preparation runs in the current browser tab, so the input and output are not uploaded to Lizely. This method converts existing text for inspection or transfer; it is separate from the macOS “Unicode Hex Input” keyboard, which is designed for typing characters rather than turning a passage into hexadecimal bytes.
What the Mac browser workflow produces
Every conversion has three layers: the source characters, the UTF-8 bytes representing those characters, and a hexadecimal display of each byte. The browser’s TextEncoder API performs the UTF-8 conversion. Each resulting byte is then written as exactly two hexadecimal digits, which makes the output suitable for inspecting byte values or supplying a payload that expects hex notation. The three display formats contain the same bytes; only their punctuation and letter case differ.
Hexadecimal is a data representation, not a way to conceal a message. It also does not perform hashing, compression, or encryption. Use it when you need an exact UTF-8 byte sequence, want to compare text with a byte-oriented protocol, or need hexadecimal characters for a software form that accepts them.
Convert text to hex on your Mac
Complete the conversion directly in your browser with these steps:
- Open the Text To HEX page in your Mac browser. The tool requires no separate application or Terminal command.
- Copy the source text from a Mac app with Command-C, then paste it into the tool’s text field with Command-V. You can also type directly. Paste the exact characters you want encoded rather than adding quotes or extra spaces.
- Choose the output layout: continuous pairs, space-separated pairs, or 0x-prefixed tokens. Whitespace and NUL characters are encoded in the order supplied; any NUL data the browser field can hold is also eligible for conversion.
- Select lowercase or uppercase hexadecimal digits. This setting changes only the letters A–F and does not alter the UTF-8 byte values.
- Select Encode. The complete hexadecimal result appears in the output panel, along with the UTF-8 byte count and formatted output length.
- Review the replacement count. A nonzero count means the source contained isolated UTF-16 surrogate code units, which the standard conversion replaces with U+FFFD. Replace those malformed units with valid characters or a correctly paired surrogate, then encode again.
- Copy the complete output. If macOS denies clipboard access, the full read-only result remains available for manual selection with the pointer.
Editing the text, changing the format or letter case, or beginning a new encode clears the previous output, error, byte statistics, replacement warning, copy status, and copy timer. This prevents an old result from being mistaken for the result of your current input.
Match the layout to its destination
Choose the format according to what will consume the hexadecimal value. In the table, NN represents the two digits for one byte, and n is the UTF-8 byte count.
| Format | Byte layout | Formatted length |
|---|---|---|
| Continuous | All two-digit pairs concatenated | 2n |
| Space-separated | Two-digit pairs separated by one ASCII space | 3n − 1 |
| 0x-prefixed | 0xNN tokens separated by one ASCII space | 5n − 1 |
No delimiter appears before the first token or after the last one. Changing the format changes the formatted length but never the encoded bytes. Uppercase mode changes only hexadecimal letters; the 0x marker remains lowercase.
Verify one short conversion
Take the two-character input Hi. The letter H is U+0048 and occupies one UTF-8 byte with hexadecimal value 48, while i is U+0069 and occupies one byte with value 69. The calculation is 2 bytes × 2 hexadecimal digits per byte = 4 digits. The continuous result is 4869, the spaced result is 48 69, and the prefixed result is 0x48 0x69. These are three presentations of the same two-byte sequence.
Handle UTF-8 and Unicode deliberately
The browser conversion follows the WHATWG TextEncoder encode specification, while MDN’s TextEncoder.encode documentation describes the UTF-8 byte-array result. Character width depends on the Unicode scalar value:
| Character group | UTF-8 byte width | Hexadecimal pairs |
|---|---|---|
| ASCII characters | 1 byte | 1 |
| Many common Latin characters | 2 bytes | 2 |
| Most Basic Multilingual Plane characters | 3 bytes | 3 |
| Supplementary Unicode scalar values | 4 bytes | 4 |
The converter preserves the supplied data rather than preparing it for display. It does not apply Unicode normalization, convert newlines, trim whitespace, fold case, parse escape sequences, or perform locale-aware rewriting. Carriage returns, line feeds, tabs, and spaces remain in their original order. NUL U+0000 becomes byte 00 and is not treated as a terminator. Combining sequences remain decomposed unless the source was already composed, and a U+FEFF inside the text remains part of the data.
JavaScript strings use UTF-16, so malformed surrogate data needs special attention. A valid high-plus-low surrogate pair represents one supplementary Unicode scalar and is encoded normally. An isolated high or low surrogate is not a Unicode scalar: the standardized conversion replaces each isolated code unit with U+FFFD before UTF-8 encoding. The result reports the number of replacements because decoding those bytes cannot recreate the original isolated code units.
Check limits before encoding large text
The input 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. Empty input is rejected. The exact maximum values are accepted, while one code unit over either corresponding limit produces an explicit error. Multi-byte Unicode in a verbose format can reach the output limit before the input limit, so the byte count and selected presentation must both be considered.
The tool validates the input before encoding. After producing the full UTF-8 byte sequence, it calculates the required formatted length from the byte count and selected syntax, then checks that prediction before building the large output string. It does not switch formats, slice bytes, drop a suffix, or sample the content. Formatting proceeds in bounded byte chunks and joins every chunk, followed by a final length check against the predicted value.
Copy only the current result
Use the copy control after checking the format, letter case, byte count, and any warning. The clipboard operation is tied to the current encode state: a late success or failure from an older permission request cannot restore stale copy information after an edit, newer encode, another copy attempt, or page closure. If access is denied, select the complete read-only output manually and use the standard Mac copy command.
- Confirm that the selected layout matches the destination’s expected notation.
- Use the byte count to verify the source size, not the formatted output length, which also includes spaces or prefixes.
- Resolve any replacement warning before relying on a round trip.
- Copy the entire output rather than a partial selection.
Know what a round trip preserves
An exact text-to-hex-to-text round trip requires well-formed Unicode. There is also a specific leading-U+FEFF caveat: the companion Hex to Text tool consumes a leading UTF-8 BOM under its documented decoder behavior, so a round trip through that decoder requires the original text not to begin with U+FEFF. A U+FEFF elsewhere in the source remains ordinary text.
Finally, keep the security boundary in view. Hexadecimal is only a display of UTF-8 bytes. Anyone who has those bytes and knows the UTF-8 rules can recover well-formed text, so use a proper encryption or secret-protection tool when confidentiality is required.
If you're weighing options, Convert to UTF-8 Bulk: Repeatable Local File Workflow covers this in detail.
If you're weighing options, UTF8 Decode Example: From Bytes to Unicode Text covers this in detail.