Storing decimal digits directly, one nibble each
Binary-coded decimal takes a fundamentally different approach from ordinary binary integer storage. Instead of converting a whole number into a single binary value (the way a normal integer is stored, where 1234 becomes one 11-bit binary pattern), packed BCD stores each decimal digit in its own 4-bit nibble: 1234 becomes four separate nibbles, 0001, 0010, 0011, 0100, one per digit, concatenated together. Written in hex, that packed representation looks identical to the decimal digits themselves —0x1234 — which is what makes the hex-to-BCD relationship on this page different from every other conversion on this site: the hex representation and the decimal value share the same digit sequence, just interpreted through a different lens.
Why store numbers this way at all
Ordinary binary integers are more compact and faster for a CPU's native arithmetic, so BCD isn't used for general-purpose computation. Its advantage is exactness for decimal fractions specifically. A value like 0.1 has no exact representation in binary floating-point — it's an infinitely repeating binary fraction, silently rounded to the nearest representable value — which is a real, well-documented source of rounding error in financial and scientific calculations that require exact decimal arithmetic. BCD sidesteps that problem entirely by never converting to binary in the first place: each decimal digit is stored and manipulated as itself, so a value like 0.10 remains exactly 0.10 rather than an approximation.
Where BCD is actually used
Older financial and point-of-sale systems, some embedded systems (digital clocks and simple calculators often compute directly in BCD since they're already displaying decimal digits on a seven-segment display), and certain database and mainframe "packed decimal" storage formats use BCD specifically to guarantee exact decimal arithmetic without the binary-floating-point rounding problem. Some processors, including x86 historically, included dedicated BCD arithmetic instructions (like adjust-after-addition opcodes) for exactly this use case, though these are rarely used in modern software, which more often reaches for an arbitrary-precision or fixed-point decimal library instead when exact decimal arithmetic is required.
Why A through F are invalid in BCD
Because each nibble represents one decimal digit, only the values 0 through 9 are valid — a nibble pattern representing 10 through 15 (which would render as a hex A through F) has no defined meaning in BCD and signals invalid or corrupted data if encountered. That's a useful integrity check in practice: a byte stream that's supposed to be packed BCD but contains any nibble with a value of 10 or higher is either not actually BCD, or has been corrupted, since a correctly-generated BCD value can never produce those nibble patterns.
A worked example
Take the decimal value 9999. In packed BCD, each digit becomes its own nibble: 9 is 1001, repeated four times, giving the packed byte sequence 1001 1001 1001 1001, or0x9999 in hex — visually identical to the decimal number itself, which is the entire point. Compare that to how 9999 would be stored as an ordinary binary integer: 10011100001111, a 14-bit pattern with no visual resemblance to the decimal digits at all, needing to be converted back through positional arithmetic to recover the original digits. BCD trades that compactness away specifically so the digit-level structure stays visible and lossless.
BCD is not the same as Hex ↔ Decimal
It's worth being clear about what distinguishes this tool from the site's mainHex ↔ Decimal converter, since both accept decimal input and produce hex output. The main converter treats the input as an ordinary integer and re-expresses it in base 16 — 1000 becomes0x3E8, using positional weighted-sum arithmetic, and the hex digits bear no resemblance to the original decimal digits. This tool instead packs the decimal digits directly into hex nibbles without any base conversion at all — 1000 becomes 0x1000, not 0x3E8 — because packed BCD isn't reinterpreting the number in a new base, it's storing the same digits in a different physical layout. Confusing the two produces a value that's numerically nonsensical in the intended context, so it's worth checking which behavior a given format or system actually expects before assuming one or the other.
Packed versus unpacked BCD
This tool implements packed BCD, which fits two decimal digits into each byte (one per nibble) — the form generally meant when "BCD" is mentioned without qualification, and the more storage-efficient of the two common variants. An alternative, unpacked BCD, uses one full byte per decimal digit (with the upper nibble typically zeroed or used for a sign flag), trading storage density for simpler processing in specific legacy hardware or software contexts. Both encode the same underlying idea — one decimal digit, one fixed-width unit of storage — differing only in how tightly digits are packed together.