Skip to content
100% local

IEEE 754 converter

Convert a decimal number to its IEEE 754 bit pattern, or bits back to a number.

Input

IEEE 754 converter

Every floating-point number a computer stores is really a sign bit, an exponent and a mantissa, packed together according to IEEE 754 — the standard that C, Java, Python and JavaScript all use for their number types. Paste a decimal number and this tool encodes it into that exact bit pattern; paste the bit pattern back in and it decodes it to a number. Switch direction with one click to go either way.

Two precisions are supported: 32-bit single (1 sign bit, 8 exponent bits, 23 mantissa bits — a C float or a Rust f32) and 64-bit double (1 + 11 + 52 — a C double, and what every JavaScript number is under the hood). The bit pattern can be written as hexadecimal or as a plain string of 0s and 1s, with byte order set to big-endian or little-endian to match how a debugger or memory dump lays the bytes out.

Turn on "Show sign / exponent / mantissa" to see the three fields split apart — the fastest way to see why a number encodes the way it does. Turn on "Show actual stored value and rounding error" to see what a number actually becomes once stored: 3.14 isn't exact in either precision, and the tool shows the real stored value alongside the gap between what you typed and what the hardware keeps — the reason floating-point comparisons in code go wrong. Special values — 0, -0, Infinity, -Infinity and NaN — all convert to their defined patterns, one per line, so a whole list converts at once.

Everything runs locally in your browser, using the same DataView the JavaScript engine itself uses to read and write IEEE 754 floats — no server-side floating-point library, and no data leaves your device.

FAQ

What is IEEE 754?
It is the standard that defines how computers store non-integer numbers in binary: a sign bit, an exponent and a mantissa (fraction). Single precision uses 32 bits total, double precision 64 — the formats behind float and double in C, f32 and f64 in Rust, and every JavaScript number.
Why does 3.14 not decode back to exactly 3.14?
Most decimal fractions can't be represented exactly in binary, the same way 1/3 can't be written exactly in decimal. The value actually stored is the closest one the format can hold — turn on "Show actual stored value" to see it and the size of the gap.
What's the difference between single and double precision here?
Single precision (32 bits) has less room for the mantissa, so it rounds more numbers and loses more digits of precision. Double precision (64 bits) is exact for far more values — it is what JavaScript numbers already are internally, so round-tripping a double through this tool never loses anything.
What does byte order change?
It only affects how the same bits are grouped into bytes for reading or typing — big-endian writes the most significant byte first, little-endian last, matching how a debugger or hex dump displays memory on a particular architecture. The number itself, and the sign/exponent/mantissa breakdown, don't change.
Is my input uploaded anywhere?
No. The conversion runs entirely in your browser using the same binary read/write APIs the JavaScript engine itself relies on — nothing you type here is sent to a server.