Why Does 0.1 + 0.2 Not Equal Exactly 0.3?

Before we blame a programming language, make a smaller prediction: can any finite decimal ever equal exactly 1/3? Commit to a model first; the page will let you test it afterward.

Your system has reduced motion on, so the unlock fades are off. Nothing on this page depends on motion: every number is still computed live by your browser the moment you commit.

Interactive

First claim under judgment

Can a finite decimal equal exactly 1/3?

Can any finite decimal equal exactly 1/3?

Yes — enough digits eventually finish No — every finite candidate stops short It depends on the number of digits

The reveal

No finite base-10 decimal equals exactly 1/3. In JavaScript Number, binary64 also approximates decimal literals, so 0.1 + 0.2 evaluates to 0.30000000000000004 rather than exactly 0.3.

You locked: —

Candidate check: Waiting for a candidate · distance from 1/3: —

The denominator is the clue: a finite base-10 decimal can only reduce to factors of 2 and 5. Because 3 is left over in 1/3, the digits repeat forever.

That same representation problem appears when binary64 stores decimal literals. Your browser's live result is 0.1 + 0.2 = —.

Evidence check · now try a finite candidate

Write a finite decimal candidate

1 decimal place. Try another candidate, then check it.

You wrote 0.1—

You wrote 0.2—

You wrote 0.3—

The sum it kept—

Full stored values, 30 significant digits, produced live by toPrecision(30) a moment ago.

Why: in base 2, one-tenth is a repeating fraction — the same fate 1/3 suffers in base 10. Here are the first bits of 0.1 in binary, extracted live from the value your browser is storing:

—

The 0011 block repeats forever. A 64-bit double has room for 53 significant bits, so it stores the nearest value it can — and nearest is not equal.

A finite representation is a contract, not the number itself.

The rebuilt model

You assumed:: If I add enough decimal places, I can eventually write a decimal that is exactly one third.
The actual model:: A finite base-10 decimal has a reduced denominator made only of 2s and 5s; 1/3 therefore repeats forever. Binary64 then approximates many decimal inputs again when it stores them.
The variable that failed you:: Representation and comparison contract — decimal notation concealed both the repeating denominator and the domain's error budget.

Run it again — one variable

Keep the same approximate values. Change only the comparison contract to fit the job that will consume them.

Interactive

value A ≈ value B

The stored values stay fixed. Your contract decides what “equal enough” means.

Your selected contract is recorded as a model choice, not a score. The same stored approximation can require a different policy in a different domain.

Evidence

ECMA-262 — The Number Type
ECMAScript Number uses the IEEE 754 binary64 format.
standard — checked 2026-07-19.
David Goldberg, What Every Computer Scientist Should Know About Floating-Point Arithmetic
Representation, rounding and error behavior in floating-point arithmetic.
paper — checked 2026-07-19.

Evidence reviewed 2026-07-20. Corrections and review policy.

Try it yourself

Open your browser's console (F12 → Console) and type 0.1 + 0.2, then 0.1 + 0.2 === 0.3.
Type (0.1).toPrecision(30) — the same stored value this page showed you, straight from your own engine.
Type (2.675).toFixed(2) and watch rounding lose to representation.
Have Python, Java, or C within reach? Same literals, same answer — the approximation lives in the format, not the language.

Interactive

Playground — bring your own decimal

Type any one-decimal number from 0.0 to 9.9:

+ 0.2

The answer you meant: —

The sum your browser keeps: —

The difference: —

—

Ask with a tolerance instead: |a − b| < ε

Everything on this panel is computed live from your input; this page uses ε = 16 × Number.EPSILON. We brute-checked all 100 one-decimal inputs from 0.0 to 9.9: 27 of them fail ===, and all 100 pass within ε. The right ε depends on how much error can accumulate. The rule doesn't.

Scope: The first claim is about finite base-10 notation; the later live result applies to JavaScript Number and equivalent IEEE 754 binary64 arithmetic.

Does not prove: This does not mean floating point is unusable. A fixed epsilon is not a universal remedy; financial systems may require integer minor units or decimal arithmetic, while exact integer counts can use strict equality.

Take it with you

The portable rule: If a computed value is approximate, then choose a comparison contract that matches its domain — a bounded tolerance, decimal arithmetic, or an exact integer representation.

Graphics coordinates

Compare transformed positions with a tolerance tied to pixel or geometry error, not strict equality.

Scientific calculation

Use absolute or relative tolerance tied to measurement uncertainty and accumulated error.

Money

Represent amounts in integer minor units or a decimal type; do not hide a binary mismatch with arbitrary epsilon.

Exact integer counts

Use strict equality when both values are true integers inside the supported exact range.

Interactive

Apply it — five seconds

Checkout — amount due

$—

The total came from float math on decimal inputs. Ship this page?

Ship it — the arithmetic is correct Block it — floats can't touch money Fix the layers, then ship

0.1 + 0.2 is not exactly 0.3 in JavaScript Number.

Use as a reference

Why Does 0.1 + 0.2 Not Equal Exactly 0.3?

The reveal

The rebuilt model

Run it again — one variable

Evidence

Take it with you

Need the conclusion, boundary and sources without the challenge?

0.1 + 0.2 is not exactly 0.3 in JavaScript Number.

Use as a reference

Why Does 0.1 + 0.2 Not Equal Exactly 0.3?

Related puzzles

Need the conclusion, boundary and sources without the challenge?