IEEE 754 Converter — Float to Binary Bits (32/64-bit)

Convert between decimal numbers and IEEE 754 bit patterns (32-bit single or 64-bit double precision) instantly, in both directions. Color-coded sign, exponent, and mantissa make NaN, infinity, and subnormal values easy to spot.

Last updated: 2026-09-03

The classic example: why 0.1 + 0.2 isn't 0.3

In JavaScript, `0.1 + 0.2` evaluates to `0.30000000000000004`, not `0.3`. Looking at the double-precision bit patterns explains why.

Value	Double-precision (64-bit) hex	Double-precision (64-bit) binary
0.1	0x3FB999999999999A	0011111110111001100110011001100110011001100110011001100110011010
0.2	0x3FC999999999999A	0011111111001001100110011001100110011001100110011001100110011010
0.3	0x3FD3333333333333	0011111111010011001100110011001100110011001100110011001100110011
0.1 + 0.2	0x3FD3333333333334	0011111111010011001100110011001100110011001100110011001100110100

0.1, 0.2, and 0.3 are all infinitely repeating fractions in binary, so none of them fit exactly into the 52-bit mantissa and each gets rounded. Because the rounding errors of 0.1 and 0.2 don't happen to cancel out, their sum ends up just one bit off from the exact bit pattern for 0.3 (0x3FD3333333333334). Try entering these values into the converter above and compare the trailing bits yourself.

What is IEEE 754? Seeing floating-point numbers as bits

When a computer stores a decimal number, it doesn't keep the digits you typed — it packs the value into a fixed number of bits following the IEEE 754 standard, splitting them into a sign, an exponent, and a mantissa. This tool lets you see exactly which bits are stored for any value you enter, in both single precision (32-bit) and double precision (64-bit), and lets you go the other way too: paste a raw hex or binary pattern and see what decimal value it decodes to.

Most day-to-day programming never requires thinking about this layer, yet it's the reason `0.1 + 0.2` doesn't equal `0.3`, why very large integers lose precision once stored as floats, and why NaN and infinity behave the way they do in comparisons. Seeing the sign bit, exponent, and mantissa laid out for a real value turns those abstract rules into something you can point at.

How to use this tool

Pick a direction and a precision Choose "Decimal → Bit pattern" or "Bit pattern → Decimal", then select single (32-bit) or double (64-bit) precision.
Enter a value For decimal input, type any number or "NaN"/"Infinity"/"-Infinity". For bit input, use a `0x`-prefixed hex string or a binary string matching the selected precision's digit count.
Read the sign, exponent, and mantissa breakdown The color-coded bit string and a detail table show the raw exponent, the exponent after removing the bias, and the full hex representation.
Check the classification badge The tool automatically labels the result as zero, subnormal, normal, infinity, or NaN, along with a short explanation of what that classification means.
Try the presets and edge cases Use the 0.1/0.2/0.3, ±0, ±Infinity, and NaN preset buttons, or try negative values and extremely large or small numbers to see how they encode.

Tips for getting more out of it

Convert 0.1, 0.2, and 0.3 to bits in double precision and compare them against the result of 0.1+0.2 (0.30000000000000004) — you can visually spot that only the last bit differs.
Entering "-0" in the decimal field produces a bit pattern with only the sign bit set (different from "+0"). As numbers 0 === -0, but the bit representations are distinct.
When the exponent field is all zero, a zero mantissa means zero, and a nonzero mantissa means a subnormal number — a special representation used to reach values extremely close to zero at the cost of precision.
Switching between single (32-bit) and double (64-bit) precision for the same value like 0.1 shows how rounding error is larger in single precision.
To decode a bit pattern back into a decimal value, enter either a `0x`-prefixed hex string, or a binary string with exactly as many digits as the selected precision (the `0b` prefix is optional).

Where this tool helps

Computer science coursework

Textbooks describe floating-point layout in the abstract; this tool lets you confirm it against real numbers while studying or preparing a lab report.

Debugging numerical precision bugs

Narrow down "why is this one calculation slightly off" by entering the suspect value and inspecting its exact bit pattern, no code required.

Embedded and low-level programming

Decode a hex float value seen in a memory dump or register back into a readable decimal number.

Technical interview preparation

Practice answering questions like "how do single and double precision differ at the bit level" using a concrete example instead of memorized facts.

Explaining "0.1 + 0.2 ≠ 0.3" to someone

Show the actual bit patterns side by side instead of just asserting that floating-point rounding is the cause.

Glossary

