Open any browser's JavaScript console and type 0.1 + 0.2 — instead of 0.3, you get 0.30000000000000004. It's not a bug in the browser or in JavaScript specifically; it's a direct consequence of how the IEEE 754 standard represents fractional numbers in binary, and the exact same result shows up in Python, Java, C#, and nearly every other language built on that standard.
The three parts of a floating-point number
An IEEE 754 number is stored as three components: a sign (positive or negative), a mantissa (the number's significant digits), and an exponent (the power the decimal point is shifted by). It's similar to scientific notation: 1.5 × 10², just in binary.
Why 0.1 can't be represented exactly in binary
0.1 in decimal is an infinitely repeating fraction in binary (similar to how 1/3 repeats infinitely in decimal). A computer only stores a limited number of mantissa bits, so the number gets rounded to the nearest representable value — and that rounding is exactly what produces the visible "error."
Where this actually bites: shopping carts and invoices
A checkout page that sums line-item prices as plain floats can drift a cent or two off the expected total after enough items — each addition rounds slightly, and the errors accumulate instead of canceling out. That's why payment systems typically work in integer cents, or use a dedicated decimal type, rather than adding raw floats together.
Why you'd need this
- Understanding and diagnosing unexpected rounding errors in financial or scientific calculations.
- Seeing the exact binary representation of a specific floating-point number.
- Explaining to a colleague or student why comparing fractional numbers for exact equality is a bad practice.
Subnormal Numbers Near Zero
When a value is too small for normal representation (a significand with a digit that starts with an implicit leading one), IEEE 754 switches into subnormal (denormalized) mode, where that implicit leading one is dropped — this allows representing even smaller magnitudes at the cost of gradually losing precision instead of jumping abruptly to zero. This "smooth" approach to zero is preferable to an abrupt underflow, but subnormal computations are noticeably slower than normal ones on some processors.