Byte Calculator

Bytes vs. characters: why the count changes

A byte is a unit of storage, while a character is what you see on screen. The confusion starts because they are not the same. In UTF-8, the encoding the modern web is built on, a single character can occupy 1 to 4 bytes depending on which alphabet it belongs to. That is why a 100-character message can be well under 100 bytes or far over it. A byte limit like "within 2,000 bytes" is a storage limit, not a character limit, so counting characters alone will mislead you. This tool reads your text with the browser's built-in TextEncoder and reports the exact UTF-8 byte length, the same number a UTF-8 database or API would store.

How UTF-8 assigns bytes

• Basic Latin letters, digits, spaces, and common ASCII punctuation are 1 byte each.
• Accented Latin letters (é, ü, ñ, etc.), Greek, and Cyrillic are 2 bytes each.
• Korean, Chinese, Japanese, and most other scripts are 3 bytes each.
• Most emoji are 4 bytes, and emoji built from several code points (skin tone, flags, family sequences) stack up to 8, 12, or more bytes for what looks like one symbol.
• A line break counts too: a Unix newline is 1 byte, but a Windows CRLF line break is 2 bytes, which quietly adds up in multi-line text.

A worked example

Take the string "Hi 안녕 :)". Reading left to right: H, i, and the space are 1 byte each, giving 3 bytes. The two Korean characters are 3 bytes each, adding 6. The next space is 1 byte, and the two ASCII characters : and ) are 1 byte each, adding 3 more. The total is 12 bytes even though the string is only 8 characters long. Now swap the smiley for an emoji, "Hi 안녕 👋". The waving-hand emoji alone is 4 bytes, so a single visible symbol costs four times what a letter does. This is exactly why emoji-heavy text overruns byte limits so easily.

Where byte limits actually bite

• Application and cover-letter fields that say "within 2,000 bytes": type your draft here first so you know the real number before the form rejects it at submission time.
• Push notifications and SMS: carriers and app stores cap the payload in bytes, and text that fits visually can still be truncated mid-word when it crosses the limit.
• Database column sizing: a VARCHAR(255) in a UTF-8 database may or may not hold 255 characters depending on the script, so checking real byte usage prevents "data too long" errors.
• API request and header fields: many APIs document length limits in bytes, and multibyte names or tags can exceed them without looking long.
• File and URL slugs: non-ASCII characters get percent-encoded, and each byte becomes a three-character %XX sequence, inflating the visible length.

Common mistakes and misconceptions

• Assuming 1 character equals 1 byte. This only holds for plain ASCII; the moment you add an accent, a Korean word, or an emoji it breaks.
• Trusting a character counter for a byte limit. A word processor's character count and a byte limit are different measurements, and they diverge fast with non-English text.
• Forgetting trailing spaces and blank lines. They are real bytes and are easy to leave in when you copy and paste.
• Treating one emoji as 4 bytes always. Compound emoji with modifiers can be several times larger, so never estimate them by eye.
• Ignoring which encoding the limit uses. A limit written for EUC-KR counts Korean as 2 bytes, so a UTF-8 count of the same text will read higher.

Cautions and limits

This tool always measures against UTF-8, which is the correct basis for almost every modern website, database, and API. Some older Korean systems still count in EUC-KR, where Korean characters are 2 bytes instead of 3, so the same text will show a smaller number there. If a form or spec does not state its encoding, assume UTF-8 but confirm when a submission is important. Also remember that a byte count answers "will it fit in storage," not "is it too long to read"; for readability, a character or word count is the better measure. When a submission truly matters, paste your final text into the real input box and check once more, since some systems apply their own trimming or normalization.