A message that looks short can still be surprisingly "heavy" in storage terms — and the reason comes down to a detail most people never need to think about until an API silently rejects a payload that looked well within limits.
How UTF-8's Variable-Width Encoding Works
UTF-8, the encoding used across almost the entire web, doesn't give every character a fixed number of bytes. Plain English letters, digits, and standard punctuation each take exactly 1 byte, since they fall within the original, limited range UTF-8 was built to stay backward-compatible with. But a single byte can only represent 256 distinct values — nowhere near enough for the full set of characters UTF-8 needs to support across every language and symbol set in use. So characters outside that basic range get 2, 3, or 4 bytes instead: accented Latin letters and many European scripts typically take 2, most Asian-language characters take 3, and emoji (along with some rarer symbols) take 4.
Character Count vs. Byte Size
Character count treats every visible character the same — one emoji counts the same as one letter "a." Byte size instead reflects the actual storage or transmission cost, and under UTF-8 that cost varies dramatically by character. Ten emoji might display as ten characters on screen while consuming 30 to 40 bytes underneath, while ten plain English letters consume exactly 10 bytes for the same visible character count. These two numbers only match reliably for plain, unaccented English text.
Why This Matters for Real Limits
Many real systems — SMS message segments, database column sizes, API request payloads — enforce their limits in bytes, not visible characters, because bytes are what actually determine storage space and network cost. Text that looks comfortably under a character-count limit can silently exceed a byte-based limit once emoji or non-English characters are involved, leading to truncated messages, rejected form submissions, or database errors that look mysterious until you check the actual byte size rather than the character count.
Check Your Text's Byte Size
Paste any text into the free Text Byte Size Calculator to see its real UTF-8 byte size alongside its character count.
FAQ
Why does an emoji or accented letter take up more than one byte? UTF-8 encoding uses a variable number of bytes per character depending on which character it is. Plain English letters, numbers, and basic punctuation each take exactly 1 byte, but characters outside that basic range — accented letters, non-Latin scripts, and emoji — require 2, 3, or up to 4 bytes each to represent, since a single byte can only distinguish 256 possible values, nowhere near enough for the full range of characters UTF-8 needs to support.
Why does character count differ from byte size? Character count simply counts how many visible characters are in a string, treating every character equally. Byte size measures the actual storage or transmission cost, which varies per character under UTF-8. A string of 10 emoji might display as 10 characters but consume 30-40 bytes, while 10 plain English letters consume exactly 10 bytes — the same character count with a very different byte size.
Why does this matter for things like SMS or API limits? Many systems enforce limits in bytes, not visible characters, precisely because byte size is what actually determines storage space or network transmission cost. A text message, database column, or API payload with a byte-based limit can silently reject or truncate content that looks well within a character-count limit but exceeds the real byte limit once emoji or non-English characters are included.