Hexadecimal is the standard way programmers read raw bytes, since two hex digits map exactly onto one byte with no rounding or ambiguity, unlike decimal where the same byte can take one, two or three digits depending on its value. That fixed width makes hex dumps easy to scan visually and easy to align in a table, which is why file inspection tools, network packet captures and low level debuggers all display raw data in hex rather than decimal or binary.
The detail most simple implementations get wrong is unicode. A naive character by character mapping assumes one byte per character, which breaks the moment the input contains an accented letter, a currency symbol or an emoji, all of which need two to four bytes in UTF-8 rather than one. This tool encodes text through TextEncoder first, converting it to real UTF-8 bytes before hex conversion ever runs, so multi byte characters produce the correct number of hex pairs every time.
Getting a byte level view of text that looks identical on screen
Reach for this tool whenever you need to see exactly what bytes a piece of text turns into, which comes up constantly in low level programming, debugging a serial protocol, writing a test fixture for a parser, or embedding a literal byte sequence inside source code, a configuration file or a network packet definition.
It is also useful for verifying that two systems agree on how a piece of text is encoded. If a value looks correct as text but a downstream system rejects it, converting it to hex on both ends and comparing the byte sequences directly, rather than the rendered characters, usually reveals whether an encoding mismatch, a stray byte order mark or an unexpected line ending is the actual culprit.
- Inspect the exact bytes a string of text produces before embedding it in a binary protocol or file format.
- Debug an encoding mismatch by comparing hex byte sequences rather than rendered characters.
- Generate a hex literal to paste into source code, a configuration file or a test fixture.
- Confirm how many bytes a specific unicode character, such as an emoji, actually occupies.
How this text to hex converter handles UTF-8
Every character you type is first passed through the browser's TextEncoder, which converts it into a sequence of UTF-8 bytes exactly as any modern web page, API or file format would store it. Plain ASCII characters, meaning ordinary English letters, digits and basic punctuation, always occupy exactly one byte and therefore produce exactly two hex digits each.
Characters outside that range behave differently, and this is precisely where a naive ascii to hex converter falls apart. An accented letter such as e with an acute accent typically needs two bytes, most currency symbols need three, and most emoji need four, so each of those characters expands into two, three or four separate hex pairs in the output rather than one. Seeing that expansion directly in the result is often the clearest way to understand why a text field with a strict byte length limit rejects input that looks short when you count characters instead of bytes.
Hexadecimal compared with decimal and binary byte views
The same underlying byte can be written three common ways: as two hexadecimal digits, as a decimal number from 0 to 255, or as eight binary digits. Hex strikes the practical balance between the two others, since it is far more compact than binary while still mapping onto byte boundaries exactly, with no rounding or variable digit width the way decimal has.
That fixed two character width per byte is why hex dumps line up cleanly in a monospace font and why file formats, cryptographic hash digests and colour codes are conventionally written in hexadecimal rather than either alternative. Once you can read a hex pair confidently, converting between all three representations becomes mostly a matter of habit.
How this string to hexadecimal conversion works under the hood
The conversion runs in two steps. First, TextEncoder turns your input string into UTF-8 bytes exactly as a browser, a server or a file system would store it. Second, each byte is formatted as two lowercase hexadecimal digits using base 16 number formatting, then joined together with spaces so individual bytes stay visually distinct in the result.
Nothing you type is ever transmitted anywhere during this string to hexadecimal conversion. The entire process runs locally using standard browser APIs, so you can confirm in your browser's developer tools that no network request fires while you convert text to hex. The resulting utf-8 hex bytes are exactly what any correct encoder in any language would produce for the same input string.
| Character | Binary | Decimal | Hexadecimal |
|---|---|---|---|
| H | 01001000 | 72 | 48 |
| i | 01101001 | 105 | 69 |
| ! | 00100001 | 33 | 21 |
How to use this text to hex converter
- 1
Type or paste your text
Enter the text you want to see as hexadecimal bytes into the input box.
- 2
Run the conversion
Press convert. Your text is first turned into UTF-8 bytes, then each byte is shown as two hex digits.
- 3
Check the byte count
Compare the number of hex pairs to your character count to spot multi byte characters like accents or emoji.
- 4
Copy the hex result
Copy the space separated hex output for use in code, a configuration file or a debugging session.
Related tools worth bookmarking
Sources and further reading
- MDN: TextEncoderThe browser API this tool uses to convert text into UTF-8 bytes before hex formatting.developer.mozilla.org
- RFC 4648: The Base16, Base32, and Base64 Data EncodingsThe specification defining Base16, the formal name for the hexadecimal byte encoding used on this page.rfc-editor.org
- WHATWG Encoding StandardThe living standard that governs how browsers convert text to and from UTF-8 bytes.encoding.spec.whatwg.org
Frequently asked questions
Common questions about the text to hex converter.
Because this text to hex converter encodes your input as UTF-8 before converting to hex, and any character outside plain ASCII, such as an accented letter, a currency symbol or an emoji, needs two to four bytes rather than one. Each of those bytes becomes its own two digit hex pair in the output.
An ascii to hex converter that only handles single byte characters will fail or produce wrong results on anything outside plain English text. This tool always encodes through UTF-8 first, so it correctly handles the full range of unicode text, not just the ASCII subset, while still producing identical results to a plain ASCII tool for ordinary English input.
Yes, the result matches exactly what you would get by encoding a string to UTF-8 bytes and formatting each byte as two hex digits in any programming language. This tool exists to save you from writing and testing that logic yourself for a one off check or a quick debugging session.
No. TextEncoder converts your input into a UTF-8 byte array entirely in memory, and each byte is then formatted as two hex digits using plain number formatting, both steps operating on values that never leave the JavaScript running in this tab. Nothing about that conversion path constructs a request of any kind, uploaded or otherwise.
Yes, using the companion hex to text converter, which reverses this exact process by parsing pairs of hex digits back into bytes and decoding those bytes as UTF-8 text. Together the two tools cover both directions of the conversion.
Lowercase hex digits, a through f, are the conventional style used by most programming languages and file formats, though uppercase and lowercase represent identical byte values. If a downstream system specifically requires uppercase hex, a simple find and replace or a text case converter handles that formatting difference.