Converting a decimal number into IEEE 754 floating point format means expressing that value as a 1-bit sign, a biased exponent field, and a fraction field packed into a fixed-width 32-bit or 64-bit word. The 32-bit form is called binary32 (single precision), and the 64-bit form is called binary64 (double precision). Both layouts follow the IEEE 754 standard for binary floating-point arithmetic and are the formats every modern CPU, GPU, and Web browser uses for float and double values. The conversion is fully deterministic: for any decimal value you enter, there is exactly one IEEE 754 bit pattern in the format you choose, and that pattern can be decoded back into the same numeric value the browser will actually store. To inspect that pattern without writing parsing code by hand, you can use the IEEE 754 Floating Point Converter, which encodes decimals to binary32 or binary64 fields and decodes the bit or hex representation back to a browser number, all through the browser's DataView API. Every step happens locally, so the exact bytes a browser will hold for your value are visible without approximation.
The IEEE 754 bit layout for binary32 and binary64
Every IEEE 754 binary floating-point value, whether single or double precision, is built from the same three parts: a single sign bit, an exponent field with a fixed bias, and a fraction field that stores the bits after the binary point (also called the mantissa or significand). The widths are different between the two formats, but the layout grammar is identical, which is why the same conversion logic can handle both.
| Field | Binary32 (single precision) | Binary64 (double precision) |
|---|---|---|
| Total bits | 32 | 64 |
| Sign bits | 1 | 1 |
| Exponent bits | 8 | 11 |
| Fraction bits | 23 | 52 |
| Exponent bias | 127 | 1023 |
| Exponent range (unbiased, normal) | -126 to +127 | -1022 to +1023 |
| Smallest positive subnormal | 2^-149 | 2^-1074 |
| Hex digits in interchange form | 8 | 16 |
The exponent is stored biased, meaning the true exponent plus the bias is what appears in the bits. For a normal number, the unbiased exponent equals the stored exponent minus the bias (127 for binary32, 1023 for binary64). For subnormals, the unbiased exponent is one minus the bias, so the formula shifts by one. The sign bit is 0 for non-negative values and 1 for negative values; positive and negative zero both have an exponent field of all zeros and a fraction field of all zeros, with only the sign bit flipped between them. Hexadecimal output for these formats is shown with the most-significant byte first and uses exactly eight hex digits for binary32 or sixteen for binary64, with no 0x label when you copy it for use in another tool or file.
Why binary32 changes your decimal value
When you type a decimal number such as 0.1 or 1234567 into the converter and select binary32, the result is rarely the exact decimal you typed, and that mismatch is not a bug. JavaScript first parses the decimal as a double-precision Number, then the DataView rounds that double down to the nearest representable binary32 value. The "stored value" you see in the output is the rounded single-precision result, not the original decimal spelling. For binary64, the stored value reflects the browser's double-precision interchange value rather than the original decimal spelling, so values such as 0.1 still differ from the typed input once that nearest-representable rounding is applied.
This means the conversion to IEEE 754 is always a projection from your decimal into the nearest representable binary floating-point value in the chosen format. The IEEE 754 Floating Point Converter exposes it by reading the bit pattern back through DataView.getFloat32 or DataView.getFloat64 in big-endian byte order, so the bits you see are exactly the bits the browser will store, not an approximation the tool computed by hand. If you need the exact decimal spelling preserved, move to a decimal or arbitrary-precision library: IEEE 754 cannot represent most decimal fractions exactly because their binary expansion is infinite. Treat the stored value the converter reports as the actual numeric quantity, not your typed decimal.
Convert a decimal number to IEEE 754 format
The converter is built around two opposite directions: decimal-to-bits and bits-or-hex-to-decimal. The decimal-to-bits path is the one most readers come for, and the steps below walk through it and what to look at in the result.
- Open the IEEE 754 Floating Point Converter and choose the decimal-to-bits direction, then pick binary32 (single precision) or binary64 (double precision) from the format selector.
- Enter a single decimal value in ordinary base-ten notation with an optional sign, fraction, and decimal exponent. The input also accepts the special tokens Infinity, -Infinity, and NaN. Leave the field empty to clear it: empty input is rejected, not treated as zero.
- Click convert. The tool writes your value through DataView.setFloat32 or DataView.setFloat64 in big-endian byte order, reads the stored number back, and renders the full breakdown.
- Inspect the sign, exponent, fraction, classification, stored value, and the binary bit string split into the standard field widths (1 + 8 + 23 for binary32, 1 + 11 + 52 for binary64).
- Copy the hexadecimal interchange form (eight hex digits for binary32, sixteen for binary64, no 0x label) and verify it against the byte order and precision expected by the protocol, file format, or hardware that will consume it.
Hexadecimal numeric literals, comma-separated numbers, units, and locale-specific decimal separators are rejected on the way in. That explicit rejection matters because it prevents JavaScript's silent coercions from hiding a parsing mistake behind a plausible-looking bit pattern. For example, a typed "1,000" will not silently become one thousand; it will be refused so you can correct it to "1000" or "1.0e3" and try again.
Reading the decoded fields after conversion
After a conversion, four fields give you the most signal about what the bits actually mean. The sign is a single 0 or 1. The exponent is the raw biased value straight out of the bit pattern; subtract 127 for normal binary32 values or 1023 for normal binary64 values to get the unbiased exponent, or use one minus the bias for subnormals. The fraction field is the raw bits after the implicit leading 1 is appended, so for a normal value the significand is 1.fraction in binary. The classification line tells you which category the exponent and fraction patterns fall into.
As a worked reference, the decimal value 1.0 in binary32 breaks down as sign 0, biased exponent 127 (binary 01111111), fraction 0, classification normal, stored value 1, and hex 3F800000. The bit string 0 01111111 00000000000000000000000 reads as "positive, exponent field is 127, no fraction bits set," which is the canonical single-precision encoding of one. The same value in binary64 is sign 0, biased exponent 1023, fraction 0, stored value 1, and hex 3FF0000000000000. These are reference fixtures in the converter's test set, so they are good values to confirm the tool is working correctly before trusting it on trickier inputs.
When IEEE 754 precision matters and when it does not
Two situations make decimal-to-IEEE-754 conversion lossy even when the tool is functioning perfectly. The first is decimal fractions whose binary expansion is infinite: 0.1, 0.2, 0.3, and almost every value that is not a sum of powers of two will round to the nearest representable binary value. The converter reports that rounded stored value, not the original decimal, which is exactly the information you need when comparing against what the browser will actually do. The second is large integers: binary64 can represent integers exactly only up to 2^53, and binary32 gives up much sooner, around 2^24, because only 24 bits of significand are available.
| Exponent pattern | Fraction pattern | Classification |
|---|---|---|
| All zeros | All zeros | Zero (sign picks +0 or -0) |
| All zeros | Nonzero | Subnormal |
| All ones | All zeros | Infinity (sign picks +∞ or -∞) |
| All ones | Nonzero | NaN |
| Anything else | Any | Normal |
For money, identifiers, counters that must round-trip exactly, or any domain where a single lost unit matters, do not rely on IEEE 754 at all: use a decimal library or an integer representation. For graphics, signal processing, scientific simulation, and protocol headers that already mandate IEEE 754, the converter is the right tool to verify that the bytes you are about to send match what the receiver expects. The base-conversion companion guide covers the reverse case where you start from bits and want to read them in another base, and the IEEE 754-2019 standard is the authoritative source for every field width, bias, and classification rule used here.