How to change number decimal seperator in C#?

Changing the decimal seperator in programming environments might be a very critical task in multi-language supporting applications. Each country has their own decimal seperator and you have to handle all the conversion tricks.

For example in Europe, several countries use decimal comma seperator such as: France, Germany, Spain, Italy, Netherlands, Russia, Turkey, Norway, Sweden, Denmark and Finland.

Different countries use different decimal formats:

• US / UK: 1234.56 (dot as decimal separator)
• Germany/ many EU countries: 1234,56 (comma as decimal separator)

So the same number must be displayed differently depending on user culture.

There are several ways to handle decimal seperator in C# programming language.

Creating Extension Methods to change number decimal seperator in C#

First method to change number decimal seperator in C# is to create an extension method that does the conversion for you as given below.

First, define your extension method, and then use it wherever you want.

public static class DoubleExtensions
{
    public static string ToGBString(this double value)
    {
        return value.ToString(CultureInfo.GetCultureInfo("en-GB"));
    }
}
// ...
Console.WriteLine(value.ToGBString());

Changing current culture of the application to manage number decimal seperator

Second method to change number decimal seperator in C# is editing the current culture:

Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture("en-GB");

Just change the decimal seperator:

Thread.CurrentCulture.NumberFormat. NumberDecimalSeparator = ".";

Editing number decimal seperator in C# through config file

Edit config file of your application:

<system.web>
    ...
    <globalization 
        requestEncoding="utf-8" 
        responseEncoding="utf-8" 
        culture="en-GB" 
        uiCulture="en-GB" 
        enableClientBasedCulture="false" />
    ...
<system.web>

NumberFormatInfo for changing number decimal seperator in CSharp

Use NumberFormatInfo.NumberDecimalSeparator Property to change seperator:

NumberFormatInfo nfi = new CultureInfo( "en-US", false ).NumberFormat;

// Displays a value with the default separator (".").
Int64 myInt = 123456789;
Console.WriteLine( myInt.ToString( "N", nfi ) ); // 123,456,789.00

// Displays the same value with a blank as the separator.
nfi.NumberDecimalSeparator = " ";
Console.WriteLine( myInt.ToString( "N", nfi ) ); // 123,456,789 00

Best use cases

1. Displaying numbers in UI (most common)

double x = 1234.56;

Console.WriteLine(x.ToString(CultureInfo.InvariantCulture)); // 1234.56
Console.WriteLine(x.ToString(new CultureInfo("de-DE")));     // 1234,56 

Use case:

• invoices
• dashboards
• reports

2. Parsing user input

var culture = new CultureInfo("fr-FR");
double value = double.Parse("12,5", culture);

Use case:

• forms
• user-entered amounts
• configuration input fields

3. CSV / file export-import consistency

File.WriteAllText("data.csv", value.ToString(CultureInfo.InvariantCulture));

Use case:

• prevent Excel misreading numbers
• ensure consistent backend storage

4. API communication

Always use invariant culture:

jsonValue = value.ToString(CultureInfo.InvariantCulture);

Use case:

• REST APIs
• microservices
• logs

5. Thread or app-wide culture setting (less common, risky)

CultureInfo.DefaultThreadCurrentCulture = new CultureInfo("tr-TR");
CultureInfo.DefaultThreadCurrentUICulture = new CultureInfo("tr-TR");

Use case:

• single-country internal apps

Common issues (very important)

1. Parsing exceptions due to wrong culture

double.Parse("12,5"); // fails in en-US culture

Error:

FormatException

2. Silent wrong values (VERY dangerous)

double.Parse("12.5", new CultureInfo("ru-RU"));

In Turkish culture:

. is not decimal separator
may interpret incorrectly or throw

3. CSV / Excel corruption

Writing:

12.5

But Excel in TR locale expects:

12,5

Result:

• number becomes text
• formulas break
• wrong imports

4. JSON / API inconsistencies

Bad practice:

value.ToString() // depends on server culture

Correct:

value.ToString(CultureInfo.InvariantCulture) // always "12.5"

5. UI/backend mismatch bugs

Example:

• UI uses TR culture → 12,5
• backend expects invariant → 12.5

Result:

• parsing fails only in production

6. Thread culture confusion in web apps

In ASP.NET:

• request culture may change per user
• background services may use invariant culture

So same code behaves differently depending on context.

7. Floating-point + formatting confusion

Not directly separator-related, but often mixed:

0.1 + 0.2 // 0.30000000000004

When formatted, may look inconsistent across cultures.