Hex to Float Converter (IEEE 754)
Paste a hex value from a debugger, protocol capture, or register map, and decode it into its IEEE 754 floating-point decimal. Each bit field β sign, biased exponent, mantissa β is shown step-by-step so you can trace the conversion and catch byte-order problems before they reach production.
Step-by-Step Conversion
- 1
Turn hex into bits
Each hex digit expands to exactly 4 binary bits.
40490FDB β 01000000010010010000111111011011
- 2
Split the bits into 3 parts
Bit 31 = sign, bits 30β23 = exponent (8 bits), bits 22β0 = mantissa (23 bits).
Sign: 0
Exponent: 10000000
Mantissa: 10010010000111111011011
- 3
Find the exponent (the power of 2)
Convert exponent bits to decimal, then subtract the bias of 127.
10000000 (binary) = 128 (decimal); 128 β 127 = 1
Actual exponent: 1
- 4
Find the mantissa value (the 1.xxx part)
Add the implicit leading 1 to the stored fraction bits.
Mantissa value: 1.5707963705
- 5
Put it together for the final number
Combine all three fields: (β1)^sign Γ 1.mantissa Γ 2^(exponent β 127).
(β1)^0 Γ 1.5707963705 Γ 2^1
= 3.1415927410125732
Visual Breakdown
See how each IEEE 754 field decodes step-by-step β from raw hex input through binary field extraction to the final decimal result.
40490FDB β sign 0, exponent 10000000, fraction 10010010000111111011011 β 3.1415927410125732
Common 32-bit values
| Hex | Float | What It Represents |
|---|---|---|
| 3F800000 | 1.0 | Positive one |
| 3F000000 | 0.5 | One half |
| 40490FDB | β 3.1415927 | Nearest 32-bit value to Ο |
| 42F6E979 | β 123.456 | Exponent 6, mantissa β 1.929 |
| 3DCCCCCD | β 0.1 | Nearest 32-bit approximation of 0.1 |
| 7F800000 | +Infinity | Positive infinity |
| 7FC00000 | NaN | Quiet NaN (canonical) |
Key Terms
| Term | Label | Details |
|---|---|---|
| IEEE 754 | Standard | Floating-point bit-layout standard |
The specification that defines how sign, exponent, and mantissa bits are packed into 32-bit (single) and 64-bit (double) words, ensuring the same hex string decodes to the same float across every CPU, GPU, and language runtime β as long as byte order matches. | ||
| Biased Exponent | Exponent field | Stored exponent + 127 |
| Mantissa (Significand) | Fraction bits | The precision-carrying bits |
| Endianness | Byte order | Which byte comes first in memory |
| Subnormal (Denormalized) | Gradual underflow | Tiny values near zero without implicit 1 |
| ULP (Unit in the Last Place) | Precision gap | Smallest representable step at a given magnitude |
| Quiet vs. Signaling NaN | NaN variants | Propagates silently vs. raises exception |
Frequently Asked Questions
The same bits mean different numbers depending on how you interpret them. 0x3F800000 is 1065353216 as an unsigned integer, but 1.0 as an IEEE 754 32-bit float. This tool interprets the bits as a float.
Each 8-character hex string expands to 32 bits that IEEE 754 splits into three fields: bit 31 (sign), bits 30β23 (8-bit biased exponent, bias = 127), and bits 22β0 (23-bit mantissa). The final value is (β1)^sign Γ 1.mantissa Γ 2^(exponent β 127), except when the exponent field is all zeros (subnormal) or all ones (infinity / NaN).
When all eight exponent bits are set (stored value = 255), a zero mantissa encodes Β±infinity (7F800000 positive, FF800000 negative) and any non-zero mantissa encodes NaN. 7FC00000 is the canonical quiet NaN on most platforms β the most-significant mantissa bit set marks it quiet; clear marks it signaling (7F800001).
A 32-bit float spans two consecutive 16-bit Modbus registers. If register 40001 holds 41C8 and 40002 holds 0000, concatenate them in that order to get 41C80000 β 25.0.
When a Modbus float decodes to a nonsense value, swap the two register halves and reconvert β vendor word-order disagreement is the most common cause. 0000 + 41C8 β 000041C8 decodes to a tiny subnormal near zero, not 25.0.
Reverse the byte pairs, not the individual hex characters. If your dump reads 00 00 C8 41 in memory order, reverse byte order to 41 C8 00 00 and concatenate to 41C80000 β 25.0. Reversing the individual characters of 0000C841 gives 148C0000, which is a different bit pattern.
0.1 in decimal is a repeating binary fraction that never terminates, so IEEE 754 rounds it to the nearest 23-bit mantissa it can store β the result overshoots by roughly 1.49 Γ 10β»βΉ, less than half an ULP, the normal rounding error of single precision. Every language using 32-bit floats stores the same approximation; switch to double (f64) if you need more than ~7 significant decimal digits.
The quickest cross-check is Python's struct module: struct.unpack('>f', bytes.fromhex('42F6E979')) returns (123.45600128173828,), confirming the tool's output for that input.
The tiny overshoot from the expected 123.456 is less than half an ULP, the normal rounding error of single precision β the same approximation every 32-bit runtime produces, not a decoding error.
GLSL mediump floats on mobile GPUs are often 16-bit half-precision, not 32-bit β the two precisions produce different bit patterns for the same value, so a hex dump from the GPU won't match what this tool decodes from a 32-bit CPU float. Switching the variable's precision qualifier from mediump to highp forces 32-bit on GPUs that support it and eliminates the mismatch.
When the stored exponent is 00 (all eight bits zero) and the mantissa is non-zero, two rules change: there is no implicit leading 1 in the mantissa, and the effective exponent is fixed at β126 rather than 0 β 127 = β127.
This design allows values all the way down to 00000001 (β 1.4 Γ 10β»β΄β΅), preventing an abrupt jump from the smallest normal float to zero β called gradual underflow.
The practical hazard: some embedded cores enable a Flush-to-Zero (FZ) flag (ARM Cortex, for example) that silently replaces any subnormal result with 0.0 for performance. A converter that returns 0.0 for 00400000 is either misconfigured or wrong β the correct result is 5.877 Γ 10β»Β³βΉ. Silent FZ corruption can accumulate across a floating-point DSP loop without raising any exception.