Index / Developer
IEEE 754 Float Inspector
A float does not hold the number you typed. It holds the nearest one it can, and that number has an exact decimal expansion which terminates. This prints it — all of it — along with the bits, the two neighbouring values and the exact difference between what you asked for and what was stored.
Value
A decimal, or bits in hex when the box below says
so.
inf, -inf and nan are
understood.
Exponent bits + fraction bits. Every format here
has one implied leading bit on top of the fraction.
binary64, normal
0.1
Hex
—
Decimal digits
—
The exact value stored
What you asked for, and what you got
The bits
Either side of it
the two nearest representable valuesThe same number in the other three formats
rounded from the decimal you typed, not from each other
Why the digits terminate, and how the rounding is decided
Every finite float is an integer times a power of two. That makes
it a dyadic rational, and every dyadic rational has a decimal expansion
that stops: multiply top and bottom by the right power of five and the
denominator becomes a power of ten. So the exact value of a float is
never a recurring decimal and never needs an approximation. 0.1 stored
as a binary64 is exactly
0.1000000000000000055511151231257827021181583404541015625, and that is
the whole number, not the first fifty-five digits of it.
The longest one here is 1,074 places. The smallest binary64 subnormal is 2−1074, so its exact decimal has 1,074 digits after the point. Printing it is the point of the page — rule nine of this site says never to fall back on scientific notation — so it is printed, and the digit count is stated next to it.
The rounding is decided exactly, not by rounding twice. Reading a decimal into a binary32 by going through a binary64 first is wrong in rare cases: the decimal can sit just the wrong side of a halfway point that the intermediate rounding has already moved. This page takes the candidate the double gives, looks at its two neighbours in the target format, and compares all three against the decimal you typed using exact integer arithmetic on digit strings. Ties go to the even fraction, which is what IEEE 754 requires. Where that disagrees with the double-rounded answer, this says so rather than quietly being right.
The gap is not the same on both sides. At a power of two the spacing below is half the spacing above, because the exponent changes there. Both gaps are printed, exactly, and they differ for every value whose fraction bits are all zero.
The shortest literal is the engine's own. JavaScript is required to print the shortest decimal that reads back as the same double, so that row is not this page's arithmetic and is worth having next to the exact value: the short one is what round-trips, the long one is what is stored, and they are different facts.
bfloat16 is not a shortened binary16. It has binary32's eight exponent bits with only seven fraction bits, so it reaches the same magnitudes as a float with about two and a half decimal digits of precision. That is why it is used where binary16 overflows.
NaN loses its payload here, and that is JavaScript's doing. A binary64 NaN has 252 − 1 distinct bit patterns, and the difference between a quiet and a signalling one lives in them. A value in this page passes through a JavaScript number, and the language is allowed to replace any NaN with a canonical one — engines do. So a NaN typed in as bits comes back as the canonical quiet NaN, not the pattern you gave. This is stated rather than hidden, because a tool that silently changed those bits would be worse than one that refused.
Nothing is sent anywhere. The whole conversion is integer arithmetic on digit arrays, done in this tab.
The longest one here is 1,074 places. The smallest binary64 subnormal is 2−1074, so its exact decimal has 1,074 digits after the point. Printing it is the point of the page — rule nine of this site says never to fall back on scientific notation — so it is printed, and the digit count is stated next to it.
The rounding is decided exactly, not by rounding twice. Reading a decimal into a binary32 by going through a binary64 first is wrong in rare cases: the decimal can sit just the wrong side of a halfway point that the intermediate rounding has already moved. This page takes the candidate the double gives, looks at its two neighbours in the target format, and compares all three against the decimal you typed using exact integer arithmetic on digit strings. Ties go to the even fraction, which is what IEEE 754 requires. Where that disagrees with the double-rounded answer, this says so rather than quietly being right.
The gap is not the same on both sides. At a power of two the spacing below is half the spacing above, because the exponent changes there. Both gaps are printed, exactly, and they differ for every value whose fraction bits are all zero.
The shortest literal is the engine's own. JavaScript is required to print the shortest decimal that reads back as the same double, so that row is not this page's arithmetic and is worth having next to the exact value: the short one is what round-trips, the long one is what is stored, and they are different facts.
bfloat16 is not a shortened binary16. It has binary32's eight exponent bits with only seven fraction bits, so it reaches the same magnitudes as a float with about two and a half decimal digits of precision. That is why it is used where binary16 overflows.
NaN loses its payload here, and that is JavaScript's doing. A binary64 NaN has 252 − 1 distinct bit patterns, and the difference between a quiet and a signalling one lives in them. A value in this page passes through a JavaScript number, and the language is allowed to replace any NaN with a canonical one — engines do. So a NaN typed in as bits comes back as the canonical quiet NaN, not the pattern you gave. This is stated rather than hidden, because a tool that silently changed those bits would be worse than one that refused.
Nothing is sent anywhere. The whole conversion is integer arithmetic on digit arrays, done in this tab.