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.

Last updated: 2026-09-20

Character count and byte count are not the same thing

Ten characters taking up thirty bytes is an everyday occurrence once non-Latin text is involved. **The byte count of one and the same string changes with the encoding:** in UTF-8 a Japanese character occupies three bytes and an emoji four, whereas in Shift_JIS a Japanese character fits into two. This tool shows at once how many bytes your input comes to under five schemes at the same time, namely UTF-8, Shift_JIS, EUC-JP, UTF-16 and ISO-2022-JP.

**The UTF-16 code-unit count shown alongside is precisely the figure JavaScript's `.length` returns.** This is the pitfall most often missed, because emoji and certain characters are represented by a surrogate pair of two units, so **what a person counts as one character, `.length` counts as two.** That is why a length limit implemented with `.length` turns input containing emoji away sooner than expected. On the database side, too, whether a `VARCHAR(255)` counts bytes or characters depends on the product and its settings, so keeping both figures in view keeps you from judging wrongly.

How to use it

Enter your text The counts update the moment you paste. Line breaks are perfectly acceptable.
Compare the character and byte counts **A single character can still amount to three bytes in UTF-8.**
Read the row for the encoding that concerns you Look at whichever scheme your storage or your destination actually uses.
Check the UTF-16 code-unit count **If your limit is enforced with JavaScript's `.length`, this is the figure that decides the outcome.**

Tips for getting more out of it

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.

Where it comes in useful

Preventing an overflow in a database column

**Where storage is limited by bytes, Japanese text fits only a third of what you might assume.** You can confirm before you insert.

Designing an input limit for a form

It gives you the material to decide whether to cap by characters or by bytes.

Interfacing with a legacy system

In fixed-width files and Shift_JIS exchanges, the byte count is the column position.

Testing how emoji are handled

**You can confirm whether a string containing surrogate pairs is treated as the length you intend.**

Character-encoding terms

UTF-8: A scheme representing the world's characters in a variable one to four bytes. **ASCII takes one, Japanese three and emoji four** as a rule of thumb.
Shift_JIS: A scheme for Japanese in which **one Japanese character fits into two bytes.** It remains in use in older systems and fixed-width files.
EUC-JP: A Japanese scheme long used on UNIX systems. A Japanese character ordinarily takes two bytes.
UTF-16: A scheme representing characters in units of sixteen bits. **JavaScript strings are counted in these units.**
Surrogate pair: The arrangement by which **a character too large for one UTF-16 unit is expressed as a pair of two.** Emoji and certain characters fall into this class.
ISO-2022-JP: A scheme that switches character sets by escape sequence, long used in Japanese email. It is also known simply as JIS.

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.

Browse all trivia