🔡 Japanese Character Counter (文字数・バイト数)

Counting text in Japanese is not as simple as it looks. A single "character" can be a half-width Latin letter (1 byte in Shift-JIS), a full-width kana or kanji (2 bytes in Shift-JIS), or a full-width Latin letter (also 2 bytes). Forms, databases, and legacy Japanese systems often have limits expressed in byte counts rather than character counts, so a string that fits in 30 characters may overflow a 30-byte field. Knowing both the character count and the byte count - in both UTF-8 and Shift-JIS - is essential for filling out Japanese web forms, designing database columns, and writing SMS or tweet-length copy.

This Japanese character counter reports the character count with and without spaces, the line count, the UTF-8 byte count, the Shift-JIS byte count, and a breakdown of full-width vs half-width characters. It is built for writers localising copy into Japanese, developers sizing database fields, and anyone filling out a Japanese government or banking form with a byte limit. For the related tasks of converting kana or romanising text, use the kana converter and the romaji converter.

Refer to the table below for how different character types contribute to the counts:

The counter walks the input once and, for each character, records its UTF-8 byte length (1 for ASCII, 2 for Latin-1 supplement and Greek, 3 for kana, kanji, and most symbols, 4 for emoji and astral-plane characters) and its Shift-JIS byte length (1 for ASCII and half-width katakana, 2 for full-width kana, kanji, and full-width Latin). It also classifies each character as full-width or half-width by checking its Unicode block, and counts spaces and line breaks separately so you can get a "no spaces" total.

The table below lists the Unicode ranges used to classify width:

All counting runs locally in your browser, so even sensitive text never leaves your device. To prepare the text first - normalising width, converting kana, or romanising - pair this tool with the kana converter and the romaji converter, or check readings with the kanji reading lookup.

1. Paste your Japanese (or mixed) text into the input box.
2. The counters update instantly as you type or paste.
3. Check the character count with and without spaces.
4. Check the UTF-8 and Shift-JIS byte counts for form or database limits.
5. Use the full-width vs half-width breakdown to plan width normalisation.

Why are there two different byte counts?

Different systems encode Japanese differently. Modern web pages use UTF-8 (where a kanji is 3 bytes), while many older Japanese government and banking systems use Shift-JIS (where a kanji is 2 bytes). The tool reports both so you can match whichever system is checking your input.

When a form says it takes 30 bytes, which encoding does it mean?

It almost always means Shift-JIS bytes, because that is the legacy encoding Japanese back-end systems still use. Plan for 2 bytes per full-width character in that case.

How are emoji counted?

Emoji are typically 4 bytes in UTF-8 and are not representable in basic Shift-JIS, so they often cause legacy forms to reject the input. The counter shows their UTF-8 byte cost so you can spot them.

Does it count words as well as characters?

It focuses on characters and bytes because Japanese has no spaces between words, making a space-split word count unreliable. The character count is the standard length metric for Japanese text.

What is the difference between full-width and half-width?

Half-width characters (A, 1, ｱ) are narrow and cost 1 Shift-JIS byte; full-width characters (Ａ, １, ア, 日) are wide and cost 2. Full-width Latin and digits are produced by Japanese IMEs and are often normalised to half-width before submission.

Is my text sent to a server?

No. All counting happens in your browser with JavaScript. Nothing is uploaded, stored, or logged, so it is safe to paste private or draft text.

When a Japanese form says it accepts "30 bytes", it almost always means Shift-JIS bytes, because that is the legacy encoding most government and banking systems still use internally - so plan for 2 bytes per full-width character. Full-width digits and Latin letters (０１２３, ＡＢＣ) cost 2 Shift-JIS bytes each, while their half-width twins cost 1, so normalising to half-width before submission often saves space. Emoji count as 4 UTF-8 bytes and are usually rejected by legacy forms. For tweets and other Unicode-aware systems, the UTF-8 count is what matters. If you need a word count for Japanese, remember that Japanese has no spaces, so a space-split word count is unreliable - the character count is the standard metric instead. To clean up width before counting, run the text through the kana converter first.