I have an application that accepts a dollar amount in $USD. Unfortunately, some people are foreign/visitors to the US and type in amounts with commas instead of periods: they format the number as XXX.XXX,00 instead of the US format of XXX,XXX.00. The different expected formats are causing issues. Even though the text input field is showing the "$" as a field prefix and I have a placeholder of "USD", people are still typing the wrong format.


Expected US: 345.60
User Enters: 345,6
accounting.js translates to: 3456.00

The user then pays $3456.00! This is obviously not good and a huge mistake. At this point, I'm thinking it's very bad for me to even try to modify the text entered. Instead, I should force the user to type in the format correctly (exact). I can easily add a format/error message below the text field which describes the correct format in more detail with examples.

If I force them to type the correct format:

  • Should I allow commas?
  • Should I remove commas automatically from input?
  • Should I throw an error when a comma is used?
  • Should I throw an error when a decimal is not used?

Note: I'm forced into the USD $ format only at this time. Decimals are 99% common, but not required for the transaction to take place. I'm looking at using a regular expression to give the warning, such as /^\d*(\.\d{2}$)?$/.

  • 6
    Implementation-specific, so not an answer: Some platforms have widgets that ensure a standardized number representation is send to the backend, e.g. <input type=number> in HTML5.
    – Crissov
    Commented Mar 31, 2016 at 20:31
  • 11
    How about you just disallow any and all comma's in the text field? There's no need for a comma, even if the user is paying over one thousand.
    – SnakeDoc
    Commented Apr 1, 2016 at 15:08
  • 30
    You show a marker of $ or USD... so what? I'm still from Italy and I'm going to still use the same decimal marker as I'd use if it was asking for €. If I'm writing a document I'm not going to switch decimal marker for numbers of USD vs numbers in euro. I'd just consistently use . or consistently use ,.
    – Bakuriu
    Commented Apr 1, 2016 at 16:45
  • 30
    There is no connection between the $ sign and USD placeholder and the use of point vs comma
    – edc65
    Commented Apr 1, 2016 at 17:28
  • 3
    My bank's ATM just enters numbers from right to left, without commas. To enter $1,234.56, you just enter 123456 and the numbers slide from right to left starting at 2 decimal points. Just ignore commas and periods.
    – Chloe
    Commented Apr 2, 2016 at 9:00

12 Answers 12


Let's talk for a minute about user expectations and magic.

A user comes to your tool with certain expectations, and not every user's expectations are the same. You're seeing this first-hand. Culture, up-bringing and life experience all shape how a user will interact with a tool, opening a vast array of expectations to potentially meet.

One expectation almost every user has, however, is that when an illusionist or magician does a trick -- say, picking a card from a card deck -- the illusionist is always going to guess their card correctly.

Put another way, if your tool is going to automate something, and going to guess what the user meant to type, it needs to get that guess correct, or the user will end up disappointed or frustrated.

As you stated as well, they may end up overcharged which, if your system changed what they entered without their express desire and increased the amount, could make you legally responsible for the overcharge and get you in trouble.

To guess or not to guess; that is the question. So, we have two courses of action to choose from:

Option 1: Analyze what's typed in and fix it

In this case, you may need to look for a solution that can better accommodate all of the edge cases you're seeing. If accounting.js isn't correctly reformatting the text, you may need to do something more custom.

Enter the regular expression.

What you'll need to do is figure out all of the patterns you might encounter, which are correct, and which need to be changed. When we start looking at common cases,

 - ###.###,## > ###,###.##?
 - ###,###,## > ###,###.##?
 - ######,## > ###,###.## or ##,###,###? 

It starts getting tricky pretty quick. To do this you'll need to do enough testing to know if your test and replacement patterns are getting it all right, and you'll need to watch out that new patterns don't emerge.

As well, if one of your patterns incorrectly changes the content, the user might not notice you've updated the amount (or, when you ask them to confirm the updated value is what they meant, they could miss an important change) and end up paying the wrong amount. What's more, if you did it for them, you might be legally on the hook.

Option 2: Guide them to the right formatting

This option will take a little less work and be safer from a number of standpoints. It's probably also more likely to end up in a pleasant user experience.

Here, still look for a strangely formatted string. Too many periods, too many digits between commas, a comma delimiting the final two strings of numbers, things like this.

What'd I'd suggest is using some implementation of live field validation to confirm that they're formatting their input correctly. When they type something strange, click out of the box, or try and submit the form, make sure to process the string to flag any of the tests you're looking for. If it fails a test, display a message next to or below the field (have a look at some of these images for ideas of how to display the messages) that explains specifically what looks strange.

Don't change anything automatically -- ask them to do that themselves.

