Shows the difference between what you expect from decimal maths and what floats store in binary (IEEE-754). Includes a “0.1 + 0.2” quick test and an exact-decimal comparison when possible.
Plain decimals only (no scientific notation).
You can include leading +/−.
Note: Excel and JS both use 64-bit IEEE-754 doubles, but formatting can hide/show the weirdness.
Results
Expression
—
“Looks equal to” check
—
Displayed result (JS)
—
This is what you usually see.
Stored value (full precision)
—
Shown with toPrecision(17).
Difference vs expected (when exact-decimal possible)
—
IEEE-754 (Float64) — hex
—
Sign | Exponent | Mantissa (as bytes)
IEEE-754 (Float64) — binary
—
Grouped for readability
Useful for tickets, lessons, blog posts, or “see, I told you so”.
Help other people find this (optional)
If this tool saved you time (or ended an argument), a small backlink from a blog post / resources page helps it show up in searches.
No tracking, no ads — just a quiet little site.
Tip: even one relevant link is worth more than a dozen random ones.
Because floats store numbers in binary, and many neat-looking decimals (like 0.1) cannot be represented exactly in binary. The float stores the closest binary fraction it can, and tiny errors can show up after arithmetic.
No. It’s a standard trade-off in IEEE-754 floating-point. Many languages (and Excel) use the same double-precision format, so you’ll see similar behaviour elsewhere.
For money: use integer pence/cents or a decimal library. For comparisons: compare within a tolerance (epsilon). For display: round to the number of decimals your users expect.
This tool tries to compute an exact decimal expectation using rational arithmetic when possible, which is easiest and safest with plain decimals (no scientific notation). The float side still accepts anything JS can parse, but the “exact” comparison may be disabled.