IEEE 754 Floating-Point Bit Pattern Visualizer
Break a decimal number down into its IEEE 754 single-precision (32-bit) or double-precision (64-bit) bit pattern, or decode a bit pattern back into a decimal value. Sign, exponent, and mantissa are color-coded, with support for NaN, infinity, and subnormal numbers.
The classic example: why 0.1 + 0.2 isn't 0.3
In JavaScript, `0.1 + 0.2` evaluates to `0.30000000000000004`, not `0.3`. Looking at the double-precision bit patterns explains why.
| Value | Double-precision (64-bit) hex | Double-precision (64-bit) binary |
|---|---|---|
| 0.1 | 0x3FB999999999999A | 0011111110111001100110011001100110011001100110011001100110011010 |
| 0.2 | 0x3FC999999999999A | 0011111111001001100110011001100110011001100110011001100110011010 |
| 0.3 | 0x3FD3333333333333 | 0011111111010011001100110011001100110011001100110011001100110011 |
| 0.1 + 0.2 | 0x3FD3333333333334 | 0011111111010011001100110011001100110011001100110011001100110100 |
0.1, 0.2, and 0.3 are all infinitely repeating fractions in binary, so none of them fit exactly into the 52-bit mantissa and each gets rounded. Because the rounding errors of 0.1 and 0.2 don't happen to cancel out, their sum ends up just one bit off from the exact bit pattern for 0.3 (0x3FD3333333333334). Try entering these values into the converter above and compare the trailing bits yourself.
Tips
- Convert 0.1, 0.2, and 0.3 to bits in double precision and compare them against the result of 0.1+0.2 (0.30000000000000004) — you can visually spot that only the last bit differs.
- Entering "-0" in the decimal field produces a bit pattern with only the sign bit set (different from "+0"). As numbers 0 === -0, but the bit representations are distinct.
- When the exponent field is all zero, a zero mantissa means zero, and a nonzero mantissa means a subnormal number — a special representation used to reach values extremely close to zero at the cost of precision.
- Switching between single (32-bit) and double (64-bit) precision for the same value like 0.1 shows how rounding error is larger in single precision.
- To decode a bit pattern back into a decimal value, enter either a `0x`-prefixed hex string, or a binary string with exactly as many digits as the selected precision (the `0b` prefix is optional).
Frequently Asked Questions
Side Note — How IEEE 754 became a common language
Before 1985, computer manufacturers each used their own floating-point representations. IBM, DEC, Cray, and others could compute the same value, say "0.1", and get subtly different rounding behavior and representable ranges, so porting a numerical program from one machine to another often produced slightly different results. To resolve this chaos, a working group led by William Kahan of UC Berkeley — who had also worked on the design of the Intel 8087 numeric coprocessor — drove the creation of an industry-wide standard, published in 1985 as IEEE 754.
The core idea of IEEE 754 is dividing a finite number of bits (32 or 64) into three roles — sign, exponent, and mantissa — to approximate the infinite set of real numbers. The exponent handles scale (how large or small a number is), while the mantissa handles precision (how many significant digits it has), letting a fixed number of bits flexibly cover both very small and very large magnitudes. The exponent is stored with a bias added (127 for single precision, 1023 for double) so that comparing two bit patterns as plain unsigned integers is enough to determine which value is larger, avoiding the extra complexity of a signed representation like two's complement.
Only fractions whose denominator is a power of two (1/2, 1/4, 3/8, and so on) can be represented exactly in binary. The decimal value 0.1 is the fraction 1/10, and since 10 is not a power of two, it becomes the infinitely repeating binary fraction 0.0001100110011... With only a finite number of mantissa bits available, it has to be truncated and rounded somewhere — this is the fundamental reason a computer cannot represent 0.1 exactly. It's also why accounting systems that need exact decimal arithmetic typically avoid floating-point numbers in favor of integer arithmetic or a dedicated decimal type (such as BCD).
IEEE 754 was later revised in 2008 and 2019, adding half precision (16-bit), quadruple precision (128-bit), and decimal floating-point formats, but the core three-way split of sign, exponent, and mantissa, along with its rounding modes, has remained unchanged since the original 1985 edition. Because nearly every programming language's float/double type conforms to this standard, the question "why isn't 0.1 + 0.2 equal to 0.3?" shows up in essentially the same form regardless of which language you use.