FreeToGenerate.com

The bits, and the exact value underneath them. Nothing is uploaded.

Type it the way you would write it in code. Everything below is what the machine actually stores.

What a JavaScript number, a JSON number, a spreadsheet cell and a C double all are.

Try these

The bits

0011111110111001100110011001100110011001100110011001100110011010
Sign
1
Exponent
11
Fraction
52

Hex: 3fb999999999999a

Kind: Normal — a leading 1 is implied and not stored.

What is actually stored

Not a rounded display of it. This is the exact value, because a binary fraction always terminates in decimal.

Exact value stored

0.1000000000000000055511151231257827021181583404541015625

56 digits

Your number is not stored exactly. The value above is what you got instead.

You typed
0.1
Prints back as
0.1

Where that comes from

7205759403792794 × 2-56

The significand is an integer and the exponent is a whole power of two, so the value is exact by construction — no floating point is involved in working it out.

The nearest other values

Representable values are not evenly spaced. These are the ones immediately either side, and nothing exists between them.

Next below
0.09999999999999999
Next above
0.10000000000000002
Gap to the next value
1.3877787807814457e-17

Also available in: Español · Português · Français · العربية

IEEE 754 floating point converter

See the sign, exponent and mantissa of any number, and the exact decimal value the machine stores rather than the rounded one it prints.

What is IEEE 754?

IEEE 754 is the standard that says how computers store fractional numbers. Almost everything uses it: a JavaScript number, a JSON number, a spreadsheet cell, a C double, a database float. The layout is three fields in a fixed number of bits — one sign bit, then an exponent, then a fraction — and the value they encode is the fraction multiplied by two raised to the exponent.

Because the exponent is a power of two, the format can only store fractions whose denominator is a power of two. A half, a quarter, an eighth: exact. A tenth: not, in the same way a third has no exact decimal expansion. So the number you typed and the number the machine kept are usually not the same number, and the gap between them is what this page shows.

The part most tools skip is the exact value. Programs print floating point numbers using the shortest decimal that would read back as the same value, so 0.1 prints as 0.1 and looks fine. The value actually stored is 0.1000000000000000055511151231257827021181583404541015625. That is not a rounding of the stored value — it is the stored value, written out in full.

How to use it

  1. Type a number. Anything you would write in code, including exponent notation like 5e-324. The buttons cover the cases that show something interesting.
  2. Read the bits. Sign, exponent and fraction are coloured separately, with the hex below them. The panel underneath says whether the value is normal, subnormal, zero, infinity or NaN.
  3. Compare what you typed to what is stored. The exact decimal value appears in full, with a note saying whether your number survived. Switch to 32-bit to see the same number stored in half the bits.

Why 0.1 + 0.2 is not 0.3

This is the example everyone meets first, and the usual explanation — floating point is imprecise — is true but stops one step too early. The interesting part is that all three numbers are already wrong before any addition happens. Stored as doubles, 0.1 is slightly above a tenth, 0.2 is slightly above a fifth, and 0.3 is slightly below three tenths. Type each into the tool above and you can read all three.

Add the first two and the exact result is 0.3000000000000000444089209850062616169452667236328125. The double nearest to three tenths is a different value, and the two are not merely close: they are adjacent. There is no representable number between them, so the sum misses by the smallest amount the format can express at that magnitude, and that is enough to make the comparison false.

The same mechanism explains the money advice you have probably been given. Nothing whose denominator carries a factor of five survives — a tenth, a hundredth, a fifth — which is every currency amount anyone writes down. It is also why comparing two floating point numbers for equality is unreliable in general, while comparing a half or a quarter is perfectly safe.

The things this makes visible

Integers are exact up to a point and then stop. Every whole number is stored perfectly until two to the fifty-third; the very next integer, 9007199254740993, has no representation and collapses onto its neighbour, so a program handling large identifiers can silently merge two of them. Type it above and the tool prints back 9007199254740992. In 32-bit the ceiling is far lower — 16777217 is already too big, and it comes back as 16777216.

Values are not evenly spaced. The gap between neighbours doubles at every power of two: it is about two times ten to the minus sixteen near 1, exactly 1 at two to the fifty-second, and exactly 2 just above that, which is another way of saying odd integers stop existing. Between 1 and 2 there are two to the fifty-second distinct values; between 2 and 4 there are the same number, spread over twice the distance.

Very small numbers change behaviour rather than disappearing. Below the smallest normal value the format drops the implicit leading 1 and lets precision degrade gradually instead of jumping to zero. These are subnormal numbers, and the smallest is two to the minus 1074 — whose exact decimal value is 1,076 characters long, which the tool will happily print.

And there are two zeros. Negative zero has its own bit pattern, compares equal to positive zero, and is distinguishable anyway: dividing one by it gives negative infinity. The bits panel shows the difference that the equality test hides.

How this was checked, and what it does not cover

The exact decimal values are computed with integer arithmetic only — no floating point is involved in describing floating point, which would be circular. A stored value is an integer significand multiplied by a power of two, and multiplying top and bottom by the matching power of five turns it into a terminating decimal, so the expansion is always finite and always exact.

Every bit pattern and every exact value was checked against Python's standard library across more than two thousand numbers spanning the whole range, including subnormals, both zeros, both infinities and the extremes. Python's decimal module reports the exact value of a double rather than an approximation of it, which makes it an exact oracle rather than merely an independent one.

What this does not do: it covers 64-bit doubles and 32-bit floats, not the 16-bit and 128-bit formats or the decimal encodings the standard also defines. It shows round-to-nearest, which is the default everywhere and the only mode most languages expose. And it says nothing about NaN payloads — a NaN carries bits that can differ between operations, but nothing portable depends on them, so the tool reports only that a value is not a number.

If you want the exact binary expansion of the decimal you typed, rather than of the value stored, that is a different question and our base converter answers it: it will show you a tenth as an infinitely repeating binary fraction. The gap between that infinite expansion and the finite one here is precisely the representation error.

Why is it free?

It is arithmetic on integers, running in your browser. Nothing runs on a server, so there is nothing to charge for and no account to create.

Nothing you type is uploaded, stored or logged. The input is a number, and it never leaves the tab.