Why a calculator shows 0.1 + 0.2 = 0.30000000000000004

Type 0.1 + 0.2 into the calculator above and you will see 0.30000000000000004 instead of the tidy 0.3 you expected. The calculator is not broken — it is showing you the exact result of a specific binary arithmetic problem. Understanding that problem takes less than five minutes and will change the way you read any decimal result from any digital calculator.

Why 0.1 cannot be stored exactly in binary

Every number inside a computer is stored in binary — base 2, using only the digits 0 and 1. Fractions that look simple in decimal (base 10) are often infinite repeating fractions in binary, in exactly the same way that 1 ÷ 3 = 0.3333… repeats forever in decimal.

The decimal number 0.1 is one such fraction. In binary it is 0.0001100110011001100110011… — a pattern that repeats without end. A computer using the IEEE 754 double-precision standard (the format used by JavaScript, and therefore by every browser-based calculator) stores numbers in exactly 64 bits. Those 64 bits cannot hold an infinite string of digits, so the value is rounded to the nearest representable number. The rounded result is not exactly 0.1; it is:

0.1000000000000000055511151231257827021181583404541015625

The same happens to 0.2. Its binary representation is also an infinite repeating fraction, and after rounding it becomes:

0.200000000000000011102230246251565404236316680908203125

What happens when those two rounded values are added

When the calculator adds those two imprecise representations together, the tiny errors do not cancel each other out — they combine. The addition produces:

0.3000000000000000444089209850062616169452667236328125

That number, rounded to the nearest 64-bit float, becomes 0.30000000000000004. The extra 4 at the seventeenth decimal place is not a rounding mistake by the calculator — it is the mathematically correct result of adding two imprecise binary approximations according to the IEEE 754 standard. Every device, language and browser that follows the same standard produces the same answer.

Why this calculator shows 0.30000000000000004 rather than something cleaner

The calculator above uses JavaScript's new Function() to evaluate your expression, which means it relies directly on the JavaScript engine's native 64-bit floating-point arithmetic. There is no hidden rounding layer that cleans up the output.

Internally the code does round the result to 10 decimal places for most numbers — Math.round(result * 1e10) / 1e10 — but 0.30000000000000004 already has its first unexpected digit at the seventeenth decimal place, well beyond that rounding threshold. So the true floating-point result passes through unchanged.

Some calculators hide this by rounding aggressively to 12 or 13 significant figures before display. That approach produces a friendlier-looking 0.3, but it conceals precision that a scientific or financial calculation might actually need. The trade-off is real: more display rounding means fewer surprising outputs but also fewer visible digits.

Does this affect every decimal calculation?

No — and that is the key nuance. Whether an error shows up depends on whether the result can be represented exactly in 64-bit binary. Some additions happen to round perfectly:

• 0.1 + 0.4 = 0.5 — 0.5 is exactly representable in binary (0.1 in base 2), so the errors cancel and the clean answer appears.
• 0.25 + 0.25 = 0.5 — same reason: both values are exact powers of 2.
• 0.1 + 0.2 = 0.30000000000000004 — neither 0.1 nor 0.2 is exactly representable, and their combined error is large enough to survive display rounding.

The pattern is not "calculators are wrong about decimals." It is more precise than that: calculators are exact about binary fractions, and most everyday decimals are not binary fractions.

What to do when precision matters

• For everyday arithmetic — the error sits at the sixteenth or seventeenth decimal place and is completely irrelevant for shopping, cooking, or budgeting.
• For financial calculations — work in whole cents rather than fractional dollars wherever possible, or use dedicated accounting software that applies fixed-point arithmetic.
• For engineering or science — note the precision limit (about 15–17 significant digits for IEEE 754 double precision) and decide whether it matters for your measurement tolerance.
• To confirm a suspicion — subtract the expected value: 0.1 + 0.2 - 0.3 in the calculator above returns approximately 5.55e-17, the actual size of the error.

Try it: enter 0.1 + 0.2 - 0.3 in the calculator above. The result is not zero — it is roughly 5.55e-17, the exact gap between the stored approximation and the true value. That tiny number is what the extra 4 in 0.30000000000000004 represents.