BCD (Binary-Coded Decimal) Converter

What Binary-Coded Decimal is

Binary-Coded Decimal (BCD) stores each decimal digit in its own 4-bit group called a nibble, using the standard 8-4-2-1 weighting. Rather than converting a whole number to pure binary, BCD keeps the decimal digits separate, which makes it easy to drive seven-segment displays and to perform exact decimal arithmetic in clocks, calculators, and financial hardware.

How BCD encoding and decoding work

To encode, each decimal digit d (0–9) maps directly to its 4-bit binary value. The number 2026 becomes four nibbles:

2    0    2    6
0010 0000 0010 0110

To decode, the input bits are split into groups of four from the right. Each group is read with weights 8, 4, 2, 1 to recover one decimal digit. Any nibble whose value lands between 1010 (10) and 1111 (15) is invalid BCD, because those codes do not correspond to a single decimal digit, and the decoder reports the error instead of guessing.

Tips and notes

When decoding, make sure the bit string length is a multiple of four; the tool pads short groups on the left so you can spot a malformed input quickly. The packed view shown here places two digits per byte, which is the most common hardware layout. If you need unpacked BCD, simply prefix each nibble with a fill nibble such as 0000 or 1111 depending on your platform’s convention.

Why BCD exists alongside pure binary

You might wonder why anyone would use BCD when binary is more compact. The answer is in the hardware context where BCD was designed. Digital clocks and watches need to drive individual digit displays: a 7-segment decoder takes a 4-bit BCD nibble directly and lights the correct segments for 0 through 9. If the time were stored as pure binary, you would need to convert — an extra step requiring division by 10, which is expensive in simple logic gates. BCD removes that step entirely.

Financial and scientific instruments also benefit because BCD avoids the decimal rounding errors that arise when binary fractions cannot represent decimal fractions exactly. The number 0.1 cannot be stored precisely in binary floating point, but BCD stores it as 0000 0001 — exact, and no rounding accumulates over thousands of calculations.

The full BCD code table

The six remaining nibble patterns — 1010 through 1111 — are pseudo-tetrades: they never appear in valid 8-4-2-1 BCD data, which is exactly what lets a decoder detect corruption that pure binary would silently accept.

BCD arithmetic and the add-6 correction

Adding two BCD digits with a normal binary adder can produce an invalid nibble or a wrong carry, because a nibble overflows at 16 while decimal digits overflow at 10. The classic fix is the add-6 correction: whenever a nibble result exceeds 9 (or produces a half-carry), add 0110 (6) to push the result past the six unused codes and generate the correct decimal carry.

Example: 7 + 5 in BCD is 0111 + 0101 = 1100 (12 — invalid). Adding 0110 gives 1 0010, i.e. carry 1 and digit 2 — the correct decimal answer, 12. x86 processors expose this as the DAA (decimal adjust after addition) instruction, and 6502/Z80-era CPUs had a dedicated decimal mode — a reminder of how common BCD arithmetic was in early commercial computing.

Practical gotchas when handling BCD data

• Sign nibbles in packed decimal. Mainframe packed-decimal appends a sign nibble as the last nibble: conventionally C (1100) for +, D (1101) for −, and F (1111) for unsigned. A trailing C/D/F in a hex dump of financial data is a sign, not corruption.
• Digit order vs byte order. BCD is written most-significant digit first within the string, but multi-byte BCD fields in file formats can still be little-endian at the byte level. Decode the byte order first, then the nibbles.
• Odd digit counts. Packing an odd number of digits leaves half a byte; the convention (leading zero nibble vs trailing sign) differs by format — check the spec rather than assuming.
• BCD is not Gray code or Excess-3. Other 4-bit decimal codes exist (Excess-3 adds 3 to every digit; Gray code changes one bit between neighbours). A stream that looks like “BCD with impossible nibbles” may simply be a different decimal code.

Packed versus unpacked: when each is used

Packed BCD stores two decimal digits per byte and is the most compact form. It is used in mainframe-era EBCDIC systems, some ISO standards for date encoding (such as the YYMMDD fields in certain card data formats), and instrumentation firmware where storage was precious.

Unpacked BCD devotes a full byte per digit with the upper nibble set to a filler value. ASCII digit encoding is actually a form of unpacked BCD: the digits '0' through '9' have the values 0x30 through 0x39, which is 0011 0000 through 0011 1001. If you mask off the upper nibble (& 0x0F) you get the decimal digit directly — a reason BCD and ASCII digit arithmetic interact cleanly in low-level code.

Sources and references

• IBM z/Architecture — Decimal (packed decimal) data format — the canonical packed-BCD layout used in mainframe and COBOL systems
• ASCII / Unicode C0 Controls and Basic Latin (digits U+0030–U+0039) — the digit code points that make ASCII a form of unpacked BCD

Maintained by the Gera Tools editorial team. The 8-4-2-1 nibble weighting and the invalid 1010–1111 range are defined by the BCD standard; encoding/decoding runs entirely in your browser. Last reviewed 2026-07-02.