Open your browser’s console, type 0.1 + 0.2 and press enter. You won’t see 0.3 but 0.30000000000000004. It’s not a bug in JavaScript, nor in your browser, nor in the computer in front of you. It’s the inevitable consequence of how a machine that only understands ones and zeros represents decimal numbers.
A system that only knows integers
Your processor works in binary. The CPU, the central unit that runs your programs, stores every piece of data as a string of bits, the zeros and ones that are the physical currency of all computing. In that language, whole numbers are expressed without trouble: 3 is 11, 10 is 1010. The problem arrives when you try to write fractions.
In decimal, 0.1 is a clean figure because 10 is divisible by 2 and 5, and 0.1 is exactly one tenth. But binary only has the factor 2. Any fraction whose denominator is not a power of two needs infinitely many digits to be represented exactly. And 0.1, in binary, is a repeating decimal that never ends: 0.0001100110011... going on forever, just as 1/3 in decimal repeats as 0.3333.
The standard that standardizes everything: IEEE 754
Because no machine can store infinitely many digits, decades ago the industry agreed on a common format for numbers with decimals, the IEEE 754 standard. It is the same one used by almost every modern language and processor for the data type known as floating point.
A floating-point number splits into three parts: a sign bit (positive or negative), a mantissa (the significant digits) and an exponent (which shifts the decimal point left or right). It is an idea close to scientific notation: 1.5 × 10³ keeps the essentials and lets the exponent place the point. In double precision (64 bits), the most common version in software, 52 bits are reserved for the mantissa, 11 for the exponent and 1 for the sign.
The rounding that accumulates
With only 52 bits of precision, 0.1 and 0.2 are not stored exactly, but as the closest approximation that fits in that space. When you add the two approximations, the error does not cancel out: it combines, which is why the result drifts from exact 0.3 by a tiny margin that appears on screen as 0.30000000000000004. The difference is on the order of a billionth, negligible for almost everyone… until it isn’t.
Rounding, the operation that adjusts a result so it fits into the available bits, is the door through which errors enter. Every operation can introduce a small deviation, and when a calculation chains thousands of steps —a simulation, a machine-learning model or a video game engine— the errors accumulate and can grow until they become visible.
When a billionth really matters
There are fields where this error is not a curiosity but a risk. In financial applications, adding and subtracting cents with floating point can produce mismatches of a few cents that, multiplied by millions of transactions, become real amounts. That is why money is almost always handled as whole numbers of cents, or with decimal types of exact precision.
Also in science: an orbit simulated over years, or a reconstructed medical image, depends on errors not getting out of hand. Developers use strategies such as comparing numbers with a tolerance margin instead of demanding exact equality, or ordering operations to minimize the loss of precision.
A trade-off, not a flaw
Floating point is not a design error but a smart compromise. Compared with exact arithmetic, which demands variable memory and computation time depending on each number, IEEE 754 offers fixed precision and extremely fast operations, ideal for the performance that modern software demands.
The next time you see a 0.30000000000000004 in your console, don’t think the machine is wrong: think that it is showing you, in the most honest way possible, that the finite world of bits cannot contain the infinite subtlety of decimal numbers.
