I have a international webservice (6 languages) with about 1000 people daily who access from any device, from smartphones to internet-cafes.

The information displayed are a bit scientific, for example distances, amounts, and dates, and the format can affect the decimal separator and the understanding of values.

Sometimes 1.000,000 (German) is correct, sometimes 1,000.000 (English) is correct.

I should allow different formats, but what should happen if the user inputs 1.000 (one thousand in German formatting but one in English formatting)?

Unfortunately 'Don't Make Me Think' does not write a lot about formatting; the only thing suggested is to leave formulae blank to keep the company from wrong inputs.

Question: should I rely on the formatting of their device or should I let the user choose the format themselves?

  • 1
    Possible duplicate of Users entering the wrong decimal separators for US$ amounts
    – Midas
    Commented Apr 24, 2016 at 8:02
  • 1
    Not a duplicate, this question is based on a Answer of the suggested Duplicate (Option2). The suggested duplicate is a question about how should the developer check, but this question is Who should check, the developer or the OS.
    – Grim
    Commented Apr 24, 2016 at 8:19
  • What is the difference between the developer and the OS?
    – Midas
    Commented Apr 24, 2016 at 8:27
  • 2
    There are some. Well a developer usually has legs, knees, always has a head with a brain inside. But a OS is software, there are no legs, no knees, head or brain. Related to the questions they may have different formats.
    – Grim
    Commented Apr 24, 2016 at 8:33
  • 1
    Got you :) I made an edit to clarify, but please change or rollback if I've misunderstood anything else.
    – Midas
    Commented Apr 25, 2016 at 11:40

4 Answers 4


Regarding input: do your users really need to type thousand separators manually? If no (which is the most likely case), I would treat both . and , typed into the field as a decimal point and allow only one symbol of that kind for that value.

Regarding output of the values: IMHO, it is better to rely on OS formats by default, but to provide possibility to change the output format and give a subtle clue about availability of that option. Tooltip (via title attribute or other means), dismissable information message, or other alternatives can be used for that.


One way to resolve this is to not make people enter decimal periods. Reject any non numeric input and let people choose the unit (meter, centimeter, etc).

For dates, use a date picker rather than a textbox.

The risk of using user's locale setting is that if people are sharing information (e.g. in support forum/wiki) about how to enter fractional inputs, one party will write that you should use points and the other party will write that you should use commas, confusing both of them. There are some cases where this is unavoidable, but if you can avoid decimal input, then avoid them.

  • a date picker ok ... but the question is: what format (mm-dd-yyyy or dd-mm-yyyy 04-12-2012 match both), should i let the os decide or shall the website customize the format?
    – Grim
    Commented Apr 25, 2016 at 8:53
  • @PeterRader: For input, I recommend using a date picker which outputs in ISO 8601 date format. Your server should only deal with ISO 8601 dates. For output/display, I recommend using named months (e.g. 04 Dec 2012) in the user's locale, rather than either of the ambiguous formats you suggested. Alternatively, depending on the applications, many applications can also use relative date (e.g. "two days ago", "moments ago", "in two years"), which optionally may display the full date when hovered/clicked.
    – Lie Ryan
    Commented Apr 26, 2016 at 15:02

C#and javascript both have a few good tools for converting number formats... if you can get the country/language iso code from the user or site (eg "de-DE" for Germans), this is easy to do...

C#, for instance, has the CultureInfo class for this purpose...

  1. User goes to your site (eg. with "/de-DE/" somewhere in the URL)
  2. User enters his value in his format
  3. You can then convert to your desired numbering format for calculation/ storage.
  4. Before the result is sent back to the user, the values are converted to eg. German numbering format.

That way you can detect which culture the user is from, but you still have free reign over what format you wish to use for storage and calculations.

Nearly every language out there has a form of number format conversion either built in or available as an extension.

Now, whether you format numbers using the user's OS or your server mostly depends on what your needs are:

Using OS settings

  • easy to do with a client app, however it can be harder to grab OS settings through a browser. (You'll have to write code for each kind of browser you wish to support)

  • Output is formatted to the user's preference independent of location

  • Uses resources on the client's machine

Using the server

  • easier to do securely in the browser

  • Can be easily extended to allow the user to choose numbering format if needed

  • no user preferences or information is needed to be sent

    • easier to code across a larger number of browsers

    • uses the server's resources for conversion and calculation

  • Your answer is a stackoverflow-answer, the question is: should i format via javascript/c# or should i keep it to the OS of the user.
    – Grim
    Commented Apr 25, 2016 at 16:49

On the input side I would leave the thousand separator, and allow only numbers and decimal separator based on the language settings of the current user, but store the values in a unified way eg:

  • allow 1000.0 (as 1000) and store as 1000.0
  • allow 1000,0 (as 1000) and store as 1000.0

On the output side you can again rely on the language settings. And can change the separator as the user choosed.

This approach will let you store the entered values uniformly and let the users choose the display format (via language settings).

This will work fine for all kinds of inputs including dates.

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.