The first time a 0.1 + 0.2 === 0.3 bug bit me in production, I did what most developers do: I searched, found "floating point is weird," and moved on. It was years before I actually looked at the bits and understood why. Once I did, a whole category of numeric bugs stopped being mysterious. This guide walks through what an IEEE 754 converter shows you, using the IEEE 754 Converter on toolz.dev, and why staring at the sign, exponent, and mantissa is the fastest way to build real intuition about how computers store decimals.
TL;DR: Computers store floating-point numbers as a sign, a power of two, and a fractional significand, following the IEEE 754 standard. An IEEE 754 converter encodes a decimal like 3.14159 into those exact bits and decodes bits back to a value. The IEEE 754 Converter does both, for single and double precision, entirely in your browser, with the sign, exponent, and mantissa broken out.
What is IEEE 754?
IEEE 754 is the standard, first published in 1985 and revised as IEEE 754-2019, that defines how computers represent floating-point numbers in binary. Nearly every CPU, GPU, and programming language follows it, which is why a double behaves the same in C, Java, Python, and JavaScript. When people say "floating point," they almost always mean IEEE 754 binary floating point.
The core idea is that a number is stored in three parts. There is a sign bit that says positive or negative. There is an exponent that scales the value by a power of two. And there is a mantissa, also called the fraction or significand, that holds the precise digits. Put together, a normal number is sign times 1.mantissa times 2 to the exponent. It is scientific notation, in base two, packed into a fixed number of bits.
The two formats you meet daily are single precision, called binary32, and double precision, called binary64. Single uses 1 sign bit, 8 exponent bits, and 23 mantissa bits, for 32 bits total. Double uses 1 sign bit, 11 exponent bits, and 52 mantissa bits, for 64 bits total. Double is the default floating-point type in most languages; single is common on GPUs and in memory-sensitive code.
What does an IEEE 754 converter actually do?
An IEEE 754 converter takes a number and shows you its exact bit pattern, split into those three fields, along with the hexadecimal form and the value read back from the bits. It works both ways: enter a decimal to encode it, or paste a binary or hex bit pattern to decode it back into the number it represents.
On toolz.dev the workflow is short. Pick single or double precision. Choose whether your input is a decimal number, a hex bit pattern, or a binary bit pattern. Enter the value. The tool shows the sign bit, the exponent field, the mantissa, the full bits, the hex, both the biased and unbiased exponent, and the exact stored value. Every field has a copy button.
The reason to look at all of this, rather than trust the number your language prints, is that the printed number lies by omission. When your console shows 0.1, it is showing you a rounded, friendly rendering. The bits tell you what is really stored, and the difference between those two is where floating-point bugs live.
Why does 0.1 plus 0.2 not equal 0.3?
This is the canonical example, and the converter makes it concrete. The value 0.1 cannot be represented exactly in binary floating point, for the same reason 1/3 cannot be written exactly in decimal. In base ten, 1/3 is 0.3333... forever. In base two, 0.1 is a repeating fraction that never terminates, so it has to be rounded to fit in 52 mantissa bits.
Decode the double for 0.1 and the value the bits actually hold is 0.1000000000000000055511151231257827021181583404541015625. The double for 0.2 is similarly a hair too large. Add the two rounded values and the result is a tiny bit more than 0.3, but the double for 0.3 is a tiny bit less, so the two are not equal. Nothing is broken. Each step is doing exactly what IEEE 754 requires, and the converter lets you watch it happen instead of taking it on faith.
Once you have seen this, the fix follows naturally: never compare floats for exact equality. Compare within a small tolerance, or use integer cents for money, or a decimal library when you need exact decimal arithmetic. The bug was never in the addition. It was in expecting a binary format to store decimal fractions exactly.
What are the sign, exponent, and mantissa?
Each field has a specific job, and the converter labels all three.
The sign bit is the simplest: 0 means positive, 1 means negative. Because the sign is a separate bit, IEEE 754 has both a positive and a negative zero, which behave equally in comparisons but carry different bits.
The exponent field stores a power of two, but with a bias added so it can represent negative exponents without a separate sign. The bias is 127 for single precision and 1023 for double. So a stored exponent field of 127 in single precision means an actual exponent of zero. The toolz.dev converter shows both numbers: the biased value that lives in the bits, and the unbiased power of two it actually applies. That distinction trips up a lot of people, which is why the tool spells it out rather than making you subtract in your head.
The mantissa holds the fractional part of the significand. For a normal number there is an implied leading 1 that is not stored, because a normalized binary significand always starts with 1, so the format gets a free bit of precision by leaving it out. That is why single precision gives about 7 decimal digits and double gives about 15 to 16, even though the mantissa fields are 23 and 52 bits.
Here is how the two formats line up field by field:
| Property | Single (binary32) | Double (binary64) |
|---|---|---|
| Total bits | 32 | 64 |
| Sign bits | 1 | 1 |
| Exponent bits | 8 | 11 |
| Mantissa bits | 23 | 52 |
| Exponent bias | 127 | 1023 |
| Approx. decimal digits | 7 | 15 to 16 |
| Common name | float | double |
How do I convert bits back to a decimal number?
Decoding is just as useful as encoding, and it is how you read a value out of a memory dump, a binary file format, or a network protocol that stores raw floats. Set the input type to Hex or Binary and paste the exact bit pattern the precision expects: 8 hex digits or 32 bits for single, 16 hex digits or 64 bits for double.
For example, the single-precision hex 40490FDB decodes to 3.1415927, the closest float to pi. The converter also accepts an optional 0x prefix and ignores spaces and underscores, so you can paste grouped bytes as you find them. If you give it the wrong number of digits, it tells you exactly how many that precision needs rather than silently truncating, which is the kind of error message I wish more tools bothered to write.
This decode direction pairs naturally with a general Number Base Converter when you need to move a value between decimal, hex, binary, and octal without the floating-point interpretation, and with the Binary Translator when you are working with text rather than numbers. I reach for all three often enough that they live in the same corner of my bookmarks.
How are infinity, NaN, and zero represented?
The special values are where IEEE 754 gets clever, and the converter identifies each case for you so you do not have to memorize the patterns.
The exponent field acts as a switch. When every exponent bit is 1, you are in the special range: an all-zero mantissa means infinity, and any non-zero mantissa means NaN, not a number. Positive and negative infinity differ only by the sign bit. NaN is what you get from operations like zero divided by zero or the square root of a negative, and it has the famous property that it does not equal itself.
When every exponent bit is 0, you are in the other special range: an all-zero mantissa is zero, positive or negative depending on the sign bit, and a non-zero mantissa is a subnormal number. Subnormals fill the gap between zero and the smallest normal number, trading precision for the ability to represent very tiny magnitudes. They use an effective exponent of one minus the bias, and they drop the implied leading 1, which the converter accounts for when it shows the unbiased exponent.
Everything else, where the exponent field is neither all zeros nor all ones, is a normal number. Being able to glance at a bit pattern and know instantly which of these five cases you are looking at is a genuine debugging superpower when a calculation produces a value you did not expect.
When do I actually need this?
You need it more often than you would guess once you know to look. I reach for it when a numeric result is off by a rounding error and I want to confirm whether the value is exactly representable. I use it when writing or debugging a binary serializer, a file format, or a wire protocol that stores floats, so I can verify the bytes match what I intended. It is indispensable when comparing single and double precision, for instance deciding whether a GPU shader can use float without losing too much accuracy. And it is one of the clearest teaching aids I know for computer architecture, because seeing the fields makes the abstract standard tangible.
If you build across the stack the way I do, floating point shows up in surprising places: a price calculation in a Laravel API, a canvas animation in React, a CSV export that mangles a coordinate. Understanding the storage format is a small investment that pays off across all of them. I wrote about how tools like this fit into a broader kit in the web developer toolkit, and the number base converter guide and binary translator guide cover the neighboring low-level conversions in more depth.
What are the limits of floating-point precision?
Once you can see the bits, the limits of the format stop being abstract. A double has 52 stored mantissa bits plus the implied leading 1, which works out to roughly 15 to 16 significant decimal digits. Push past that and precision quietly evaporates. The largest integer a double can represent with every value in between still exact is 2 to the 53rd power, which is 9007199254740992. Add one to that and the result rounds back down, because the next representable value is two away, not one. This is why languages that use doubles for all numbers, JavaScript among them, expose a Number.MAX_SAFE_INTEGER constant at exactly that value, and why large database IDs sent as JSON numbers can silently corrupt.
The gap between one representable value and the next is called a unit in the last place, or ULP, and it grows as the magnitude grows. Near 1.0 the gap is tiny; near a billion it is a few hundred; near the maximum double, around 1.8 times 10 to the 308th, the gap between neighbors is astronomically large. The converter makes this visible: encode two nearby large numbers and you will often find they share the same bits, because there simply is no representation between them. Understanding ULP is what stops you from expecting more resolution than the format can give.
A related trap is catastrophic cancellation. When you subtract two nearly equal floating-point numbers, the leading digits cancel and you are left with the low-order bits, which were the least accurate part to begin with. The result can be dominated by rounding error even though each input looked precise. This is why numerically careful code reorders operations to avoid subtracting close quantities, and why summing a long list of floats in a naive loop accumulates error that better algorithms like Kahan summation avoid.
The practical takeaways are consistent. Do not store money as a float; use integer cents or a decimal type, because a value like 0.10 is not exactly representable and errors compound across thousands of transactions. Do not compare floats with exact equality; compare within a tolerance sized to your problem. And when a very large integer must survive a round trip, keep it as a string or use an arbitrary-precision integer type rather than trusting a double to hold it. Each of these rules is easier to remember once the converter has shown you why the format behaves the way it does.
Frequently asked questions
How do I convert a decimal number to IEEE 754?
Choose single or double precision, keep the input type on Decimal, type your number, and convert. The tool encodes the value into its IEEE 754 bit pattern and shows the sign bit, exponent field, mantissa, full binary, and hexadecimal. All of it runs in your browser.
What is the difference between single and double precision?
Single precision (binary32) uses 32 bits: 1 sign, 8 exponent, and 23 mantissa, giving about 7 decimal digits of precision. Double precision (binary64) uses 64 bits: 1 sign, 11 exponent, and 52 mantissa, giving about 15 to 16 digits. Double is the default float type in most languages; single is common on GPUs and in memory-constrained code.
Why does 0.1 not convert to an exact value?
0.1 has no finite representation in binary floating point, just as 1/3 has no finite decimal. The closest representable double is 0.1000000000000000055511151231257827021181583404541015625. The converter shows the stored value read back from the bits, so you can see the tiny difference that causes rounding surprises like 0.1 + 0.2 not equalling 0.3.
What are the sign, exponent, and mantissa?
The sign bit is 0 for positive and 1 for negative. The exponent field stores a power of two with a bias added (127 for single, 1023 for double), which is why the tool shows both the biased value in the bits and the unbiased power it applies. The mantissa holds the fractional part of the significand, with an implied leading 1 for normal numbers.
Can I convert IEEE 754 bits back to a decimal number?
Yes. Set the input type to Hex or Binary and paste the exact bit pattern: 8 hex digits or 32 bits for single precision, 16 hex digits or 64 bits for double. The tool decodes it and shows the decimal value it represents along with the full field breakdown.
How are infinity, NaN, and zero represented?
When every exponent bit is 1, an all-zero mantissa means infinity and a non-zero mantissa means NaN. When every exponent bit is 0, an all-zero mantissa is zero (positive or negative depending on the sign bit) and a non-zero mantissa is a subnormal number. The converter labels each of these cases for you.
Is it safe to use this tool for sensitive numbers?
Yes. The conversion runs entirely in JavaScript in your browser. No network request carries your input, nothing is stored, and the tool works offline once the page has loaded, so any value you enter stays on your device.
What hex format does the converter expect?
Plain hexadecimal digits, with an optional 0x prefix and spaces or underscores for grouping, which are ignored. Single precision expects 8 hex digits and double precision expects 16. For example, 40490FDB is single-precision pi (3.1415927).
Explore the bits yourself with the free IEEE 754 Converter. It encodes and decodes single and double precision floats entirely in your browser, with nothing uploaded.
