Updated · Built and checked by the PlinzoTools team, formulas tested against published sources
Find a text's actual UTF-8 byte size, not just its character count.
18 bytes
A string's character count and its actual storage size in bytes are not the same thing once non-ASCII characters are involved -- emoji and many non-Latin scripts use multiple bytes per character in UTF-8. This tool reports both, the byte size being what actually matters for storage limits, upload size, or database column sizing.
Type or paste any text. Character count, UTF-16 code unit count, and UTF-8 byte size all update instantly.
UTF-8 uses 1 byte for ASCII characters, but 2-4 bytes for many other characters (2 for most Latin-extended/Greek/Cyrillic, 3 for most CJK characters, 4 for most emoji). A 5-character emoji string can easily be 15-20+ actual bytes -- a common source of confusion when a database column limit is set in bytes but validated in the application as a character count.
For converting text into its hex or binary byte representation directly, see the Text to Hex Converter.
Take the hypothetical string "Cafe" written with an accented final letter, followed by a space and one smiling emoji. Counting by characters, that is six: four letters, a space, and the emoji. The tool's Characters figure counts each code point once, so it reports 6. The UTF-16 code unit figure is 7, because the emoji sits outside the Basic Multilingual Plane and takes a surrogate pair of two units. The UTF-8 byte size is 10: three plain ASCII letters at 1 byte each, the accented letter at 2 bytes, the space at 1, and the emoji at 4. Three different numbers describe the same short string, and which one you need depends entirely on what limit you are checking against.
The byte size always assumes UTF-8 encoding, computed in your browser with the standard text encoder. Nothing is uploaded. If your target system stores text in UTF-16 or a legacy single-byte encoding, its byte count will be different, and some databases with limited UTF-8 support store only a subset of four-byte characters. For any hard production limit, test with a representative sample of the real text your users will submit, including the longest and most exotic entries you expect.
Developers sizing a column for names or comments can paste a few worst-case samples and see how far bytes exceed characters. Writers of push notifications or SMS-style messages can see quickly why an emoji-heavy message hits a byte ceiling sooner than its visible length suggests.
JavaScript's .length counts UTF-16 code units, not bytes or even always actual characters -- some characters (like many emoji) need 2 UTF-16 code units (a "surrogate pair"), so .length can overcount characters while still undercounting UTF-8 bytes.
Not much -- plain ASCII text has 1 byte per character, so character count and byte size match exactly; the difference only becomes significant with emoji, accented characters, or non-Latin scripts.
4 bytes for the base emoji code point -- complex emoji built from multiple code points (like a family emoji or one with a skin-tone modifier) use even more bytes total, since each combined code point adds its own bytes.
Each emoji is typically a four-byte sequence in UTF-8 but counts as one character, so a string with many emoji will show a byte size well above its character count.
Yes. Everything in the text box is encoded, including spaces and line breaks, so a trailing newline adds one byte.
No. The counts are computed locally in your browser as you type.
Reference: MDN Web Docs