IEEE 754 is the binary floating-point standard that defines how a value such as 3.141592653589793 is laid out as one sign bit, a biased exponent, and a fraction field, with binary32 using 1+8+23 bits and binary64 using 1+11+52 bits per IEEE 754-2019. When you convert a decimal to IEEE 754 in a browser, the JavaScript engine first parses your input as a 64-bit double, then writes those bits through the DataView API in big-endian byte order and reads the stored number back, which is the value that actually appears in memory rather than the digits you typed. The IEEE 754 Floating Point Converter exposes this exact pipeline so you can see the sign, exponent, fraction, classification, binary bits, and hexadecimal interchange form for binary32 or binary64 at the same time. Everything runs locally, so no input or output leaves the page, and the displayed hex matches the bytes the browser would hand to a binary file or network protocol. This makes the tool useful for debugging numeric mismatch reports, validating a payload against a specification, and learning how rounding, signed zero, and special values are encoded at the bit level.
How IEEE 754 Stores a Number in Your Browser
Both formats split a 32-bit or 64-bit word into a sign, an exponent, and a fraction (sometimes called the significand or mantissa). The sign bit is 0 for positive values and 1 for negative. The exponent field is stored with a fixed bias so the comparison hardware can treat it as an unsigned integer, and the fraction holds the bits that follow the implicit leading one for normal numbers. The width of each field is the only structural difference between the two formats, and that single difference cascades into the precision, the range, and the hex digit count you will see in the converter.
| Field | binary32 (single precision) | binary64 (double precision) |
|---|---|---|
| Total bits | 32 | 64 |
| Sign bit | 1 (bit 31) | 1 (bit 63) |
| Exponent bits | 8 (bits 30 to 23) | 11 (bits 62 to 52) |
| Fraction bits | 23 (bits 22 to 0) | 52 (bits 51 to 0) |
| Exponent bias | 127 | 1023 |
| Hex digits shown | 8 | 16 |
| Byte order | Big-endian, MSB first | Big-endian, MSB first |
The bias of 127 for binary32 and 1023 for binary64 is what turns the stored exponent into an unbiased value. For a normal number, the converter reports exponent minus bias; for a subnormal, the unbiased exponent is one minus the bias. Infinity and NaN skip that arithmetic entirely because they are special values rather than finite numbers, and the converter reports their classification instead of computing a misleading exponent.
Convert a Decimal to IEEE 754 Binary32 or Binary64
Pick the encoding direction and the precision that match the consumer you are targeting. binary32 is common in GPU shaders, embedded firmware, and older file formats; binary64 is the default for JavaScript Number values, IEEE 754 double precision in most languages, and the canonical interchange form for 64-bit network payloads.
- Choose decimal-to-bits or bits-or-hex-to-decimal, then select binary32 or binary64 in the converter.
- Enter one decimal value using ordinary base-ten notation, with an optional leading sign, decimal point, and exponent, or use the tokens Infinity, -Infinity, or NaN.
- Convert and inspect the stored value together with the sign bit, exponent field, fraction field, classification, full binary pattern, and hexadecimal representation.
- Copy the hex digits without the 0x label and confirm the byte order and precision against the language, file format, network protocol, or hardware specification that will consume the bytes.
For a deeper walkthrough of the manual sign-and-exponent arithmetic, the decimal to IEEE 754 format guide lays out the same conversion with pen-and-paper steps.
Decode Bit and Hex Patterns Back to Decimal
The reverse direction matters whenever a payload arrives as raw bytes from a binary log, a sensor reading, a saved file, or a remote endpoint and you need to confirm what numeric value it represents. The converter accepts exactly 32 binary digits for binary32, exactly 64 binary digits for binary64, exactly 8 hex digits, or exactly 16 hex digits, with an optional 0x prefix on the hex form. Anything outside those widths is rejected, which keeps the bit pattern unambiguous and prevents partial-field decoding.
The accepted bits are written into an ArrayBuffer and read back through DataView as the matching float, so the displayed sign, exponent, and fraction fields reflect the exact bytes you entered. JavaScript still exposes every NaN value as the single value NaN, so two NaN payloads with different fraction bits are indistinguishable through the numeric output even though both bit patterns remain visible in the converter. Positive zero and negative zero follow the same rule: their stored bits differ, but ordinary comparisons treat them as equal, which is why operations such as reciprocal can produce different results.
Why binary32 Changes the Value You Typed
JavaScript does not have a binary32 type. It only has a single Number type, which is binary64, so the converter parses your input as a double first and then rounds it to the nearest representable single when you select binary32. The stored value line in the converter reflects that narrowed result, which is the value a single-precision consumer such as a shader or a fixed-size file field will actually read. The bit pattern is the binary32 encoding of that narrowed value, not a re-encoding of the original decimal spelling.
This matters for any decimal that does not have an exact binary representation. Many familiar fractions, including 0.1, require an infinite binary expansion and round to the nearest representable double. Large integers also lose unit precision in binary64 well before they reach the limit of 2 to the 53, and binary32 loses precision much sooner. When a domain requires exact money, identifiers, or arbitrary precision, the IEEE 754 interchange format is the wrong tool and a decimal or big-integer library is the right one. The converter makes the rounding visible rather than hiding it, which is the point of comparing the stored value against the input.
Zero, Subnormal, Infinity, and NaN Classifications
The exponent and fraction fields together decide how a bit pattern is interpreted, and the same bits under a different field pattern can mean a normal number, a subnormal, a signed zero, infinity, or NaN. The classification rule is mechanical: an all-zero exponent with a zero fraction is signed zero, with a nonzero fraction it is subnormal, a nonzero exponent below the all-ones pattern is normal, an all-ones exponent with a zero fraction is infinity, and with a nonzero fraction it is NaN.
| Exponent field | Fraction field | Classification | Unbiased exponent |
|---|---|---|---|
| All zeros | All zeros | Signed zero | Not finite |
| All zeros | Nonzero | Subnormal | 1 − bias |
| All ones | All zeros | Infinity | Special value |
| All ones | Nonzero | NaN | Special value |
| Any other | Any | Normal | Exponent − bias |
Subnormals fill the gap between zero and the smallest normal magnitude by using a leading zero instead of the implicit leading one, which costs precision but extends the range downward. The converter displays them with the unbiased exponent reported as 1 minus the bias so you can compare them directly with normals on the same scale.
Verify the Hex and Byte Order Against the Consumer
The hex output is the single most useful artifact for cross-checking because it survives copy and paste exactly and maps directly to bytes. The display shows exactly eight hex digits for binary32 and exactly 16 for binary64 in most-significant-byte-first order, which is the order produced by the big-endian DataView writes the converter performs internally. If the consumer you are feeding is little-endian, or expects 32-bit and 64-bit words split into separate high and low words, you still need to reorder the bytes before placing the value into a file or packet.
The standard itself defines only the value; it does not define which byte comes first on the wire. Byte order is part of the contract with the consumer, so the safe sequence is to convert, copy the hex, then compare it against the language, file format, network protocol, or hardware specification that will read the bytes. The IEEE 754-2019 standard and the ECMAScript Number type specification document the format and the JavaScript narrowing behavior respectively, and they are worth bookmarking whenever a numeric mismatch report lands in your queue.
A quick smoke test is to convert 1.0 to binary64 and back, then convert 0.1 to binary64 and read the stored value carefully: 1.0 round-trips exactly, while 0.1 reveals the single-bit rounding that explains most floating-point surprises in code review. Adding -0.0 confirms that negative zero decodes with its sign bit set while still comparing equal to 0.0 under normal arithmetic. These three fixtures are usually enough to validate that the rest of the conversion path is wired correctly before you start comparing production payloads.
Related reading: How to Convert a Decimal IP Address to Hexadecimal.