Why 0.1 + 0.2 Is Not 0.3: Floating Point Explained

The sum, with all its digits

Every number on this page is computed by the page itself, in the same 64-bit arithmetic it describes.

The two 20-digit lines are the point. The stored value of 0.3 is a little below 0.3, and the sum of the stored 0.1 and 0.2 is a little above it. They are two different 64-bit values, one step apart, so the comparison is false. The 17-digit printout is simply the shortest string that identifies the stored sum; it is not an error that appeared out of nowhere, it was there in the inputs.

What the 64 bits hold

A JavaScript number is a double-precision 64-bit IEEE 754 value, the same type as a double in Java or C. MDN gives the layout: 1 bit for the sign, 11 bits for the exponent and 52 bits for the fraction, also called the mantissa or significand.

Fifty-three binary digits are worth about 15 to 17 decimal digits. The gap between 1 and the next representable number is 2⁻⁵², available as Number.EPSILON, which is 2.220446049250313e-16. The 64 bits can hold huge values, up to 1.80 × 10³⁰⁸ (Number.MAX_VALUE) before the result becomes Infinity, but never more than 53 bits of precision at any size. The number base converter shows any number in binary, including the fraction part, which is where the trouble with 0.1 starts.

Why 0.1 cannot be stored

A fraction has a finite expansion in a base only if its denominator divides a power of that base. In decimal, 1/4 is 0.25 and 1/8 is 0.125, but 1/3 is 0.333… forever, because 3 does not divide any power of 10. In binary the only finite fractions are the ones with a power of two underneath: 1/2, 1/4, 3/8. One tenth is 1/10, and 10 has the factor 5, so in binary it repeats forever:

0.1 = 0.000110011001100110011001… (the block 0011 repeats)

The 53 digits that fit are kept, the rest is rounded, and the number that is actually stored is, written out in full:

0.1000000000000000055511151231257827021181583404541015625

Python's documentation gives the same value as a fraction, 3602879701896397 / 2⁵⁵, and spells out the rule: most decimal fractions cannot be represented exactly as binary fractions, just as 1/3 cannot in decimal. The table shows which short decimals are exact and what the others really hold.

0.5 and 0.25 are exact because they are 1/2 and 1/4. Everything else in the table is a rounded neighbor, some just below the decimal you typed, some just above. The direction matters later, when you round.

Why you usually do not see it

Languages print the shortest decimal that reads back to the same stored value. For 0.1 that string is simply 0.1, so the error stays hidden. It surfaces when an operation moves the result to a different stored value than the one the short string would pick: 0.1 + 0.2 lands one step above the stored 0.3, so the shortest string for it needs 17 digits. Multiplying a price by 100 does the same thing:

5 of the 5 products are not whole numbers, and the last row is the dangerous one: the stored 1.005 is already below 1.005, so 1.005 × 100 gives 100.49999999999999 and even Math.round returns 100 cents, not 101. Rounding repairs the first four, where the error came from the multiplication. For the fifth it was in the typed number before any arithmetic, which is why the money rule below says to turn the typed amount into cents directly instead of multiplying a float.

Safe integers

Integers are exact as long as they fit in the 53 bits of precision. MDN states the range: from −(2⁵³ − 1) to 2⁵³ − 1, which is 9,007,199,254,740,991, available as Number.MAX_SAFE_INTEGER. Safe means the integer is represented exactly and compares correctly. Beyond it, the gaps between representable numbers grow to 2, then 4, then 8, so some integers simply do not exist:

This is why 64-bit IDs from databases and APIs must travel as strings in JSON, not as numbers: a 19-digit ID parsed into a JavaScript number is silently rounded to a neighbor and the lookup fails. JavaScript's BigInt type holds integers of any size exactly, at the cost of not mixing with ordinary numbers.

How to compare

MDN's advice is short: floating point numbers should never be compared with ===. Four ways that work, from quickest to most exact.

