Define optional normalization of full-width characters in <input type="number">

[kyouhei-horizumi]

What is the issue with the HTML Standard?

Problem Statement

In Japanese input environments, users frequently type full-width digits and symbols using IMEs when entering numbers. However, because <input type="number"> does not accept these characters, the element is often avoided in Japan — even when it would otherwise be the semantically correct choice.

Real-World Example

In Japan, it is common to switch between Japanese and English input modes using an IME, depending on the content being typed. For example, consider a form with two consecutive fields: a name field and an age field, where the age field uses <input type="number">.

A user would naturally enter their name in full-width Japanese characters. Without consciously switching to English input mode, they might then move directly to the age field and continue typing in the same (Japanese) input mode.

When using a Japanese IME, typing numbers or symbols in this state produces full-width digits and punctuation. As a result, browsers may reject the input: some versions of Chrome (up to version 138) discard it entirely upon confirmation, while in WebKit, the input appears to succeed but the .value becomes an empty string.

While experienced users might eventually notice what’s happening, in practice this leads to real-world confusion. At my company, we have even received calls from users reporting this as a bug in our forms.

Since JavaScript cannot intercept or correct full-width characters before they are rejected, developers are often forced to avoid using <input type="number"> altogether — even when it would be the appropriate semantic choice.

Affected Characters

The following characters are commonly produced by Japanese IMEs during numeric input in full-width mode:

• Full-width digits: U+FF10–U+FF19
  → Example: '１２３４５６７８９０' (instead of '1234567890')

• Minus sign variants:

  • U+FF0D: Full-width hyphen-minus (often produced on Windows in full-width alphanumeric input)
    → '－123'
  • U+2212: Unicode minus sign (commonly produced on macOS in full-width alphanumeric input)
    → '−123'
  • U+30FC: Long sound mark (inserted when typing a minus sign alone in kana mode)
    → 'ー123'

• Full-width full stop: U+FF0E
  → Used for decimal points in numbers like '３．１４'

Current Browser Behavior

The handling of full-width numeric characters in <input type="number"> currently varies across major browsers:

• Blink (Chromium)

  • Prior to version 139, typing full-width characters (e.g., １２３) into a number field and confirming the input would cause the text to be silently cleared.
  • Starting in version 139, normalization of U+FF0D (full-width hyphen-minus) and U+30FC (long sound mark) was implemented during native keyboard input, allowing input like ー１２３ or －５ to be accepted as -123 or -5.
    This behavior was implemented by the author of this issue (Chromium CL 6609680).
  • Normalization of U+2212 (Unicode minus sign) is currently in progress at: https://chromium-review.googlesource.com/c/chromium/src/+/6665760
  • Assignment via JavaScript (e.g., input.value = '１２３') strictly follows the HTML specification and is rejected — the value is not accepted, and .valueAsNumber is NaN.

• WebKit (Safari)

  • A patch is currently under review to normalize the following characters during native keyboard input only:
    • Full-width digits: U+FF10–U+FF19
    • Minus sign variants: U+FF0D, U+30FC, U+2212
    • Full-width full stop: U+FF0E
  • Related discussion: Bugzilla Issue / Patch or PR
  • Like Chromium, JavaScript assignment via .value does not trigger normalization. The field may display the characters, but .value is empty internally if the input is invalid.

• Gecko (Firefox)

  • Both native keyboard input and JavaScript assignment (e.g., input.value = '１２３') are accepted as valid numeric input.
    This behavior has been in place at least since before December 2024, when I first became aware of the issue.
  • Gecko appears to have recognized this issue early on and has implemented permissive behavior accordingly.
  • Full-width digits and many symbol variants are accepted and parsed as numbers, including some emoji-like or decorative numerals.
  • However, U+30FC (long sound mark) is not supported and will cause the input to be rejected or interpreted as invalid.
  • This behavior is more permissive than in Chromium or WebKit, but it is not defined in the HTML specification.
    • A separate issue has been opened to discuss whether such permissive behavior is conforming per the current spec: Gecko accepts non-conforming full-width digits in <input type="number"> #11405

This inconsistency leads to compatibility issues for web developers and confusion for users — especially in regions where full-width input is the norm.

Proposal

Update the HTML specification to allow user agents to normalize certain full-width characters during native text input in <input type="number">.

Specifically, the characters listed in the Affected Characters section should be explicitly allowed — or recommended via a should statement — to be normalized by the user agent before parsing or rejecting the input.

This would reflect current behavior in some engines and clarify expectations across implementations.

Benefits of standardizing this behavior include:

• Improved usability in East Asian input environments
• Reduced developer confusion and workaround code
• Better interoperability across browsers

If there's interest, I’m happy to help draft concrete spec text or open a pull request to formalize this.

This proposal does not seek to change the behavior of JavaScript assignment to .value. For discussion on whether such input should be considered conforming, please refer to issue #11405 .

Reference

• Test case (non-WPT): https://bug-284363-attachments.webkit.org/attachment.cgi?id=475645
• WebKit Bugzilla issue: https://bugs.webkit.org/show_bug.cgi?id=284363
• WebKit Pull Request: <input type="number"> does not support full-width numbers (e.g., "ー２００") for Japanese IME users WebKit/WebKit#47095
• Chromium issue: https://issues.chromium.org/issues/383232110

---

Let me know if this is something we could move forward with.

