What does a text to hex converter show?
It shows the exact bytes your text is stored as, written in hexadecimal. This one encodes the text as UTF-8 and prints each byte as a two-digit lowercase pair, separated by spaces. Hi becomes 48 69, two bytes. Grüße becomes 47 72 c3 bc c3 9f 65, seven bytes for five characters, because ü and ß each need two.
That byte view answers questions a character count can't: how large a string really is, whether two strings that look the same are stored the same way, and what a program will actually write to disk or send over the network.
How many bytes each character takes
RFC 3629, the UTF-8 specification, sets the byte length from the character's code point. You can predict the size of any character with this table:
| Code point range | Bytes | Example | Hex output |
|---|---|---|---|
| U+0000 to U+007F | 1 | A |
41 |
| U+0080 to U+07FF | 2 | Ω (Greek capital omega) |
ce a9 |
| U+0800 to U+FFFF | 3 | 中 (CJK "middle") |
e4 b8 ad |
| U+10000 to U+10FFFF | 4 | 👍 |
f0 9f 91 8d |
The first byte of each character announces how many bytes follow. A byte below 80 stands alone. A byte starting with c or d opens a two-byte sequence, e a three-byte one and f a four-byte one. Bytes from 80 to bf are continuation bytes and never start a character. Once you know that, you can split a long hex string into characters by eye.
Worked example
Convert naïve:
- Type
naïveand click Convert. - The output is
6e 61 c3 af 76 65. - Split it by the lead-byte rule:
6e(n),61(a),c3 af(ï),76(v),65(e).
The c3 af pair is the interesting part. ï is U+00EF, binary 00011 101111 when padded to the 11 payload bits a two-byte sequence carries. The lead byte is 110 plus the first five bits (11000011, or c3) and the continuation byte is 10 plus the last six (10101111, or af). Every accented Latin letter in the U+0080 to U+07FF range works the same way, which is why so many of them start with c3.
Things that surprise people
Two spellings of the same letter. é can be one precomposed character, c3 a9, or a plain e followed by a combining accent, 65 cc 81. They look identical on screen. If two strings refuse to match, converting both here shows which form each one uses.
Invisible characters. A no-break space, which web pages and word processors insert freely, is c2 a0 instead of the ordinary space 20. A byte order mark at the start of pasted text is ef bb bf.
The replacement character. If the input contains a broken UTF-16 sequence (half of an emoji, usually from text that was cut in the middle), the browser's TextEncoder substitutes U+FFFD, and you'll see ef bf bd. That's a sign the text was already damaged before you pasted it.
Line endings. Each line break becomes 0a. The browser has already normalised line endings in the text box, so 0d never appears.
Comparing with a file on disk
The output is meant to match what a hex editor or dump utility shows for the same text saved as UTF-8:
- Save the text to a file as UTF-8 without a BOM.
- Dump it:
xxd -p file.txton Linux or macOS prints plain lowercase hex with no spaces, andFormat-Hex -Path file.txtin PowerShell prints uppercase pairs in rows of 16 with offsets. - Compare. The bytes should agree, except that the file may end with a trailing
0a(or0d 0aon Windows) that your text box didn't have, and some editors addef bb bfat the start.
If the file shows a single byte such as e9 where this page shows c3 a9, the file was saved in Latin-1 or Windows-1252, not UTF-8.
Related conversions
To turn hex bytes back into readable text, use hex to text, which decodes UTF-8 and reports invalid sequences. For the same bytes in base 2 there's text to binary, and Base64 encoder packs them into a shorter, copy-safe form. If your text is plain English and you mainly want the hex notation for code, ASCII to hex covers the escape formats.
Last updated