Float Inspector (IEEE 754)
Inspect IEEE 754 floating-point numbers: sign, exponent, mantissa bits, exact decimal value, next/previous float. Single (32-bit) and double (64-bit) precision.
IEEE 754 bit layout
A floating-point number is stored as three fields: a sign bit, an exponent (biased), and a significand (mantissa) with an implicit leading bit for normal numbers.
Special cases: all-zero exponent + all-zero mantissa = ±0; all-ones exponent + all-zero mantissa = ±∞; all-ones exponent + non-zero mantissa = NaN.
About this tool
Computers store decimal numbers in IEEE 754 floating-point format, which cannot represent most real numbers exactly. 0.1 + 0.2 does not equal 0.3 because 0.1 is stored as a nearby binary fraction. This tool shows you exactly what your number becomes when a program reads it as a float (32-bit) or double (64-bit): the sign, exponent, and mantissa bits, the precise decimal value stored, and the next and previous representable numbers.
For example, the literal 0.1 is stored in double precision as the exact fraction 3602879701896397 / 2^55 = 0.1000000000000000055511151231257827021181583404541015625. The neighboring floats are 0.099999999999999991673327315311325594622582912445068359375 and 0.100000000000000019428902930940239457513523101806640625. Knowing these neighbors is how you reason about epsilon, rounding error, and equality tests.
Use this when debugging 0.1 + 0.2 !== 0.3, porting fixed-point code, understanding Math.fround, picking an epsilon for collision detection, or learning how subnormals, infinities, and NaN are actually laid out in memory.
FAQ
Why does 0.1 + 0.2 not equal 0.3? ›
Because 0.1 and 0.2 cannot be represented exactly in binary floating point — they are stored as the nearest double, which is a tiny amount larger. When added, the rounding errors accumulate and the result (0.30000000000000004) differs from the stored value of 0.3 by one ULP. This is true in every IEEE 754 language: JavaScript, Python, C, Java, Rust — all of them.
What is the difference between Float32 and Float64? ›
Float64 (double) has 52 mantissa bits — about 15-17 significant decimal digits. Float32 (single) has only 23 mantissa bits — about 7 decimal digits. Float32 also has a smaller exponent range (about ±10^38 vs ±10^308 for double). GPUs and many ML frameworks default to Float32 for speed; JavaScript Number and most languages default to Float64.
What is a subnormal (denormal) number? ›
When the exponent field is all zeros but the mantissa is non-zero, the number is subnormal. These fill the gap between zero and the smallest normal number, gradually losing precision as they approach zero. They let you represent very tiny values (down to about 5e-324 for double) at the cost of slower arithmetic on some CPUs.
What is ULP and why do the neighboring floats matter? ›
ULP (unit in the last place) is the gap between two consecutive representable floats at a given magnitude. It grows as numbers get larger — near 1.0 the ULP for double is about 2.2e-16, but near 1e16 it is 2. The previous and next floats shown here let you see exactly how coarse the representable grid is at the magnitude of your number, which tells you when an equality comparison is safe and when a calculation will round to the same value.
Why is the "exact decimal" string so long? ›
Because that is the precise decimal expansion of the binary fraction actually stored in memory. Most languages only print a short round-trippable approximation (0.1 instead of 0.1000000000000000055…), but the full expansion is what you would get if you converted the bits to a decimal exactly. It is the ground truth for reasoning about accumulated rounding error.
Can I also convert between integer bases (binary, hex, octal)? ›
Yes — use the <a href="/number-base">Number Base Converter</a> for integer base conversions (binary ↔ octal ↔ decimal ↔ hexadecimal) with arbitrary BigInt precision. This tool focuses on IEEE 754 floating-point representation; the base converter handles the integer side.