Explore Numeric Input Problems
See the 7 most painful problems with numeric inputs in web apps. Try each demo yourself to experience why numora exists.
Paste Chaos
Users paste numbers in every format imaginable
Real users paste values from spreadsheets, financial reports, different locales, and scientific tools. Native inputs either reject them outright or silently corrupt the data. Click the paste buttons below to see what happens.
Cursor Position Hell
Formatting destroys cursor position
When you format a number (adding commas), the cursor jumps to the end. Try typing 1234567 rapidly in both inputs and watch the cursor.
Type rapidly and watch the cursor jump to the end after each keystroke:
Cursor at position: 0
The cursor always jumps to the end, making editing impossible.
Type rapidly and the cursor stays in the logical position:
Cursor at position: 0
Cursor stays where you expect it, even as commas are added.
Scientific Notation Expansion
1e-18 should expand to 0.000000000000000001
In crypto and DeFi, users frequently deal with very small or very large numbers. Pasting 1e-18 (1 wei) should display the full decimal representation, not the scientific notation.
1e-180.0000000000000000011.5e-70.000000152.1e+152100000000000000Native displays:
(empty)Shows scientific notation or loses precision entirely
Numora expands:
(empty)Full decimal expansion with precise representation
Mobile Keyboard Gremlins
Hidden characters that break your validation
Mobile keyboards often insert non-breaking spaces (U+00A0), zero-width characters, or other invisible Unicode. These break validation and calculations silently.
When copying "1 234" from a mobile app, you might get:
What you see:
1 234What's actually there (hex):
31 C2 A0 32 33 34(C2 A0 = UTF-8 non-breaking space)
The Decimal Dilemma
Is 1,234 one thousand or 1.234?
In the US, 1,234.56 means one thousand two hundred thirty-four and 56 cents. In Europe, the same number is written as 1.234,56. Native inputs have no idea which you mean.
Try typing 1.2.3.4 or1,2,3,4 to see how multiple separators are handled.
Valid for US:
1,234.56Confusing for US:
1.234,56Type 1,234.56:
Native input rejects commas entirely and can't be configured for locale.
Type 1,234.56:
Configurable decimal separator. Multiple decimals are automatically prevented (only the first is kept).
Thousand Separator Traps
Format on blur is jarring, format on change is hard
Formatting numbers with thousand separators as users type is surprisingly difficult. Most implementations either format on blur (jarring) or format on change (cursor jumps). Different regions also use different grouping styles.
Type 1234567 and watch the cursor:
Problems:
- Cursor jumps to end after each keystroke
- Editing in the middle is impossible
- Only supports one grouping style
Type 1234567 smoothly:
Features:
- Cursor stays in logical position
- Edit anywhere without issues
- Supports Thousand grouping: 1,234,567
The type="number" Lie
It seems right, but it's deeply broken
<input type="number"> seems like the obvious choice for numeric inputs, but it has fundamental problems that make it unsuitable for most real-world applications.
Hover and scroll to accidentally change the number
Thousand separators are rejected
Ugly increment/decrement buttons appear
Allows "e" but not "," - counterintuitive
Screen readers struggle with the format
Some mobile browsers show wrong keyboard
.value might differ from displayed text
Hover over the input and use your scroll wheel:
- Hover and scroll to change value accidentally
- Try typing 1,000 (comma rejected)
- Notice the ugly spinner buttons
Implementation:
<input type="number" />Same test - hover and scroll:
Numora uses:
- type="text" - no scroll hijacking
- inputmode="decimal" - mobile numeric keyboard
- Full formatting support with commas
- Consistent, predictable behavior
Implementation:
<input type="text" inputmode="decimal" />Ready to solve these problems?
numora handles all of this out of the box. No more regex nightmares, no more cursor jumping, no more precision loss.