An IEEE 754 binary32 single-precision floating point value is represented by exactly 8 hexadecimal digits, and a binary64 double-precision value is represented by exactly 16 hexadecimal digits, with the most-significant byte written first. To convert hex to an IEEE 754 floating point number, take that bit string apart into three fields: one leading sign bit, a biased exponent field, and a fraction field, then evaluate the formula sign × 1.fraction × 2^(exponent − bias). The IEEE 754 standard defines the bias as 127 for binary32 and 1023 for binary64, and it adds an implicit leading 1 to the fraction for every normal number. Special patterns cover zero, subnormals, infinity, and NaN. A reliable way to convert hex to IEEE 754 floating point without writing a parser is to feed the hex into the IEEE 754 Floating Point Converter, which writes those exact bits through the same DataView routine JavaScript uses for binary32 and binary64 interchange and reports the decoded number, sign, exponent, fraction, classification, and unbiased exponent.
Hexadecimal is the canonical carrier for IEEE 754 interchange because every hex digit maps to four binary digits. That mapping turns a 32-bit float into 8 hex characters and a 64-bit float into 16 hex characters without any ambiguity about leading zeros or endianness in the text. When a file format, network protocol, or compiled binary stores a float, it stores those bits, and the hex representation is what you see when you dump those bytes with a debugger, a hex editor, or a logging tool. Reversing that process is the everyday task behind queries like "convert hex to IEEE 754 floating point", and the rules below let you read the bits yourself or hand them to a tool that does.
What an IEEE 754 Hex String Actually Encodes
An IEEE 754 hex string is a packed bit pattern, not a number in disguise. The text "4029000000000000" does not mean 4.029 × 10^15 in decimal; it means the 64 bits 01000000 00101001 00000000 00000000 00000000 00000000 00000000 00000000, and those bits decode to the floating point value 12.5 once you apply the IEEE 754 rules. The same caution applies to short hex values: "3F800000" is exactly 1.0 as a binary32 float, not a decimal with a trailing zero. Reading hex as a packed bit pattern is the only interpretation that matches what a file, a wire format, or a hardware register actually stores.
Two widths are worth keeping straight. The narrower width is binary32, also called single precision, with 8 hex digits and the bias 127. The wider width is binary64, also called double precision, with 16 hex digits and the bias 1023. Confusing the two widths is the single most common reason a hex-to-float answer looks wrong by many orders of magnitude, because doubling the exponent field while leaving the mantissa in place can shift a value by a factor of more than a billion. If a hex string is shorter than 8 digits it cannot be a complete binary32 pattern, and if it sits between 9 and 15 digits long it does not fit either standard width cleanly, so a strict decoder rejects the input rather than padding it with stray zeros.
Splitting the Bits into Sign, Exponent, and Fraction
Once you have a complete hex pattern of 8 or 16 digits, split the underlying bits into three consecutive fields. The leftmost bit is the sign: 0 for positive, 1 for negative. The next group is the biased exponent, 8 bits wide for binary32 and 11 bits wide for binary64. The remaining bits are the fraction, 23 bits for binary32 and 52 bits for binary64. The unbiased exponent is the biased value minus 127 for binary32 or minus 1023 for binary64. The fraction is read as a binary value with an implicit leading 1 placed to the left of the binary point for every normal number, producing a mantissa between 1.0 and just below 2.0. The decoded value is sign × mantissa × 2^unbiased exponent.
Special patterns short-circuit the formula. An all-zero exponent with an all-zero fraction is +0 or −0 depending on the sign bit; they compare equal in ordinary comparisons but differ in operations like reciprocal. An all-zero exponent with a nonzero fraction is subnormal, the mantissa uses 0.fraction instead of 1.fraction and the unbiased exponent is one minus the bias so that the smallest subnormal still produces a positive value. An all-ones exponent with a zero fraction is +∞ or −∞. An all-ones exponent with a nonzero fraction is NaN, and JavaScript exposes every NaN as the single value NaN even when distinct payloads remain visible in the entered bits.
A worked example makes the field arithmetic concrete. Take the hex string 4029000000000000 as a binary64 pattern. The binary form is 01000000 00101001 00000000 00000000 00000000 00000000 00000000 00000000. The sign bit is 0, the exponent field 10000000010 binary equals 1026 decimal, and 1026 minus the bias 1023 leaves an unbiased exponent of 3. The fraction field starts with the bits 1001 and is followed by zeros, which is the binary fraction 0.1001, equal to 1/2 + 1/16 = 0.5625. With the implicit leading 1, the mantissa becomes 1.1001 binary, which is 1.5625 in decimal. Multiplying by 2^3 gives 1.5625 × 8 = 12.5. The same hex string fed to the IEEE 754 Floating Point Converter reports the stored value 12.5 alongside the sign, exponent, fraction, classification, and full 64-bit pattern.
How to Convert Hex to IEEE 754 Floating Point
The decoding workflow has three short steps: pick the bit width that matches the hex string, enter the hex, and read the stored value plus every field the tool exposes. The exact sequence used by the IEEE 754 Floating Point Converter is below.
- Choose the bits-or-hex-to-decimal mode and select binary32 for an 8-digit hex string or binary64 for a 16-digit hex string.
- Enter the hex string with or without the 0x prefix into the hex field. The input must be exactly 8 or 16 hex digits for the chosen width; shorter or longer strings are rejected rather than truncated.
- Read the stored value, sign bit, biased exponent, unbiased exponent, fraction, classification (zero, subnormal, normal, infinity, or NaN), and the full binary pattern. Copy the binary or hex if you need to paste it into another tool, and verify byte order against the actual consumer before relying on the value in a protocol or file.
If you have a decimal value to encode instead, switch the tool to decimal-to-bits mode, choose binary32 or binary64, enter the decimal in ordinary base-ten notation with an optional sign and exponent, and read the hex output along with the stored value, which reveals the rounding that occurs when a binary64 input narrows to binary32.
Comparing binary32 and binary64 in Hex
The two widths share the same overall layout but trade exponent range for mantissa precision. The table below summarizes the IEEE 754-2019 fields that drive every hex-to-float conversion.
| Field | binary32 (single) | binary64 (double) |
|---|---|---|
| Total bits | 32 | 64 |
| Hex digits | 8 | 16 |
| Sign bits | 1 | 1 |
| Exponent bits | 8 | 11 |
| Fraction bits | 23 | 52 |
| Exponent bias | 127 | 1023 |
| Smallest positive subnormal | 2−149 | 2−1074 |
| Largest finite value | (2 − 2−23) × 2127 | (2 − 2−52) × 21023 |
These are the field widths and bias values defined by the IEEE 754-2019 standard. They are constants of the format, not values computed by the tool, so the same table applies to any IEEE 754 binary32 or binary64 interchange. Picking the wrong row when reading a hex pattern is the fastest way to misread a value, so the table is worth pinning next to your decoding step.
Why Byte Order and Precision Matter for Hex Decoding
Hexadecimal text removes endianness ambiguity by writing the most-significant byte first, but the byte order of the underlying storage still matters when the hex came from a dump of raw memory. Most file formats and network protocols use big-endian byte order for IEEE 754 interchange, and the JavaScript DataView routines used by the IEEE 754 Floating Point Converter also write and read in big-endian order, so a hex string lifted from a big-endian source decodes directly. A little-endian source produces the same hex string only after its bytes are reversed, and swapping byte order changes every bit of the float, often by sign as well as magnitude.
Precision is the second contract a hex string carries. Binary64 has 52 fraction bits, which is around 15 to 17 significant decimal digits, while binary32 has 23 fraction bits and gives only about 6 to 9 significant decimal digits. The stored value reported by the converter reflects the rounded binary value, not the decimal string you might have started from, so a 0.1 input rounds to a nearby binary64 value rather than reproducing the infinite 0.0001100110011... expansion. For money, identifiers, and arbitrary-precision arithmetic, use a decimal or integer library rather than re-decoding a hex float, because the rounding has already happened and cannot be undone by switching tools.
Limits of Browser-Based Hex Decoding
The IEEE 754 Floating Point Converter runs entirely in the browser and uses the same DataView routines as the JavaScript runtime, so it matches what a JavaScript Number will hold for any given bit pattern. That symmetry has three practical limits. First, distinct NaN payloads cannot be distinguished through the numeric value because JavaScript collapses every NaN to a single value, although the entered bits remain visible in the display. Second, the converter reports the classification of infinity and NaN rather than inventing an unbiased exponent, because the unbiased exponent is undefined for those patterns. Third, the input parser rejects hexadecimal numeric literals, expressions, commas, units, and locale-specific decimal separators to keep parsing explicit, which means a stray "0x" prefix on a binary input or a comma in a fraction will produce an error rather than a silently coerced value. For the byte-order, precision, and classification rules that govern hex interchange in a specific format, cross-check the bit pattern against the language, file format, network protocol, or hardware specification that will consume it.
For the decimal-to-bits direction, the same tool exposes the rounding behavior a binary64 input undergoes when narrowed to binary32, and it accepts Infinity, -Infinity, and NaN in decimal form alongside ordinary base-ten notation. The combined decode and encode coverage lets the IEEE 754 Floating Point Converter serve as the single local reference for moving between hex interchange patterns and browser floats, and pairs naturally with a deeper walkthrough of converting decimal numbers to IEEE 754 floating point format when the input is a decimal value rather than a hex bit pattern.
For a deeper look, see How to Convert a Hex IP Address to Dotted Decimal.