Binary-to-decimal conversion explains how whole numbers live in memory, but most real-world values — prices, measurements, physics simulations — are decimals, not integers. This guide looks at what happens one layer deeper: how a fractional number like 3.14 is actually packed into bits, and why that packing occasionally produces surprising rounding behavior.
Beyond whole-number conversion
Quick answerConverting an integer like 42 into binary, octal, or hex is a clean, exact operation — every whole number has an exact finite representation in any base. Fractional (decimal) values are a different story: most of them can't be written exactly in binary, no matter how many digits you allow, which is where floating-point representation comes in.
ToolPico's first guide on number base conversion covers the mechanics of converting whole numbers between bases — the division/multiplication method that a number base converter automates for binary, octal, decimal, hexadecimal, and any base from 2 to 36. That guide (and the tool's "Advanced settings") also touches on converting a decimal fractional part by repeatedly multiplying by the target base. This article takes a different angle: it looks specifically at how a computer stores a fractional value like 3.14 internally, using the IEEE 754 floating-point standard, and why that storage format is the root cause of certain rounding surprises programmers run into.
Key fact: IEEE 754 is the near-universal standard defining how "float" and "double" values are laid out in binary across virtually all modern programming languages and processors.
Three fields: sign, exponent, mantissa
Quick answerA floating-point number packs three separate binary fields into one fixed-width value: 1 sign bit, a block of exponent bits (which scale the number by a power of 2, after removing a fixed bias), and a block of mantissa bits (which hold the actual significant digits of the value).
For the common 32-bit "single precision" format, that's 1 sign bit + 8 exponent bits + 23 mantissa bits = 32 bits total. The 64-bit "double precision" format most languages use by default for ordinary decimal numbers extends this to 1 + 11 + 52 = 64 bits, trading a wider layout for far greater precision.
Illustrative example (not a live calculation): imagine breaking down a hypothetical 32-bit float. A conceptual "IEEE 754 float" mini-tool — not something this converter builds today, but a natural companion to bit-level tools like the "Bit Click" tab already on the
Number Base Converter — would take a decimal input such as 3.14, show its sign bit (0, since it's positive), its 8-bit biased exponent, and its 23-bit mantissa, side by side, the same way the existing bit grid shows two's complement for integers today.
The exponent field uses a fixed offset called a bias (127 for single precision, 1023 for double) so the stored exponent bits are always non-negative — the true exponent is recovered by subtracting the bias back out after reading the bits.
Bit layout at a glance (illustrative)
Field widths for common IEEE 754 formats — reference only, not tied to a specific tool output
| Format | Sign | Exponent | Mantissa |
|---|
| Single precision (32-bit) | 1 bit | 8 bits | 23 bits |
| Double precision (64-bit) | 1 bit | 11 bits | 52 bits |
Why 0.1 + 0.2 isn't exactly 0.3
Quick answer0.1 and 0.2 are both repeating (infinite) fractions in binary, the same way 1/3 repeats forever in decimal. Because a float only has a limited number of mantissa bits, each value gets rounded to the closest representable approximation — so adding the two approximations together produces a tiny error that becomes visible as something like 0.30000000000000004.
This isn't a bug in any particular language — it's a direct consequence of the sign/exponent/mantissa layout having a finite number of bits to represent an infinite decimal expansion. The same underlying idea appears in the base-conversion guide's note on decimal fractions: some fractions are infinite (repeating) once you switch bases, whether you're converting decimal to binary by hand or letting a converter calculate it to a chosen number of digits.
Hypothetical scenario: imagine a checkout script that adds up item prices as floating-point dollars and compares the total to an expected value using a strict equality check. Because of the same rounding behavior described above, that comparison can silently fail even when the totals are "the same" to any human looking at the printed numbers — a classic reason experienced developers compare floats with a small tolerance instead of exact equality, or work in integer cents instead.
Where this shows up in practice
Floating-point bit layout rarely needs to be inspected directly, but a few situations make it worth understanding conceptually:
Debugging unexpected values like NaN (not-a-number) or Infinity, which have specific, recognizable bit patterns in the exponent and mantissa fields rather than being arbitrary. Comparing serialized data across two systems or languages that might disagree on precision. And simply building intuition for why financial or scientific code so often avoids raw floating-point math for exact totals, preferring integer-based or decimal-specific arithmetic instead.
None of this changes how integer base conversion works — that part remains exact, as covered in the base-conversion guide. It's specifically the fractional, real-number side of computing where the sign/exponent/mantissa structure becomes relevant, and where a future companion "float breakdown" view alongside the existing bit-grid tool could make the concept visible rather than abstract.
Explore whole-number base conversion instantly
Binary, octal, decimal, hex, or any base from 2 to 36 — step-by-step working, bit grouping, two's complement, and text/Base64 conversion, all free and in your browser.
Try the free Number Base Converter →
Frequently asked questions
Why does 0.1 + 0.2 not equal 0.3 exactly in most programming languages?
Because 0.1 and 0.2 cannot be represented exactly in binary floating-point, the same way 1/3 cannot be written exactly in decimal. The IEEE 754 format stores the closest representable binary approximation of each value, so tiny rounding differences appear once the numbers are added, producing something like 0.30000000000000004 instead of an exact 0.3.
What are the sign, exponent, and mantissa in a floating-point number?
A floating-point number is stored as three binary fields packed into a fixed width: 1 sign bit (0 for positive, 1 for negative), a group of exponent bits that (after subtracting a fixed bias) scale the value up or down by powers of 2, and the remaining mantissa (or significand) bits that hold the actual precision digits. A standard 32-bit single-precision float uses 1 sign bit, 8 exponent bits, and 23 mantissa bits.
Is a floating-point number the same thing as converting decimal to binary?
They're related but not identical. Converting a decimal integer to binary just re-expresses the same exact value using powers of 2. A floating-point number additionally has to represent a fractional part and an exponent within a fixed number of bits, which is why it uses a packed sign/exponent/mantissa layout instead of a plain binary string — and why it can only approximate most decimal fractions rather than store them exactly.
What is exponent bias in IEEE 754, in simple terms?
Exponent bias is a fixed offset (127 for 32-bit single precision, 1023 for 64-bit double precision) added to the true exponent before it's stored, so that the stored exponent field is always a non-negative binary number. To recover the real exponent, you subtract the bias back out. This trick lets hardware compare two floats' magnitudes by comparing their bit patterns almost like plain integers.
Why would a developer ever need to look at a float's raw bits?
Debugging numeric edge cases (NaN, infinity, subnormal numbers, or unexpected rounding), verifying serialization/deserialization across languages, and understanding precision limits before comparing floats for equality are all situations where seeing the actual sign/exponent/mantissa bit pattern behind a decimal value clears up confusion that stepping through source code alone doesn't.
Related guides
A note on this guide: the bit-width figures and examples above describe the IEEE 754 standard as commonly implemented; they are for educational purposes and are not a substitute for consulting your language's exact numeric documentation (edge cases like subnormal numbers and rounding modes can vary by platform). This article is informational, not engineering advice.