Introduction

Converting decimal to double in C# is easy syntactically, but it is not a neutral operation. You are moving from a base-10 type designed for exact financial values into a binary floating-point type designed for range and speed, so the main question is not how to cast, but whether the conversion is appropriate for your data.

Use an Explicit Conversion

C# requires an explicit conversion from decimal to double because precision can be lost. The two common forms are a cast and Convert.ToDouble.

1decimal price = 19.95m;
2
3double asDouble1 = (double)price;
4double asDouble2 = Convert.ToDouble(price);
5
6Console.WriteLine(asDouble1);
7Console.WriteLine(asDouble2);

Both lines produce a double, and for ordinary values they behave the same. The important part is that the conversion is explicit, which forces you to acknowledge that the target type is less precise for many decimal fractions.

Understand Why Precision Changes

decimal stores numbers in a form that is well suited for exact base-10 quantities such as prices and tax rates. double follows IEEE 754 binary floating-point rules, which means many decimal fractions cannot be represented exactly.

That difference becomes visible with formatting:

1decimal amount = 0.1m;
2double converted = (double)amount;
3
4Console.WriteLine(amount);
5Console.WriteLine(converted.ToString("R"));

The "R" format specifier prints a round-trippable representation of the double, and it often reveals the tiny binary approximation that was hidden by normal formatting.

This is why financial code usually stays in decimal even when conversion is technically possible.

Convert Only at the Boundary

A good pattern is to keep calculations in decimal for as long as possible and convert only when an API requires double. Many math and graphics APIs are built around double, so a conversion at the edge of the system is normal.

1decimal radius = 12.5m;
2
3double area = Math.PI * Math.Pow((double)radius, 2);
4Console.WriteLine(area);

Here the conversion happens because Math.Pow works with double. That is a reasonable place to convert, because the API is already defined in floating-point terms.

Do Not Mix the Types Blindly

The most error-prone code is code that jumps back and forth between decimal and double during the same calculation pipeline. Pick one type for the core computation and stay with it.

1decimal subtotal = 12.30m;
2decimal taxRate = 0.08m;
3decimal total = subtotal + subtotal * taxRate;
4
5Console.WriteLine(total);

If you later need a double for charting or interop, convert once at the handoff:

double chartValue = (double)total;

That keeps the precision-sensitive part of the logic in the safer type.

Cast Versus Convert.ToDouble

For this particular conversion, a cast is usually the clearest option:

double value = (double)myDecimal;

Convert.ToDouble is more common when writing generic conversion code or working with boxed values:

object boxed = 42.75m;
double value = Convert.ToDouble(boxed);

In ordinary application code, the cast is shorter and makes the type change obvious.

Common Pitfalls

The biggest mistake is assuming that a successful cast means the number stayed exact. Many values survive the conversion only approximately, even though the printed output looks normal at first glance.

Another common issue is converting money-related values to double too early. Once that happens, later arithmetic may accumulate rounding noise that would not have existed in decimal.

Mixing decimal and double in the same expression is also awkward in C#, because the compiler does not silently combine them the way some developers expect. That friction is a clue that the program should settle on one numeric model for the calculation instead of bouncing between both.

Finally, do not optimize blindly for speed. double arithmetic is often faster, but if correctness depends on exact decimal behavior, the faster answer is the wrong answer.

Summary

• Convert from decimal to double with an explicit cast or Convert.ToDouble.
• The conversion can lose precision because double uses binary floating-point representation.
• Keep precision-sensitive calculations in decimal and convert only when an API requires double.
• Avoid mixing decimal and double repeatedly inside the same calculation pipeline.
• For money and other exact base-10 values, decimal is usually the safer long-term type.