Check again as soon as you can whether they've made correct changes. Ideally do this before they have to hit the submit button again, when they focus-off from the field for example. If it's all good, display a message (in a friendly success color like green or blue) that tells them they successfully fixed the error. If they need to try and fix it again, re-display an error message, and indicate that you checked and they still have more to do.

Oops, looks like it's still not quite right. <error mitigation message follows.>

This way, they know they still have work to do and the form is explicitly asking for follow-up action.

Edit: In conclusion...

Consider the use cases in front of you and which option (or mix of the two) you feel you can implement to make the experience predictable and understandable for the user.

An interesting option that combines the two is the masking that @jjwdesign brought up in the comments. The form could either guide the user from the beginning how do do the conventions, displaying a subtle ___,___.__ in the field, or it might add/convert the punctuation as the user types a value in. We just need to be careful not to do this in a confusing way; as some point out throughout the comments on the page here, overriding a user's inputs can be disorienting.

Good luck!

  • 1
    I've decided on Option 2. I've got the warnings in place already with nice markup. What are you thoughts on using "masking"? Such as igorescobar.github.io/jQuery-Mask-Plugin
    – jjwdesign
    Commented Mar 31, 2016 at 15:05
  • 2
    Guide them to the right formatting, that's the right mindset, although you might want to Force them into the right formatting, Splitting the input field into two parts, [integers].[decimals].
    – Lars
    Commented Apr 1, 2016 at 10:23
  • 2
    @Lars I think you're head's in the right place. But splitting the two up ends up building to the edge case instead of supporting the major case, in which most everyone will put the number in correctly.
    – Matthew
    Commented Apr 1, 2016 at 12:52
  • 1
    @jjwdesign masking is certainly a neat option and helps show them what they should be doing, while also requiring specific input. Trouble can be if they add too large a number for the mask, but that's an implementation detail you can plan for.
    – Matthew
    Commented Apr 1, 2016 at 12:58
  • 4
    This is all very well until you get some Indian users, who write numbers as, e.g., $1,00,00,000.34 (ten million dollars and thirty-four cents). Commented Apr 1, 2016 at 21:52

Another option would be for the text field to ignore all non-numeric characters, and display appropriate formatting automatically.

For example:

User enters '3' -> Text field displays '0.03'
User enters '4' -> Text field displays '0.34'
User enters ',' -> Text field displays '0.34' (no change)
User enters '5' -> Text field displays '3.45'
User enters '6' -> Text field displays '34.56'
  • 15
    This is a common thing to accountants and cashiers (it's on many cashdesks and even CC terminals), but it's very counter-intuitive to other people.
    – yo'
    Commented Apr 1, 2016 at 9:32
  • 41
    PayPal does exactly this, and it's incredibly weird the first few million times you use it.
    – anon
    Commented Apr 1, 2016 at 13:07
  • 2
    @yo' no it's not. many online payment systems, even for food delivery, use this method.
    – SnakeDoc
    Commented Apr 1, 2016 at 15:11
  • 2
    @QPaysTaxes Not only incredibly weird, but annoying too
    – Insane
    Commented Apr 2, 2016 at 8:54
  • 3
    Every ATM I've ever used does this as well, excepting the cents. So it shouldn't be too unfamiliar to most people. Commented Apr 2, 2016 at 15:54

Show the user what's expected visually and show how the machine interprets the user's input.

My contribution to the brainstorm would be:

  • Use a reference to the cheque-form of the old days :)
  • Let the computer ignore all comma's and periods that the user enters (for that matter: non-numerical characters)
  • Show (if you're able to) an image in the background of your text-field, indicating the positions of the dollars, the cents and a period separating them.
  • Use a mono-spaced font for the number
  • Have the number right-aligned.

Now, as the user enters the amount, she'll see how the system interprets her input, automatically, with no script working (except maybe the script that rejects any comma's and dots):

draft explainging the idea


  • 1
    This. All of this. Commented Apr 3, 2016 at 15:15
  • 3
    I woudn't mind if the "3" starts in the leftmost dollar position, and the cents position stays zeroed until you hit . or ,. So the displays would be "3.00, 31.00, 314.00" until you hit .. As a final nicety, you could visually switch the hightlighted parts when you hit . or ,. Don't forget that you will need a backspace when somebody adds a . or , intending to use it as a digit group marker.
    – MSalters
    Commented Apr 4, 2016 at 0:28
  • 1
    You'll end up with many users wanting to enter "$30" and ending up with $0.30. I would instead recommend showing "$ 0.00" / "$ 0.03", "$ 0.31", "$ 3.14", and so on. And instead of having a very small, nearly invisible decimal separator, make it use a full digit with. That will indeed require some scripting, but is less error-prone IMHO.
    – jcaron
    Commented Apr 4, 2016 at 12:27
  • 1
    @nicodemus13 Yes, you're right, auch… That's why my circles always end up square :D But seriously, it is indeed 3.14159—2—65
    – Ideogram
    Commented Apr 5, 2016 at 13:12
  • 1
    @MSalters the trouble with switching to cents at a punctuation point is that some folks might type the in-between-dollars punctuation as well. When they type $314,159.65, we'd get "$314.15965" instead.
    – Matthew
    Commented Apr 7, 2016 at 14:12

