IEEE754 Floating Point Converter
Translations: deThis page allows you to convert between the decimal representation of numbers (like "1.02") and the binary format used by all modern CPUs (IEEE 754 floating point).
Update
There has been an update in the way the number is displayed. Previous version would give you the represented value as a possibly rounded decimal number and the same number with the increased precision of a 64bit double precision float. Now the original number is shown (either as the number that was entered, or as a possibly rounded decimal string) as well as the actual full precision decimal number that the float value is representing. Entering "0.1" is  as always  a nice example to see this behaviour. The difference between both values is shown as well, so you can easier tell the difference between what you entered and what you get in IEEE754.
This webpage is a tool to understand IEEE754 floating point numbers. This is the format in which almost all CPUs represent noninteger numbers. As this format is using base2, there can be surprising differences in what numbers can be represented easily in decimal and which numbers can be represented in IEEE754. As an example, try "0.1". The conversion is limited to 32bit single precision numbers, while the IEEE754Standard contains formats with increased precision.

Usage:
You can either convert a number by choosing its binary representation in the buttonbar, the other fields will be updated immediately. Or you can enter a binary number, a hexnumber or the decimal representation into the corresponding textfield and press return to update the other fields. To make it easier to spot eventual rounding errors, the selected float number is displayed after conversion to double precision.

Special Values:
You can enter the words "Infinity", "Infinity" or "NaN" to get the corresponding special values for IEEE754. Please note there are two kinds of zero: +0 and 0.

Conversion:
The value of a IEEE754 number is computed as:
sign ** 2<sup>exponent</sup> ** mantissa
The sign is stored in bit 32. The exponent can be computed from bits 2431 by subtracting 127. The mantissa (also known as significand or fraction) is stored in bits 123. An invisible leading bit (i.e. it is not actually stored) with value 1.0 is placed in front, then bit 23 has a value of 1/2, bit 22 has value 1/4 etc. As a result, the mantissa has a value between 1.0 and 2. If the exponent reaches 127 (binary 00000000), the leading 1 is no longer used to enable gradual underflow.

Underflow:
If the exponent has minimum value (all zero), special rules for denormalized values are followed. The exponent value is set to 2^{126} and the "invisible" leading bit for the mantissa is no longer used.
The range of the mantissa is now [0:1).
Note: The converter used to show denormalized exponents as 2^{127} and a denormalized mantissa range [0:2). This is effectively identical to the values above, with a factor of two shifted between exponent and mantissa. However this confused people and was therefore changed (20150926).

Rounding errors:
Not every decimal number can be expressed exactly as a floating point number. This can be seen when entering "0.1" and examining its binary representation which is either slightly smaller or larger, depending on the last bit.

Other representations:
The hex representation is just the integer value of the bitstring printed as hex. Don't confuse this with true hexadecimal floating point values in the style of 0xab.12ef.

FAQ (Frequently Asked Questions):

Can you send me the source code? I need to convert format x to format y.:
This source code for this converter doesn't contain any low level conversion routines. The conversion between a floating point number (i.e. a 32 bit area in memory) and the bit representation isn't actually a conversion, but just a reinterpretation of the same data in memory. This can be easily done with typecasts in C/C++ or with some bitfiddling via java.lang.Float.floatToIntBits in Java. The conversion between a string containing the textual form of a floating point number (e.g. "3.14159", a string of 7 characters) and a 32 bit floating point number is also performed by library routines. If you need to write such a routine yourself, you should have a look at the sourecode of a standard C library (e.g. GNU libc, uclibc or the FreeBSD C library  please have a look at the licenses before copying the code)  be aware, these conversions can be complicated.

I've converted a number to floating point by hand/some other method, and I get a different result. Your converter is wrong!
Possibly, but unlikely. The conversion routines are pretty accurate (see above). Until now, checking the results always proved the other conversion less accurate. In particular toggling the last bit can lead to the same result after rounding to a fixed number of decimal places. Please check the double precision result (bottom line in the converter) and compare the difference to the expected decimal result while toggling the last bit.

Note: If you find any problems, please report them here.