IEEE-754 Analysis

What does an IEEE 754 analyzer show?

An IEEE 754 analyzer shows exactly how a computer stores a decimal number as a binary floating-point value. It splits the bit pattern into three fields: a sign bit, a biased exponent and a mantissa (the fraction). It also prints the raw hex. This tool does it for 32-bit single precision and 64-bit double precision, the two formats almost every language uses for float and double.

The formats are defined in IEEE 754-2019, the current revision of the standard, where they're called binary32 and binary64. JavaScript's own Number type is binary64 (ECMAScript specification), so the double-precision output is literally what your browser holds in memory.

Field layout

For a normal number the value is (-1)^sign × 1.fraction × 2^(exponent - bias). The leading 1. isn't stored; it's implied, which buys one free bit of precision.

How to use it

1. Type a number, for example -6.5.
2. Choose Double (64-bit) or Single (32-bit) under Precision.
3. Click Analyze.
4. Read the four lines: sign, exponent bits with the unbiased exponent (or a zero, subnormal or special label) in brackets, all 23 or 52 mantissa bits, and hex.

Worked example: -6.5

Do it by hand first. 6.5 in binary is 110.1 (4 + 2 + 0.5). Normalise it by moving the point two places left: 1.101 × 2². So:

• the sign is 1, because the number is negative
• the true exponent is 2, stored as 2 + 127 = 129 = 10000001 in single precision
• the fraction is what follows the leading 1: 101, padded with zeros

The analyzer agrees. Single precision prints:

Sign: 1
Exponent: 10000001 (2)
Mantissa: 10100000000000000000000
Hex: 0xc0d00000

Double precision uses the larger bias, 2 + 1023 = 1025:

Sign: 1
Exponent: 10000000001 (2)
Mantissa: 1010000000000000000000000000000000000000000000000000
Hex: 0xc01a000000000000

Why 0.1 + 0.2 isn't 0.3

Try 0.3 and then 0.30000000000000004 (which is what JavaScript gives for 0.1 + 0.2) in double precision. The hex outputs are 0x3fd3333333333333 and 0x3fd3333333333334: one unit apart in the last place. Both started as rounded approximations of decimals that repeat forever in binary, and the rounding errors don't cancel.

Single precision has the same problem with fewer bits. 0.1 becomes 0x3dcccccd, which is really 0.100000001490116119384765625. You can see the same rounding in JavaScript with Math.fround(). Integers run out too: 16777217 in single precision comes back as 0x4b800000, which is 16777216, because 24 bits of significand can't hold it.

Special values

The bracket after the exponent bits follows these cases. Zeros print (zero). Subnormals print the minimum exponent the standard gives them, 1 - bias, with a flag: 1e-45 in single precision shows Exponent: 00000000 (-126, subnormal), and 5e-324 in double shows (-1022, subnormal) with a mantissa line ending in a single 1. An all-ones field isn't an exponent, so Infinity, -Infinity and 3.4e39 (which overflows in single precision) show (special: Infinity), and NaN shows (special: NaN). The sign line tells +Infinity from -Infinity.

What it doesn't do

It doesn't convert a hex bit pattern back into a number, doesn't support half precision (16-bit) or 128-bit formats, and doesn't show the exact decimal value of the stored float. Single-precision results come from first parsing your input as a double and then rounding to the nearest 32-bit float, which is the same thing Math.fround does.

Related tools

• Decimal to binary handles the integer part when you're normalising by hand.
• Hex to binary expands a single-precision Hex line into its 32 bits; split a double's 16 hex digits into two halves first, since that tool stops at 53 bits.
• Binary to decimal turns the exponent field back into its stored value.
• The JavaScript lessons include a lesson on numbers that covers the 0.1 + 0.2 surprise from the coding side.