You can do whatever you wish basically, as long as you provide a way to verify the input. I would personally dynamically display --next to the input field-- the amount at least partially written out, like

[ 123.45     ] (123 US dollars, 45 cents)
[ 123,45     ] (123 US dollars, 45 cents)
[ 123,456.78 ] (123 456 US dollars, 78 cents)
[ 123,456    ] (123 456 US dollars, 0 cents)

([] contains the input, () contains the verification. Note the usage of a non-ambiguous space as a thousands seperator.)

I don't say the method of interpreting the input I propose is the best one, but you provide an instant verification. To me (coming from a country with a decimal comma rather than decimal dot), it's intuitive to treat ,XX as cents, but to other people, ,XXX means units. Since an instant verification is provided, no harm should be caused.

Note: Just remember to submit both the user input (for later check what they actually wrote in case of doubt) and the verification (to be sure what the user saw and believed is thhe interpretation), and re-check that they are consistent when the form is submitted.

  • 1
    A very good solution. I think the feedback that the program has interpreted my input correctly is very important in this case.
    – hansmaad
    Commented Apr 1, 2016 at 11:36
  • 2
    That is what I thought of too. This provides instant verification without magical guessing invisible to the user. Even better if there's a placeholder with example value: e.g. 123,456.78, so that the user instantly knows the formatting rules.
    – fri
    Commented Apr 3, 2016 at 14:21

You could create two fields - 1 for dollars and 1 for cents. In this way you don't need any formatting logic and you can strip out any non-alphanumeric characters when you save to a database.

  • Unfortunately, it's posted in only one field.
    – jjwdesign
    Commented Mar 31, 2016 at 16:50
  • That's even worse: remember that users don't read what they should, and easily enter 123.45 in the first field and nothing in the second one. With your method, it's 12 thousand something, whereas they meant 1 hundred something.
    – yo'
    Commented Apr 1, 2016 at 9:33
  • 1
    @jjwdesign: What does “it’s posted in only one field” mean?
    – Ry-
    Commented Apr 4, 2016 at 3:01
  • To solve the problem yo' pointed out, I’d suggest showing an error on any non-alphanumeric characters.
    – Ry-
    Commented Apr 4, 2016 at 3:03

Locale is what this question is about. The fact that your users have to handle US dollars, does not mean they will do so in the locale of the 'owner' of this particular currency unit (USA). Date formats are another example of how different locales can render a value in ways that are ambiguous without knowledge of the locale the value was rendered in.

How a human expects to handle locale information depends on many factors which you cannot always predict as a programmer. What you can do, is give them enough information for them to know which locale they are experiencing the software in, or which aspects of that locale they have to deal with. In HTML, one way is to render localized placeholders that show the expected input format.

You have expressed your concern about people accidentally processing incorrect amounts of money. It may be good to request the user for final confirmation before processing the request. If you analyze the entered amount and it's in an unusual format, because it uses decimal and grouping separators that are different from those in en_US, you can always show a message that asks the user if they entered the correct amount.

  • 2
    I would mark this as a correct answer. Your app should parse user input based on USER's locale and not assume anything. Same thing will happen (and wreak even more havoc) if your app requests a date! Just think how most of the world uses intuitive formats such as dd.mm.yyyy or yyyy.mm.dd, while your app would probably except "twisted" us mm.dd.yyyy...
    – user100858
    Commented Apr 4, 2016 at 7:49
  • I second user100858's comments. This is the correct answer. Any "solution" that forces the user to specify a period as the decimal separator if their locale uses something else (e.g. a comma), is not correct.
    – Bill Dagg
    Commented Apr 27, 2016 at 22:13

The UX solution is to make it error free for the users no matter what format they're used to. Nothing more. Nothing Less.

I would recommend that you look into regex type solution:

  1. make certain there are two digits after the comma (add a 0 if necessary)
  2. then strip out all non-digits
  3. then add the decimal point.
345,6 becomes 
345,60 becomes 
34560 becomes

