IEEE-754 Float Visualizer
See exactly how a decimal number is stored as an IEEE-754 float — sign bit, exponent bits and mantissa bits — and why numbers like 0.1 aren't stored exactly.
Result
Every floating-point number a computer stores — a JavaScript number, a C float, a Python float — is encoded the same way under IEEE 754: one sign bit, a block of exponent bits, and a block of mantissa (fraction) bits. Single precision (32-bit) uses 1 sign bit, 8 exponent bits and 23 mantissa bits; double precision (64-bit), the format behind almost every language's default number type, uses 1 sign bit, 11 exponent bits and 52 mantissa bits. This tool takes any decimal number you type, encodes it in either width using the browser's own DataView/ArrayBuffer float encoder — the same machinery your code actually runs on — and colors each bit by which region it belongs to.
The encoding itself follows three steps, and this tool walks through all of them instead of just showing the final bits. First, normalization: the number is rewritten as 1.mantissa × 2^exponent, with exactly one nonzero digit before the binary point (numbers too small for that get the subnormal treatment instead, with no implicit leading 1). Second, exponent bias: since the exponent field must store both positive and negative exponents as an unsigned number, a fixed bias (127 for single precision, 1023 for double) is added before the field is written out in binary. Third, the fractional mantissa is expanded bit by bit with the classic “multiply by two, take the integer part as the next bit, keep the remainder” method — repeated until the mantissa field is full, at which point the leftover bits decide whether the result rounds up or down (round-half-to-even, the IEEE-754 default).
This is exactly why a number as ordinary as 0.1 isn't stored exactly. In binary, 0.1 is a repeating fraction (0.0001100110011…, forever), so no finite mantissa can hold it precisely — it has to be rounded off somewhere. Encode 0.1 as a 32-bit float and read the bits back, and you don't get 0.1 back: you get exactly 0.100000001490116119384765625. Double precision has 29 more mantissa bits to work with, so its rounding error is far smaller, but it is not zero either — 0.1 as a 64-bit double is exactly 0.1000000000000000055511151231257827021181583404541015625. This tool computes that exact stored value with big-integer arithmetic (no floating-point shortcuts) so the gap between what you typed and what the hardware actually keeps is never hidden or approximated.
Special values get exact, reserved bit patterns rather than a normal encoding: zero and negative zero have all-zero exponent and mantissa bits (only the sign bit differs), ±Infinity has all-one exponent bits with an all-zero mantissa, and NaN has all-one exponent bits with at least one mantissa bit set. Everything here runs locally in your browser — nothing you type is uploaded anywhere — which makes this a safe place to build real intuition for floating-point bugs: why `0.1 + 0.2 !== 0.3` in almost every programming language, why float32 textures in graphics code lose precision that float64 wouldn't, and why financial code should generally avoid binary floating point altogether.