Why 0.1 + 0.2 Doesn't Equal 0.3
Type `0.1 + 0.2` into your console, and you won't get `0.3`. It's not a JavaScript bug — you'll get the exact same result in Python, Java, or Go. IEEE 754, mantissas, and why you should never store money as a float.
Type 0.1 + 0.2 into your console. The result is 0.30000000000000004. You're not using a buggy library, your browser isn't broken — and this isn't a JavaScript bug either. Try it in Python, Java, Go, or whichever language you like, and you'll get the exact same result. That's because they all follow the same standard: IEEE 754.
The Base Problem
In base 10, you can't represent 1/3 cleanly; 0.333... repeats forever. Computers face the exact same problem, just in base 2. In binary, 0.1 is 0.000110011... — an infinitely repeating fraction. A number that looks trivial in base 10 becomes impossible in base 2.
The 64-Bit Limit
A JavaScript number occupies 64 bits in memory: one sign bit, eleven exponent bits, and fifty-two mantissa (fraction) bits. The infinitely repeating binary expansion of 0.1 gets chopped off at those fifty-two bits. What's left behind is a tiny, imperceptible rounding error. When you add the individual errors of 0.1 and 0.2 together, you end up with 0.30000000000000004.
Invisible in One Operation, Catastrophic in Millions
console.log(0.1 + 0.2); // 0.30000000000000004
console.log(0.1 + 0.2 === 0.3); // falseIn a single addition, this difference won't break anything. But when you have hundreds of additions in a shopping cart or millions of transactions in an accounting system, that error compounds. Eventually, a cent goes missing. Ledgers won't balance, and tests fail intermittently.
Warning: Never store money as a float
Set the ground rule right away: never store currency as a floating-point number. Store it as an integer in cents (or whatever the lowest denomination is) and divide it right before displaying it on the screen. If you must compare numbers, don't check for direct equality; check against a tiny tolerance instead: Math.abs(a - b) < Number.EPSILON.
Wrapping Up
This is still a popular interview question — not because of a random coding gotcha, but because it exposes a fundamental constraint of how computers represent numbers. Set this rule up front in any system dealing with money, and never worry about it again.
