Japan Number Format

Format Rules

What's different here

Japanese number format

Japanese (ja-JP) punctuates numbers like en-US and zh-CN: 1234567.89 is 1,234,567.89. The differences are elsewhere. Yen amounts have no decimals, and the yen sign depends on the locale: ja-JP prints ￥ (U+FFE5 FULLWIDTH YEN SIGN), while en-US prints ¥ (U+00A5 YEN SIGN). Compact numbers use 万, 億 and 兆. And Japanese input methods can enter full-width digits, which Number() can't read.

￥ and ¥: two yen signs

new Intl.NumberFormat('ja-JP', { style: 'currency', currency: 'JPY' }).format(1234567.89);
// → "￥1,234,568"    (U+FFE5 FULLWIDTH YEN SIGN)
new Intl.NumberFormat('en-US', { style: 'currency', currency: 'JPY' }).format(1234567.89);
// → "¥1,234,568"     (U+00A5 YEN SIGN)
new Intl.NumberFormat('zh-CN', { style: 'currency', currency: 'JPY' }).format(1234567.89);
// → "JP¥1,234,568"
new Intl.NumberFormat('ja-JP', { style: 'currency', currency: 'CNY' }).format(1234567.89);
// → "元 1,234,567.89"   (U+00A0 after 元)
new Intl.NumberFormat('ja-JP', { style: 'currency', currency: 'JPY', currencyDisplay: 'name' }).format(1234567.89);
// → "1,234,568円"

• The same currency gets a different character depending on the locale. A test that expects ¥1,234,568 fails against ja-JP output. Compare formatToParts() or the ISO code, not the glyph.
• With the default currencyDisplay: 'symbol', ja-JP shows the yuan as 元, so yen and yuan never share a sign in ja-JP output. The clash happens in other locales: en-US writes the yen as ¥ and the yuan as CN¥, and in zh-CN the yen becomes JP¥.
• With currencyDisplay: 'narrowSymbol', ja-JP prints ￥ for both: JPY as ￥1,234 and CNY as ￥1,234.00. Use ISO codes when both currencies can appear.
• currencyDisplay: 'name' gives the 円 form used in Japanese text.

万, 億, 兆, and how they differ from Chinese

const ja = new Intl.NumberFormat('ja-JP', { notation: 'compact' });
ja.format(9999);           // → "9999"
ja.format(12345);          // → "1.2万"
ja.format(123456789);      // → "1.2億"
ja.format(1234567890123);  // → "1.2兆"

const zh = new Intl.NumberFormat('zh-CN', { notation: 'compact' });
zh.format(123456789);      // → "1.2亿"
zh.format(1234567890123);  // → "1.2万亿"

new Intl.NumberFormat('ja-JP', { style: 'currency', currency: 'JPY', notation: 'compact' }).format(350000000);
// → "￥3.5億"

• 億 (U+5104) and the Simplified Chinese 亿 (U+4EBF) are different characters. Reusing zh-CN strings or translations for Japanese gets them wrong.
• At 10¹², Japanese switches to 兆 while zh-CN writes 万亿.
• ja-JP has no short word for thousands, so 9,999 stays 9999.

Full-width digits in user input

Japanese input methods can enter full-width digits, U+FF10–U+FF19 (１２３), instead of ASCII. It happens when a user stays in Japanese input mode while moving from a text field to a number field. Responding to a WHATWG proposal on this, the W3C Internationalization Working Group noted that "CJK users are often not thinking about wide-vs-narrow input". JavaScript's number parsing and \d only accept ASCII digits, so normalise with NFKC first:

const typed = '１２３，４５６';
Number(typed);                                       // → NaN
/^\d+$/.test('１２３');                               // → false
typed.normalize('NFKC');                             // → "123,456"
Number(typed.normalize('NFKC').replace(/,/g, ''));   // → 123456
'￥１，２００'.normalize('NFKC');                        // → "¥1,200"
'ー１２'.normalize('NFKC');                            // → "ー12"

• Unicode defines each full-width digit, comma, full stop, hyphen-minus (U+FF0D) and ￥ as a compatibility (<wide>) form of its ASCII or Latin-1 counterpart, so NFKC normalisation converts them. Normalise before parsing or validating.
• NFKC does not touch ー (U+30FC, the long-vowel mark) or − (U+2212 MINUS SIGN). The WHATWG issue reports that Japanese IMEs can produce both when the user means a minus sign. Map them to - yourself if negatives are allowed.
• <input type="number"> is no shortcut. The HTML Standard requires the field's value to use ASCII digits, and browsers differ in what they accept from the keyboard. A proposal to standardise full-width normalisation is still open (WHATWG issue #11395, PR #11616).

Q&A

Why does my test expect ¥ but Intl returns ￥?

Because the test was written for en-US. ja-JP output uses U+FFE5 FULLWIDTH YEN SIGN (CLDR ja.xml), and en-US output uses U+00A5 YEN SIGN. Both mean JPY. Assert on the code or on formatToParts().

How do I tell JPY from CNY?

With the default symbol display, ja-JP shows ￥ for JPY and 元 for CNY (with narrowSymbol, both get ￥). In en-US, ¥ is JPY and CN¥ is CNY. In zh-CN, ¥ is CNY and JP¥ is JPY. Store the ISO code with every amount.

Is 億 the same as Chinese 亿?

Same value (10⁸), different character. ja-JP uses 億 (U+5104), zh-CN uses 亿 (U+4EBF), and above 10¹² they split again (兆 vs 万亿).

Why does Number() return NaN for a Japanese user's input?

The input probably contains full-width digits from a Japanese input method. Run input.normalize('NFKC'), map ー and − to a minus if needed, then parse.

Code Examples

// Basic number
new Intl.NumberFormat('ja-JP').format(1234567.89)
// → "1,234,567.89"

// Currency
new Intl.NumberFormat('ja-JP', {
  style: 'currency',
  currency: 'JPY'
}).format(1234567.89)
// → "￥1,234,568"

// Percentage
new Intl.NumberFormat('ja-JP', {
  style: 'percent',
  minimumFractionDigits: 1
}).format(0.125)

// Compact notation
new Intl.NumberFormat('ja-JP', {
  notation: 'compact'
}).format(1234567)

Negative Number Formats

Edge Cases & Notes