Reference path · conclusion first

Does 0.1 + 0.2 Equal 0.3?

0.1 + 0.2 is not exactly 0.3 in JavaScript Number.

Precise claimJavaScript Number uses IEEE 754 binary64. The nearest representable values make 0.1 + 0.2 evaluate to 0.30000000000000004, so strict equality with 0.3 is false.

Applies

The live result applies to binary64 arithmetic and the specific values shown. Equivalent double-precision environments exhibit the same representation issue.

Does not prove

This does not mean floating point is unusable. A fixed epsilon is not a universal remedy, and financial systems may require integer minor units or decimal arithmetic.

Portable rule

If you compare computed decimals, then choose a domain-sized tolerance — or use an exact representation.

Test yourself first Jump to evidence ↓

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

Use as a reference

Declare the discussion context, then copy a stable link. No account or personal data is attached.

Does 0.1 + 0.2 Equal 0.3?

Not on paper — in your browser's JavaScript engine, which runs the same IEEE 754 arithmetic as nearly every language you will ever ship. True or false?

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

The expression under judgment

0.1 + 0.2 === 0.3

No lookup table, no tape delay: after you commit, your browser's own engine evaluates this exact expression, live, on this page.

In JavaScript, is it true or false?

True False

The reveal

JavaScript Number uses IEEE 754 binary64. The nearest representable values make 0.1 + 0.2 evaluate to 0.30000000000000004, so strict equality with 0.3 is false.

You answered: —

Your browser just evaluated it — a millisecond ago, right here on this page: 0.1 + 0.2 === 0.3 → —

What your browser actually added: 0.1 + 0.2 = —. Not a display artifact: that is the shortest decimal that names the resulting double — parse it and you get the same bits back.

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.

0.1 was never 0.1.

The rebuilt model

You assumed:: Computer arithmetic is ordinary decimal arithmetic, so 0.1 + 0.2 must strictly equal 0.3.
The actual model:: Most simple decimal fractions have no finite binary representation, so the machine stores nearby binary values and arithmetic operates on those values.
The variable that failed you:: Representation — decimal notation concealed binary approximation.

Run it again — one variable

Same literals, same stored values, same sum. The only thing that changes is the question you ask of it.

Interactive

0.1 + 0.2 === 0.3

Answered live, again: —

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 live result applies to binary64 arithmetic and the specific values shown. Equivalent double-precision environments exhibit the same representation issue.

Does not prove: This does not mean floating point is unusable. A fixed epsilon is not a universal remedy, and financial systems may require integer minor units or decimal arithmetic.

Take it with you

The portable rule: If you compare computed decimals, then choose a domain-sized tolerance — or use an exact representation.

Frontend tests

Do not assert strict equality for geometry or animation values produced by floating-point calculations.

Payments

Represent money in integer minor units or a suitable decimal type.

Data pipelines

Define numeric tolerances from the measurement and accumulated error, not from habit.

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

Take it into the discussion

Need the conclusion, boundary and sources without the challenge?

Open the same page in its conclusion-first reading state, then declare the work context before copying a stable reference.

Use as a reference →

0.1 + 0.2 is not exactly 0.3 in JavaScript Number.

Use as a reference

Does 0.1 + 0.2 Equal 0.3?

Related puzzles

Need the conclusion, boundary and sources without the challenge?