Regardless of the process, or your back-end tools, make it easy for your users. If they expect to put in 345,6 (instead of 345.60) then let them.

  • 3
    From my recent perspective, changing the text entered into the field is a very bad idea. Even if it's to correct the format. It could result into payment the incorrect amount.
    – jjwdesign
    Commented Mar 31, 2016 at 14:55
  • Yes it might. Putting error notices is a very good alternative. Using two text boxes works but I would try to avoid that. Regardless confirmation screens are important
    – Mayo
    Commented Mar 31, 2016 at 15:20
  • What do you think about jQuery .mask() plugin?
    – jjwdesign
    Commented Mar 31, 2016 at 16:52
  • 2
    @jjwdesign: I just experimented with the plugin. It should work in that one way or another it will force the user to put it into a format but I wasn't all that pleased with the results when I was trying to "break" it.
    – Mayo
    Commented Mar 31, 2016 at 17:58
  • 2
    34560 should not become 345.60 without some strong clues as to why. For example, you could always show the '.' and fill in the digits as the user types.
    – hhamilton
    Commented Mar 31, 2016 at 21:10

The banking site I use in Belgium only allows you to input the decimal notation but not the thousands separator.

It accepts either a single comma or a single dot for the decimal notation, but nothing else can be input.

I've done some more testing of how they treat the input field.

  1. You can only use , or a . once for the decimal notation, no thousands separator
  2. If you type 4, then try to type 4,, nothing happens, same as 4,000. you can't add the .
  3. You can type 4000.00 or 4000,00 and it converts both to 4000,00
  4. Copying and pasting isn't allowed
  5. 4,000 gets converted to 4,00 - this is an issue, certainly for a banking site, but it would only occur for people that type in thousand separators, not as with the case of the OP where people are using commas for decimal notation. As copying and pasting isn't allowed it would only be for people that want to type the thousand separator, which is typically only done for readability, but you might need to test how many people would do that.
  • I did something like that, but it caused a huge mistake.
    – jjwdesign
    Commented Mar 31, 2016 at 16:51
  • 4
    "so at the worst they will under pay" can actually be very serious, depending on what the payment is for and whether the user notices it.
    – Bob
    Commented Mar 31, 2016 at 23:59
  • I do agree that's an issue, the biggest problem I could see would be someone thinking they've paid for something when they haven't actually. However it's certainly less of an issue with someone paying $3,456 instead of $345.60.
    – icc97
    Commented Apr 1, 2016 at 9:21

In general try to avoid errors, they're the UI of last resort in my opinion. If there's anything that can be handled by system logic to avoid errors that should be the go to solution. Also avoid forcing them into a particular formatting. Try to anticipate the formatting they'll use, the microinteractions, and design your system around that.

A question for you...How often are people going to be entering decimal amounts into this field?

My suggestion would be to default format the number so it displays as by default, when the user first sees it, and any user entry goes between the dollar sign and the decimal point? If you implement it that way any user entry is interpreted as the dollar amount, and if users won't ever enter decimal amounts you can stop there.

However, if you need to account for decimal amounts, you could prevent any alteration of the decimal amount until the user types "." on their keyboard, at which point they enter the decimal section of the field. To solve your specific problem, you could treat "," the same way. When users key "," on their keyboard enter them into the decimal amount section.

So the user interaction would follow as such...

  1. Enter dollar amount
  2. Key "." or ","
  3. Enter decimal amount
  4. Finish
  • I'm forced into the USD $ format only. I also am forced into using only one field. Decimals are 99% common, but not required for the transaction to take place. I'm looking at using a regular expression to give the warning, such as: /^\d*(\.\d{2}$)?$/
    – jjwdesign
    Commented Mar 31, 2016 at 14:51

I had the problem with an app for German users in the past. I sticked to the dot notation (for computers) and wrote a js to transform all commas to dots (no need to type the 1000s delimiter, the js would display whitespaces for that). I wanted to make sure that no comma reaches the backend server.

There were different respones by the users. Some did not note anything (e.g. non-Germans). Some were surprised, but adapted to it (e.g. bloomberg users). Some were confused and asked about the comma (e.g. heavy excel-only users).

Warning: this is just what I did. I am not an UX person who can jugde if such an approach is a good thing.


I tend to use autoNumeric for number input fields, always I set it to accept both comma and dot/period/whatever you call it as decimal separator, without any thousands separator (seriously, who whould even use it in input?) Unfortunately even if you set it up to accept comma as decimal separator when you paste number using comma it just drops it (I'm currently writing issue)... But at least on keyboard input it behaves properly


Require the input to have a single dot followed by exactly two digits, with no commas. But allow the user to type multiple dots and commas into the field. If these requirements are not met when the user clicks outside the box, reject the input and show a text error so the user must manually remove stray commas and put a dot and the number of cents.

A note can be placed before the field: "Input must end in .XX, such as $XXXX.XX".

If the user types any commas but is forced to manually remove them, there is no possibility that the user assumes a comma was accepted. And since the dot and cent amount is required, the user is forced to see that the input includes cents.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.