IEEE 754: The international standard defining how computers represent floating-point numbers. Published in 1985, it's followed by the float/double type in nearly every programming language.
Sign bit: The single bit indicating whether a value is positive (0) or negative (1). It's independent of the exponent and mantissa, which is why "+0" and "-0" exist as distinct bit patterns.
Exponent: The bits that encode the scale (magnitude) of the value — 8 bits in single precision, 11 in double — stored with a bias added.
Mantissa (significand): The bits that encode the significant digits of the value — 23 bits in single precision, 52 in double — normally interpreted with an implicit leading 1.
Bias: A fixed offset (127 for single precision, 1023 for double) added to the exponent so it can be stored and compared as a plain unsigned integer.
Subnormal number: A bit pattern with an all-zero exponent and a nonzero mantissa. Dropping the implicit leading 1 lets it represent values closer to zero than a normal number can, at the cost of precision.
NaN (Not a Number): A bit pattern with an all-one exponent and a nonzero mantissa, produced by undefined operations such as 0/0 or ∞-∞.
Infinity: A bit pattern with an all-one exponent and an all-zero mantissa, typically produced when a calculation overflows the representable range.

Frequently Asked Questions

0.1, 0.2, and 0.3 are all infinitely repeating fractions in binary, so a computer has to round each of them to fit the finite mantissa (52 bits in double precision). Because the rounding errors for 0.1 and 0.2 don't happen to cancel each other out, their sum ends up slightly different from the exact bit pattern for 0.3 (0.30000000000000004). This isn't a bug in any particular language — it happens in every IEEE 754-compliant language.

Single precision (float, 32-bit) uses 1 sign bit, 8 exponent bits, and 23 mantissa bits. Double precision (double, 64-bit) uses 1 sign bit, 11 exponent bits, and 52 mantissa bits. More mantissa bits give more significant digits (precision), and more exponent bits give a wider representable range. Most programming languages default to double precision for their floating-point type.

It's a bit pattern where the exponent field is all zero but the mantissa is nonzero. A normal floating-point number has an implicit leading 1 in its mantissa, but a subnormal number omits it and instead fixes the exponent at its minimum value, letting the format represent values even closer to zero than the smallest normal number can — at the cost of some precision.

IEEE 754 has an independent sign bit, so even when the exponent and mantissa are both all zero, a sign bit of 0 gives "+0" and a sign bit of 1 gives "-0" — two distinct bit patterns. Numerically, 0 === -0 is true, but some operations reveal the difference, such as 1/0 producing +Infinity while 1/-0 produces -Infinity.

Both use a bit pattern where the exponent field is all one. If the mantissa is all zero, it represents infinity (with the sign bit distinguishing +Infinity from -Infinity); if the mantissa is nonzero, it represents NaN (Not a Number). These arise from mathematically undefined operations such as division by zero or ∞ - ∞.

Side Note — How IEEE 754 became a common language

Before 1985, computer manufacturers each used their own floating-point representations. IBM, DEC, Cray, and others could compute the same value, say "0.1", and get subtly different rounding behavior and representable ranges, so porting a numerical program from one machine to another often produced slightly different results. To resolve this chaos, a working group led by William Kahan of UC Berkeley — who had also worked on the design of the Intel 8087 numeric coprocessor — drove the creation of an industry-wide standard, published in 1985 as IEEE 754.

The core idea of IEEE 754 is dividing a finite number of bits (32 or 64) into three roles — sign, exponent, and mantissa — to approximate the infinite set of real numbers. The exponent handles scale (how large or small a number is), while the mantissa handles precision (how many significant digits it has), letting a fixed number of bits flexibly cover both very small and very large magnitudes. The exponent is stored with a bias added (127 for single precision, 1023 for double) so that comparing two bit patterns as plain unsigned integers is enough to determine which value is larger, avoiding the extra complexity of a signed representation like two's complement.

Only fractions whose denominator is a power of two (1/2, 1/4, 3/8, and so on) can be represented exactly in binary. The decimal value 0.1 is the fraction 1/10, and since 10 is not a power of two, it becomes the infinitely repeating binary fraction 0.0001100110011... With only a finite number of mantissa bits available, it has to be truncated and rounded somewhere — this is the fundamental reason a computer cannot represent 0.1 exactly. It's also why accounting systems that need exact decimal arithmetic typically avoid floating-point numbers in favor of integer arithmetic or a dedicated decimal type (such as BCD).

IEEE 754 was later revised in 2008 and 2019, adding half precision (16-bit), quadruple precision (128-bit), and decimal floating-point formats, but the core three-way split of sign, exponent, and mantissa, along with its rounding modes, has remained unchanged since the original 1985 edition. Because nearly every programming language's float/double type conforms to this standard, the question "why isn't 0.1 + 0.2 equal to 0.3?" shows up in essentially the same form regardless of which language you use.

Browse all trivia