Guide
Counting bytes in UTF-8, UTF-16 and UTF-32
A character count tells you what a reader sees, but computers store, send and limit bytes. The two numbers agree only for plain English text, and the gap grows with every accent, symbol or emoji. This page measures the byte length of any text in the Unicode encodings people actually use, shows the bytes, and helps when a limit is in the way.
How UTF-8 spends bytes
UTF-8 uses one byte for the 128 ASCII characters, two bytes for code points up to U+07FF (which covers Latin letters with accents, Greek, Cyrillic, Hebrew and Arabic), three bytes up to U+FFFF (most Asian scripts, the euro sign and many symbols), and four bytes beyond that (emoji and rare scripts). The page lists the bytes in hexadecimal, so you can see that é is C3 A9, the euro sign is E2 82 AC and a smiling face is F0 9F 98 80.
UTF-16 and UTF-32
UTF-16 uses two bytes for code points up to U+FFFF and four bytes, a surrogate pair, above that. This is the encoding behind JavaScript strings, Java and Windows APIs, and it is why the JavaScript length of an emoji is 2. UTF-32 always uses four bytes. Each of the two comes in big-endian and little-endian forms, which differ only in the order of the bytes of each unit; the table shows both. The counts exclude a byte order mark unless you switch the option on.
Byte limits
Enter a limit and the page tells you whether the UTF-8 size fits. If it does not, it shows how many bytes are over, offers the text cut to the last whole character that fits, and says how many characters were removed. The cut never splits a multi-byte sequence, which is what causes the replacement characters seen in truncated text. Use it for database columns, HTTP headers, cookie values and fields in APIs that measure bytes.
Decoding bytes
The second mode runs the other way. Paste hexadecimal bytes, with or without spaces, choose the encoding, and the page shows the text and the code points. Latin-1 is included for data from older systems. If the bytes are not valid in the chosen encoding, an error message explains which sequence failed, which helps when you are not sure which encoding a log or a file used.
A worked example
The Sample button loads “Héllo, wörld! € 日本語 😀”. It has 21 code points, and the same number of visible characters, but its JavaScript length is 22 because the emoji takes two UTF-16 units. In UTF-8 it takes 34 bytes, in UTF-16 44 bytes and in UTF-32 84 bytes. With a limit of 20 bytes the page keeps the text up to and including the space after the euro sign, which is exactly 20 bytes, and drops the Japanese characters whole instead of cutting one in the middle.
Limits
Only the Unicode encodings listed are counted. Windows-1252, Shift JIS, GBK and other legacy code pages are not, and neither is Base64 or URL-encoded size. Lone surrogate halves cannot be written in UTF-8, so they appear as the replacement character. The page counts the text you paste after your browser has normalised line endings, so a file with Windows line breaks may differ from the count your system reports.
Related tools
- Unicode Inspector lists every code point with its category and script.
- Text to Binary shows the bytes of text in binary.
- Byte Converter converts between KB, KiB, MB and the other units.
- Quoted-Printable Decoder decodes the byte escapes found in email.
Checked against the current version of the UTF-8 Byte Counter on .