Byte Length Counter by Encoding

Measure how many bytes your text becomes in UTF-8, Shift_JIS, EUC-JP, UTF-16, and JIS (ISO-2022-JP). Useful for checking database column limits and legacy form input caps.

Tips

  • In UTF-8, half-width alphanumeric characters take 1 byte each, while Japanese characters (hiragana, katakana, kanji) usually take 3 bytes each, so the same character count can mean very different byte counts between English and Japanese text.
  • Older systems that enforce byte-based limits on columns like VARCHAR(255) will hit their cap much faster with Japanese text than with English text of the same character length.
  • Most emoji are represented by a surrogate pair of two code units, taking 4 bytes in both UTF-8 and UTF-16, which is why social media character counters sometimes hit their limit sooner than expected.
  • If you already know a byte count and want to convert it to KB, MB, and other units, use our sister tool "Byte Unit Converter" instead — it handles the reverse calculation of byte count to other units.

Frequently Asked Questions

Character length counts how many visible characters are in a string, while byte length tells you how many bytes (octets) are needed to store or transmit that string as computer data. For plain ASCII text the two numbers match exactly, but for text containing multi-byte characters like Japanese, byte length can be several times larger than character length.

UTF-8 uses a variable-length scheme of 1 to 4 bytes per character, and most Japanese characters (hiragana, katakana, common kanji) take 3 bytes. Shift_JIS, on the other hand, encodes most Japanese characters in 2 bytes, so the same Japanese text is usually larger in UTF-8 than in Shift_JIS.

It depends on the database engine and the column's character set settings. MySQL's VARCHAR(n) is generally limited to "n characters", but there are also separate internal byte-based limits (such as maximum indexable key length), so text containing emoji can sometimes trigger errors. Check your specific DBMS documentation for the exact behavior.

Half-width alphanumeric characters and symbols take just 1 byte in UTF-8, Shift_JIS, and EUC-JP alike, while full-width characters (hiragana, katakana, kanji, full-width symbols) take 2 to 3 bytes depending on the encoding. A 10-character string can be as small as 10 bytes if it's all half-width, or 20-30 bytes if it's all full-width.

This tool takes a text string as input and calculates its byte length for each encoding. The "Byte Unit Converter" tool instead takes a byte count you already know (e.g. 1,500,000 bytes) and converts it into units like KB, MB, or GB. Use this tool when you want "text to byte count", and the other tool when you want "byte count to other units".
ツールくん

Side Note — The hidden relationship between social media character limits and byte counts

Older versions of MySQL's "utf8" character set had a surprising limitation: it could not actually store Unicode emoji (supplementary characters beyond U+10000). UTF-8 itself is a variable-length encoding that supports up to 4 bytes per character, but MySQL's "utf8" was historically capped at 3 bytes per character, causing INSERT errors whenever text containing emoji was saved. Migrating to "utf8mb4", which correctly supports the full 4-byte range, is now the recommended fix — a well-known example of why understanding the relationship between character encoding and byte count actually matters in practice.

Back when Twitter (now X) enforced its famous 140-character limit, there was a long-running debate about fairness between languages: Japanese users could express a fairly complete thought in 140 characters, while English users could barely fit 20-30 words in the same limit. This is because a single Japanese kanji character can carry far more information than a single English letter. Twitter eventually introduced a weighted counting system where languages like Japanese counted as "1 character = 1 count" while others counted "2 bytes = 1 count" for certain characters, in an attempt to balance the playing field across languages.

Mobile SMS has a similar quirk. A standard GSM-encoded SMS allows up to 160 characters per message, but the moment it includes even a single character outside the 7-bit GSM character set — such as an emoji or a Japanese character — the encoding switches to UCS-2 (roughly equivalent to UTF-16), and the limit drops sharply to just 70 characters. The fact that using a single Japanese character can cut your available message length in more than half is a perfect real-world illustration of the exact relationship between character encoding and byte count that this tool is built to measure.

More tools in this category