An IEEE 754 floating-point binary32 or binary64 value is stored as one sign bit, a biased exponent field, and a fraction field, and the IEEE 754 Floating Point Converter lets you base convert IEEE 754 floating point values in your browser by encoding decimals into those exact fields or decoding bit and hex patterns back to browser numbers. For binary32, the layout is one sign bit, eight exponent bits, and 23 fraction bits, with an exponent bias of 127 and an eight-digit hexadecimal interchange string written most-significant byte first. For binary64, the layout is one sign bit, 11 exponent bits, and 52 fraction bits, with an exponent bias of 1023 and a 16-digit hexadecimal interchange string also written most-significant byte first. Every conversion runs through the browser's DataView API with setFloat32 or setFloat64 in big-endian byte order, so the bits and hex you see are the bits the browser itself stores. Use the converter to inspect sign, exponent, fraction, classification, the rounded stored value, and the full hexadecimal interchange form before sending that value to a network protocol, file format, or hardware register that expects a specific IEEE 754 layout.
IEEE 754 binary32 and binary64 field layouts
Both binary32 and binary64 follow the IEEE 754-2019 structure of one sign bit, a biased exponent, and a trailing fraction, but their field widths and bias constants differ. The table below summarizes the two layouts so you can pick the right width for the consumer that will read your output.
| Property | binary32 (single precision) | binary64 (double precision) |
|---|---|---|
| Total width | 32 bits | 64 bits |
| Sign bit width | 1 bit | 1 bit |
| Exponent width | 8 bits | 11 bits |
| Fraction width | 23 bits | 52 bits |
| Exponent bias | 127 | 1023 |
| Hex digits (MSB first) | 8 | 16 |
| Unbiased exponent for normal values | stored minus 127 | stored minus 1023 |
| Unbiased exponent for subnormals | 1 minus 127 | 1 minus 1023 |
The IEEE 754 standard reserves the all-zeros exponent pattern for zero and subnormal values and the all-ones pattern for infinity and NaN. Everything in between is a normal number with an implicit leading 1 in the fraction. You can confirm the exact widths and reserved patterns in the IEEE 754-2019 standard when you need to map the same logic to half precision, quad precision, or any other width the standard defines.
Encode a decimal value to IEEE 754 bits
- Open the converter and select the decimal-to-bits direction, then choose binary32 or binary64 for the target precision.
- Type one value in ordinary base-ten notation. An optional leading sign, a fractional part, and a decimal exponent such as 1.5e-3 are accepted; Infinity, -Infinity, and NaN are also accepted. Hexadecimal tokens, commas, units, and locale decimal separators are rejected on purpose so the parser does not silently coerce input.
- Read the result panel for the stored value, the sign bit, the stored exponent, the fraction, the classification (zero, subnormal, normal, infinity, or NaN), the unbiased exponent, the full bit string, and the hexadecimal interchange form. For binary32 the bit string is 32 digits and the hex is eight digits; for binary64 the bit string is 64 digits and the hex is 16 digits, with the most-significant byte first in both cases.
- Use the copy action to grab the hex digits without the 0x label and paste them into your code, protocol, or fixture file.
The encoding path writes the JavaScript Number through DataView.setFloat32 or DataView.setFloat64 in big-endian byte order and then reads the stored value back, which is why binary32 reveals the rounding that occurs when a double-precision input is narrowed to single precision. As a worked example, encoding 1.0 in binary64 produces the bit string 0 01111111111 0000000000000000000000000000000000000000000000000000: sign bit 0, stored exponent 01111111111 (decimal 1023, which is the bias 1023 plus the unbiased exponent 0), fraction all zeros, and a hex interchange of 3FF0000000000000. Any rounding or precision loss in your original input becomes visible directly in those fields.
Decode bits or hexadecimal back to a number
- Switch the converter to the bits-or-hex-to-decimal direction and pick binary32 or binary64 so the parser expects the matching length.
- Enter exactly 32 binary digits or eight hexadecimal digits for binary32, or exactly 64 binary digits or 16 hexadecimal digits for binary64. A leading 0x on the hex form is optional. Other lengths are rejected so partial inputs cannot produce a misleading stored value.
- Inspect the recovered stored value, the sign, the stored exponent, the fraction, the classification, the unbiased exponent, and the entered bit pattern. The entered sign, exponent, and fraction fields stay visible even when the stored value collapses to a special value such as NaN.
- If the decoded value is NaN, remember that ECMAScript exposes every NaN payload as the single value NaN. The entered bits remain in the display, but distinct NaN payloads cannot be distinguished through the numeric value alone.
This path writes the entered bits into an ArrayBuffer and reads the matching float back through the same DataView calls used for encoding, which preserves the bit pattern end-to-end. Negative zero, encoded as sign 1 with an all-zero exponent and a zero fraction, decodes back as -0 and stays separate from positive zero even though the two values compare equal in ordinary arithmetic.
Classifications and special values
IEEE 754 classifies every bit pattern based on the exponent and fraction fields rather than the numeric value. The rules below apply identically to binary32 and binary64, with only the field widths changing.
| Classification | Exponent field | Fraction field | Unbiased exponent |
|---|---|---|---|
| Zero | All zeros | All zeros | Not reported (special) |
| Subnormal | All zeros | Nonzero | 1 minus bias (for example 1 minus 127) |
| Normal | Nonzero, not all ones | Any | Stored value minus bias |
| Infinity | All ones | All zeros | Not reported (special) |
| NaN | All ones | Nonzero | Not reported (special) |
The converter reports classification instead of inventing an unbiased exponent for infinity or NaN, because those are special values, not ordinary numbers with a finite exponent. Positive and negative zero share the same fraction and exponent but differ in the sign bit, and that sign can produce different results in operations such as reciprocals, which is why the page preserves -0 when it is entered or decoded.
Why precision and byte order matter
Many decimal fractions, including the familiar 0.1, require an infinite binary expansion and round to the nearest representable value when stored as binary32 or binary64. Large integers can also lose unit precision in binary64, and binary32 loses precision much sooner. The converter makes that rounding visible by showing the stored value alongside the original input, but the bit pattern itself is not a proof that the decimal value is exact. When a domain requires exact money, identifiers, or arbitrary precision, use a decimal or integer library instead of raw IEEE 754 floats.
Byte order is the second contract you must respect. The converter writes and reads in big-endian order, which matches DataView.setFloat32 and setFloat64 with no endian argument. If your protocol, file format, or hardware expects little-endian floats, swap the bytes before writing them or you will silently invert the result. Eight external fixtures are built into the tool to cover binary32 1, negative zero, positive infinity, the maximum finite value, the minimum positive subnormal, and binary64 1, negative zero, and pi, with additional tests for subnormal, infinity, NaN, and binary input boundaries.
Verifying against the actual consumer
Treat the bit pattern and hex from the converter as a contract, not as a free-form representation. Compare them against the language runtime, file format, network protocol, or hardware specification that will read the value, paying special attention to byte order, width, and how the consumer handles NaN payloads and negative zero. If the consumer is a C struct, a Java Float, a WebAssembly memory layout, or a binary log file, its floating-point rules and endianness must match what the converter produced. When any of those do not match, the converter is the place to find the mismatch, not in the downstream code, because every step runs locally through the same DataView calls that the rest of the browser uses for float interchange.