Why is 0.1 + 0.2 not exactly 0.3?

Q: Why is 0.1 + 0.2 not exactly 0.3?

**Target Audience:** Engineers preparing for JavaScript fundamentals interviews. **Difficulty:** Medium > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . Every number below, including the raw bit-level rounding, was actually printed by Node — not asserted from memory. ## 1. Why This Even Matters — A Story First Try writing exactly one-third as a decimal: `0.333...` never terminates, so any fixed number of digits is an approximation. Binary floating point has the exact same problem, just with different "awkward" fractions — `0.1` in binary is an infinitely repeating pattern, just like `1/3` is in decimal. Computers store a fixed, finite number of bits, so the value gets rounded, and that tiny rounding error is what surfaces as `0.30000000000000004`. ## 2. The Core Idea 📌 **Interview term:** JavaScript numbers use the IEEE-754 double-precision format. Only fractions expressible as a sum of powers of two are

The problem

Question presented to candidate: "If I type 0.1 + 0.2 into a JavaScript console, what do I get, and why? And how would you correctly compare two floating-point numbers for equality in real code?"

What a strong answer should cover:

📌 Interview term: IEEE-754 double-precision floating point — every JavaScript number is stored in this 64-bit binary format, which can only exactly represent certain fractional values (those expressible as a sum of powers of two). Most decimal fractions, including 0.1 and 0.2, have no exact binary representation and must be rounded to the nearest representable double.
📌 Interview term: the real answer — 0.1 + 0.2 genuinely evaluates to 0.30000000000000004, not 0.3, because both operands are already-rounded approximations, and their sum's rounding compounds the error. Verified directly via .toPrecision(20), showing the actual stored bits differ from the mathematically exact 0.3.
A precise answer names that this is not unique to JavaScript — it affects every language using IEEE-754 doubles (Python, Java, C, Go), since it is a property of the number format itself, not a JavaScript-specific bug.
📌 Interview term: Number.EPSILON — the smallest representable difference between 1 and the next larger double; the standard correct way to compare floats for "close enough" equality is Math.abs(a - b) < Number.EPSILON (or a domain-appropriate tolerance), never ===.
A precise answer names a real counter-example: 0.5 + 0.25 === 0.75 is genuinely true, because 0.5 and 0.25 are both exact powers of two — the bug only affects fractions that are not powers of two, not "all floating-point math."

Clarifying questions expected:

None — this is a definitional/technical question; precisely naming the IEEE-754 mechanism (not just "floating point is imprecise") is the strong signal.

Code / implementation expected: Optional — showing the toPrecision(20) output and the Number.EPSILON comparison fix demonstrates real understanding beyond reciting "floats are weird."

floating-point

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for JavaScript fundamentals interviews. Difficulty: Medium

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. Every number below, including the raw bit-level rounding, was actually printed by Node — not asserted from memory.

1. Why This Even Matters — A Story First

Try writing exactly one-third as a decimal: 0.333... never terminates, so any fixed number of digits is an approximation. Binary floating point has the exact same problem, just with different "awkward" fractions — 0.1 in binary is an infinitely repeating pattern, just like 1/3 is in decimal. Computers store a fixed, finite number of bits, so the value gets rounded, and that tiny rounding error is what surfaces as 0.30000000000000004.

2. The Core Idea

📌 Interview term: JavaScript numbers use the IEE

The solution is hidden so you can try first

4 min read · 8 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptReal IEEE-754 rounding proof, Number.EPSILON fix, and the power-of-two counter-example