How this instrument works
Computers don't store decimal numbers like 1.0 or 0.1 the way you'd write them on paper — they store a bit pattern that encodes the number's sign, magnitude and precision according to a fixed international standard: IEEE 754. This instrument converts a decimal value into its IEEE 754 single-precision ('binary32', the format behind the `float` type in C, Java, and most languages) 32-bit representation, broken into its three constituent fields.
The first field is a single sign bit: 0 for positive, 1 for negative. The next eight bits are the exponent field, storing the power-of-two scale of the number, but biased by adding 127 so the field can represent both very large and very small exponents using only unsigned bits — a stored exponent field of 127 actually means an exponent of 0. The final 23 bits are the mantissa (or fraction): the significant digits of the number after an implicit leading 1 that IEEE 754 doesn't bother storing, since every normal binary number can be written as 1.xxxx x 2^n.
This three-way split is why floating-point numbers have finite precision and why some decimal values, like 0.1, can never be represented exactly in binary — the mantissa only has 23 bits to work with, so numbers that need more binary digits than that get silently rounded to the nearest representable value. Understanding the bit layout is the first step to understanding phenomena like floating-point rounding error and why `0.1 + 0.2 != 0.3` in most programming languages.
The outputs here are strings, not ordinary numbers — the bit pattern field shows all 32 bits space-separated by section (sign, exponent, mantissa), because that's genuinely what gets stored: a specific sequence of 1s and 0s, not a further numeric quantity to do arithmetic on.
- Enter any decimal value into Decimal value — positive, negative, zero, or a fraction.
- Read IEEE 754 bit pattern for the full 32-bit encoding, shown as sign, exponent and mantissa sections separated by spaces.
- Read Sign bit separately: 0 means positive, 1 means negative.
- Read Stored exponent field to see the biased exponent (add -127 to get the true power-of-two exponent).
- Read Mantissa (fraction) bits to see the 23 stored significand bits, remembering the standard's implicit leading 1 isn't shown here because it's never stored.
Worked example — encoding 1.0 in IEEE 754 single precision
Enter 1.0 into Decimal value. IEEE 754 bit pattern reads "0 01111111 00000000000000000000000". Sign bit reads 0, since 1.0 is positive. Stored exponent field reads 127, and Mantissa (fraction) bits reads all zeros, "00000000000000000000000".
This decodes exactly as it should: sign 0 means positive, exponent field 127 minus the bias of 127 gives a true exponent of 0, and an all-zero mantissa combined with the implicit leading 1 gives a significand of exactly 1.0. Putting it together: (-1)^0 x 1.0 x 2^0 = 1.0. This is the canonical textbook example for IEEE 754 because every field lands on its simplest possible value, making the bias and implicit-bit mechanics easy to see clearly.
Questions
Why is the exponent field 'biased' by adding 127 instead of just storing a negative sign?
The 8-bit exponent field only stores unsigned values from 0 to 255, but real exponents need to range from very negative (for tiny numbers) to very positive (for huge numbers). Adding a fixed bias of 127 lets the field represent true exponents from -127 to +128 using only non-negative stored values (0 to 255) — a stored field of 127 means true exponent 0, a stored field of 200 means true exponent 73, and so on. This also makes comparing two floating-point numbers as if they were plain integers work correctly, which was a deliberate design goal of IEEE 754.
What is the implicit leading 1 in the mantissa, and why isn't it stored?
Every 'normal' (non-zero, non-special) binary floating-point number can be written in the form 1.xxxxx x 2^n — the leading digit before the binary point is always 1 for a normalized value, so IEEE 754 doesn't waste a bit storing it. Only the fractional part after that implicit 1 is stored, in the 23-bit mantissa field. This trick effectively buys 24 bits of precision from only 23 stored bits — one extra 'free' bit, sometimes called the hidden bit.
Why can't 0.1 be represented exactly in IEEE 754, and does that matter?
0.1 in binary is an infinitely repeating fraction (0.0001100110011...), similar to how 1/3 repeats forever in decimal. IEEE 754's 23-bit mantissa can only store a finite number of binary digits, so 0.1 gets rounded to the nearest representable binary32 value — extremely close to 0.1, but not exactly equal to it. This is why floating-point arithmetic can produce surprising results like 0.1 + 0.2 evaluating to something like 0.30000001192092896 rather than exactly 0.3, and why comparing floats for exact equality is generally unsafe in code.
What does the bit pattern for 0.0 look like, and why?
0.0 encodes as all zero bits: sign 0, exponent field all zeros (0), and mantissa all zeros. IEEE 754 reserves an all-zero exponent field as a special case meaning the number is zero (or, with a non-zero mantissa, a 'subnormal' number very close to zero) rather than following the normal implicit-leading-1 rule — this special case is what lets the format represent exact zero at all, since 1.0 x 2^n can never equal zero for any exponent n.
How does negating a number change its IEEE 754 bit pattern?
Negation flips only the sign bit — the exponent and mantissa fields are completely unchanged. For example, 1.0 encodes as sign 0, exponent 127, mantissa all zeros, while -1.0 encodes as sign 1 with the identical exponent (127) and mantissa (all zeros). This is a deliberate design feature of IEEE 754: negating a float is just one bit flip, with no need to touch the magnitude bits at all.