Acknowledgments

I’d like to thank Anne van Kesteren for their thoughtful discussion and encouragement in raising this issue.

I’m also grateful to everyone who has provided feedback and support during related development and review work in Chromium and WebKit — your input has been instrumental in shaping this proposal.

Thank you all for helping improve the consistency and usability of the web.

[myakura]

I don't know whether keyboards or IMEs support, but adding inputmode="numeric" would be nicer for this case?

I've personally encountered such input requiring ASCII numeric characters while using my Japanese IME. so I understand your frustration. However, I'm afraid that silently changing the script type on input after typed without clear guidance might further confuse users.

[annevk]

I think at a minimum we should test that the value setter does not accept non-ASCII. That's weird.

I could see doing more. We currently have this note at https://html.spec.whatwg.org/multipage/input.html#number-state-(type=number):

This specification does not define what user interface user agents are to use; user agent vendors are encouraged to consider what would best serve their users' needs. For example, a user agent in Persian or Arabic markets might support Persian and Arabic numeric input (converting it to the format required for submission as described above). Similarly, a user agent designed for Romans might display the value in Roman numerals rather than in decimal; or (more realistically) a user agent designed for the French market might display the value with apostrophes between thousands and commas before the decimals, and allow the user to enter a value in that manner, internally converting it to the submission format described above.

I think what @myakura might be hinting at is that it would be unexpected if you entered １２３ in a numeric control to have it reflected back as 123. However, preserving the input only works as long as you then not manipulate the value through stepping. So I'm not sure how much value there is in that. Perhaps if the Japanese locale always formatted numbers in full width that could be used for display, but either way you'll see some conversion happening.

cc @whatwg/forms @whatwg/i18n

[kyouhei-horizumi]

I don't know whether keyboards or IMEs support, but adding inputmode="numeric" would be nicer for this case?

Thank you. That's a good point.

Just to clarify: currently, inputmode="numeric" is defined in the HTML specification as a hint for virtual keyboards only. It does not affect IME behavior on desktop platforms.

https://html.spec.whatwg.org/multipage/interaction.html#input-modalities:-the-inputmode-attribute

For example, when I tested this in Chrome 137 on macOS and Windows, setting inputmode="numeric" did not change the input mode of the Japanese IME — it remained in its previous state (e.g., full-width input). So full-width digits like ２３４ could still be entered without any restriction. (though they won’t be reflected in the input's value).

Because of this, inputmode alone doesn't prevent the issues we're trying to address here — such as full-width input being silently rejected by <input type="number">.

[kyouhei-horizumi]

@annevk Thank you again for your insights.

As the conversation has progressed, I realized that there are actually two distinct (but related) topics:

1. Normalization during native input (typing/pasting): Whether the HTML specification should explicitly allow (or recommend) user agents to normalize full-width characters like ２３４, －, or ． during user input into <input type="number">. -- This is the main focus of this proposal.

2. Programmatic .value assignment: Whether assigning a full-width string to .value (e.g., input.value = '２３４') should be accepted. According to the current HTML specification, the value must be a valid number string, so full-width characters would not be considered conforming. It seems that only Gecko currently accepts this input, which may be worth discussing separately to determine if this behavior aligns with the spec.

Out of respect for scope (and your help in shaping this proposal), I’d like to keep this issue focused on the native input case (1).
The discussion about programmatic assignment — including related Web Platform Tests (WPT) — would be better handled in a separate issue.

If you're interested in exploring (2) further, I’d be happy to open that follow-up issue.

[r12a]

Very nicely written issue @kyouhei-horizumi . Thanks for raising this.

I put together a very simple codepen at https://codepen.io/r12a/pen/PwqVJym.

I noticed, while playing with it, that if you increment/decrement the number in Firefox the full-width characters are replaced by proportionally-spaced ones. I therefore have a question for you: I wonder whether this conversion should occur as the user types, rather than after using controls to change the number. In other words, as the user types full-width digits, the form control automatically converts to and displays ASCII digits(same for dashes and dots), ie. the user would never see the fullwidth glyphs even though they are typing them.

The issue could be extended to cover many other scripts which have their own digits. For example, the behaviour noted for Japanese above appears to apply also to, say, the Arabic digits ١٢٣٤: (and other scripts, except for some recently encoded ones) Firefox displays and recognizes the native digits, but converts immediately to ASCII internally and replaces them with ASCII when incrementing using the control; Chrome 138 doesn't display or handle the native digits; and Safari displays the native digits in the form, but doesn't handle via JS and increments from 0. It's not clear to me whether, for those scripts, changing the encoded code points for display is a good idea — there is, of course, a significant difference in shapes between native and ASCII digits that is not relevant to the case for Japanese fullwidth numbers. Did you consider other native digits while fixing Chrome?

(There are other issues to be taken into account for native digit representations, related to types of numbering, base, etc, but they are probably not relevant for this particular discussion, especially for modern usage.)

[annevk]

If you're interested in exploring (2) further, I’d be happy to open that follow-up issue.

I think we should treat it as non-conforming and test it as such, but feel free to track that as a new issue if you wish.

[kyouhei-horizumi]

Thanks for the suggestion. I went ahead and opened a follow-up issue as you mentioned: #11405

It focuses on whether such input is conforming under the current spec, which seems to be relevant to Gecko's current behavior.
Would appreciate any thoughts you have there!