Complete Guide to Japanese Zenkaku & Hankaku for Banking and Registration

Visually, Zenkaku characters sit inside a full square cell — the same width as a Kanji. Hankaku characters are compressed into roughly half that width. The visual difference is really a byte-encoding difference: Zenkaku Katakana, digits, and Latin letters are 2-byte characters, while Hankaku Katakana is a 1-byte character defined in JIS X 0201, the Japanese character encoding standard published in 1969 — years before 2-byte Japanese encodings like Shift-JIS existed. Half-width Katakana is not a modern shortcut; it is the original way Japanese text was represented on 8-bit systems, and it never went away because the banking infrastructure built on top of it never got rebuilt.

Japan's inter-bank clearing network, run by Zengin-Net (全国銀行データ通信システム), was built in the 1970s on fixed-width, 120-byte-per-record text files — the same 'Zengin format' that payroll and transfer files still use today. To fit a name into a fixed number of bytes on 1970s mainframe storage, the standard allocated a fixed field of 30 bytes for the recipient's name, using 1-byte half-width Katakana. Every bank connected to that network — including newer online banks — still has to produce and consume files in that exact byte layout to clear a transfer nationally, because rebuilding a real-time settlement system used by every financial institution in the country is a decades-long, extremely high-risk project that nobody undertakes just to modernize a name field. So the front-end website can look completely modern while the back-end transfer instruction it generates still has to squeeze your name into a 1969-era, 1-byte character set.

The rule is not 'the whole form must be half-width' — it applies field by field, and mixing them up is the most common source of confusion:

• フリガナ / Furigana (name reading) — almost always required in half-width Katakana. This is the field that gets encoded directly into the Zengin transfer record.
• 口座名義 / Account holder name as printed on the passbook — usually half-width Katakana, because it mirrors the same Zengin-derived field.
• Display name in online banking UI — often accepts full-width Kanji or Hiragana; this is a separate, purely cosmetic field with no byte constraint.
• Address (住所) — policy varies by bank. Many accept full-width Kanji for the address itself but require half-width digits for building numbers, room numbers, and postal codes.
• Phone number — nearly universal: half-width ASCII digits, no exceptions.

Because these rules differ field by field on the same form, people often convert everything to half-width and get rejected on the address line, or leave everything full-width and get rejected only on フリガナ. Check each field's own label before assuming one rule applies to the whole page.

The dakuten/handakuten splitting rule is the one manual conversion almost always gets wrong: 「ガ」 looks like one character but must become two half-width characters (ｶ + ﾞ), which is also why half-width text is sometimes one or two characters longer than the full-width original of the same word.

1. Identify which specific field is rejected — read the error message or the field label, since the rule is per-field, not per-form (see the section above).
2. Check the space between surname and given name. A huge share of 'invalid character' errors on フリガナ fields come from a full-width space (　) sitting between ヤマダ and タロウ instead of a half-width one — visually identical, byte-wise different.
3. Convert dakuten/handakuten characters correctly. Typing ｶ then ﾞ by hand often produces the wrong Unicode combining sequence; run the name through a converter instead of manually retyping it.
4. Re-check length limits after conversion. Because voiced characters expand from 1 to 2 characters when converted, a name that fit a 15-character full-width limit can overflow a stricter half-width character cap.
5. Watch for copy-paste sources. Text copied from a PDF bank statement, an Excel cell, or a macOS/Windows IME that defaults to full-width input frequently carries invisible full-width spaces or digits even when the visible text looks fine.

• IME default width. Most Japanese IMEs on macOS and Windows convert romaji input to full-width Katakana by default; typing directly into a half-width field without switching modes silently produces full-width text that looks correct on screen.
• Copy-paste from PDFs. Bank statements and government PDFs frequently embed full-width digits and spaces even in fields that look like plain ASCII, because the PDF was generated from a full-width source document.
• The surname/given-name gap. This is worth repeating separately because it is the single most reported cause: retyping the space manually instead of running the whole string through a converter almost always leaves a full-width space behind.
• Trailing punctuation. A full-width period or comma left over from a pasted abbreviation (e.g., a company suffix like 株式会社) will fail a strict half-width-only field even if every other character is correct.

The same 1-byte legacy constraint resurfaces well outside consumer banking: e-Tax (National Tax Agency e-filing) rejects full-width characters in several identifier fields; credit card issuer applications typically require half-width Katakana for the cardholder name exactly as it will be embossed; mobile carrier and eSIM registration forms (docomo, au, SoftBank, Rakuten Mobile) enforce half-width for name and address fields tied to billing; and crypto exchange KYC forms (bitFlyer, Coincheck, and similar) inherit the same bank-transfer-derived validation because they settle fiat withdrawals through the Zengin network. If a Japanese form rejects your input and the error mentions 'カタカナ' or '半角', the underlying reason is almost always the same legacy encoding constraint described above, regardless of which industry the form belongs to.

Everything above solves a single form field. Payroll processors and accounts-payable teams instead have to produce or receive an entire Zengin file — a plain-text file made of fixed 120-byte records, where every recipient name has already gone through the same Zenkaku-to-Hankaku conversion described here, multiplied across hundreds of rows. The practical workflow is: (1) normalize each recipient's name and furigana to half-width before it enters the payroll export, (2) run the finished file through a Zengin format validator to catch any Zenkaku characters that slipped into a half-width field, any record that is not exactly 120 bytes, or any trailer-record total that doesn't match the actual row count, and (3) convert the validated file to CSV when you need to reconcile it against an internal ledger in Excel. Skipping step 2 is why a payroll file that 'looks fine' in a text editor still gets bounced by the bank portal — a single stray full-width space in row 340 fails the whole batch.