• A tolerance. Treat two numbers as equal when their difference is smaller than a threshold. Math.abs(a − b) < Number.EPSILON is true for 0.1 + 0.2 against 0.3 (true), but EPSILON only fits values around 1; MDN's example scales it, 2000 × EPSILON for values around 2000. Python's math.isclose() does the scaling for you.
• Round first, then compare. If the numbers mean dollars or percentages, round both to the digits that matter and compare the rounded values. The rounding calculator shows what each rounding rule does to a tie like 2.5 or 2.675.
• Integers. Keep money in whole cents, quantities in the smallest unit, and the comparison becomes exact integer arithmetic up to 2⁵³. Convert to dollars only for display.
• A decimal type. Python's decimal module does decimal arithmetic suitable for accounting, and its fractions module stores 1/3 exactly. JavaScript has no built-in equivalent, but several libraries do the same job in base 10.

For sums of many values, Python's documentation also points to math.fsum(), which tracks the lost digits across the whole sum and rounds once at the end.

How rounding tools decide

Rounding a float with the language's own function rounds the stored value, not the number you typed. The stored 1.005 is 1.00499999999999989342, below the halfway point, so (1.005).toFixed(2) returns 1.00. Python's round(2.675, 2) gives 2.67 for the same reason, and its documentation uses that very example. Nothing is wrong with the rounding rule; the input was already a hair short.

Our calculators avoid this by never turning your number into binary. The rounding calculator keeps the digits you typed as text and rounds them with exact whole-number arithmetic, so 1.005 to two places is 1.01 and 2.675 is 2.68, under every tie rule it offers. The significant figures calculator and the scientific notation converter work the same way: the digits are moved and counted as text, so a trailing zero you typed on purpose survives, 1e-500 converts without becoming 0, and a 30-digit number keeps all 30 digits instead of the 15 to 17 a double can hold. If you need to reproduce a program's result rather than the correct decimal one, round the stored value shown in the tables above instead.

Rules of thumb

1. Expect any decimal with a 5 in its denominator to be stored slightly off. 0.5, 0.25 and whole numbers are exact.
2. Never compare floats with ===. Use a scaled tolerance, round first, or work in integers.
3. Money goes in cents, as integers. Parse the typed amount into cents; when you must multiply a float by 100, round the result, never truncate.
4. Integers above 9,007,199,254,740,991 need a string or BigInt.
5. Round for display at the last step, once, and show 15 significant digits at most.

Frequently asked questions

Sources

• MDN Web Docs: Number (a double-precision 64-bit IEEE 754 value; 1 sign bit, 11 exponent bits, 52 mantissa bits; precision 2 to the minus 52, about 15 to 17 significant decimal digits; integers exact from minus 2 to the 53 plus 1 to 2 to the 53 minus 1; MAX_VALUE and Infinity)
• MDN Web Docs: Number.EPSILON (2 to the minus 52, about 2.22e-16, the gap between 1 and the next double; a reasonable threshold around magnitude 1 only, scale it for larger values, never compare floats with ===)
• MDN Web Docs: Number.MAX_SAFE_INTEGER (9007199254740991; safe means represented exactly and compared correctly; MAX_SAFE_INTEGER + 1 === MAX_SAFE_INTEGER + 2 is true)
• Python documentation: Floating-Point Arithmetic, Issues and Limitations (most decimal fractions have no exact binary form, like 1/3 in decimal; 0.1 is stored as 3602879701896397 / 2**55, exactly 0.1000000000000000055511151231257827021181583404541015625; 0.1 + 0.1 + 0.1 != 0.3; math.isclose, math.fsum, the decimal and fractions modules)
• Python documentation: built-in functions, round() (round(2.675, 2) gives 2.67 instead of the expected 2.68 because most decimal fractions cannot be represented exactly as a float; ties go to the even choice)

Written by Tobias. Updated October 24, 2026.