Decimal to BCD Converter — Convert Decimal to Binary-Coded Decimal

What is a decimal to BCD converter?

A decimal to BCD converter takes a normal base-10 number and re-encodes each of its digits as a separate 4-bit binary value. That encoding is called Binary-Coded Decimal — BCD for short. Instead of converting the whole number to base 2 like pure binary would, BCD keeps the decimal digits visible: 254 becomes 0010 0101 0100, where 0010 is the digit 2, 0101 is the digit 5, and 0100 is the digit 4.

This is different from what most people mean by "convert to binary." Decimal 254 in pure binary is 11111110 — eight bits, one value. In BCD it is twelve bits, three nibbles, three digits. BCD is less efficient at packing data, but it has one decisive advantage: every decimal digit stays individually addressable. That makes it the natural encoding for anything that has to display or compute with decimal digits directly — digital clocks, seven-segment displays, financial ledgers, and the real-time clock chips buried inside almost every modern computer.

This tool converts in both directions, shows the per-digit breakdown for every value, compares BCD against pure binary side by side, and supports the two encodings that show up most often in practice — the standard 8421 code and the self-complementing Excess-3 alternative. In BCD → Decimal mode it also flags invalid nibbles — the six patterns 1010 through 1111 that a well-formed BCD stream never contains.

💡 Quick example. 42 in decimal is 0100 0010 in BCD — digit 4 becomes 0100, digit 2 becomes 0010. Packed into bytes, that is one byte: 0x42. Note that 0x42 looks like the decimal number 42 but the hex value it stores is 66 — that is exactly the packed-BCD trick: the digits of the decimal number are stored as hex digits.

The 8421 BCD table — decimal digit to 4-bit code

Every decimal digit has exactly one 4-bit BCD representation in the standard 8421 encoding. The four bit positions carry weights 8, 4, 2 and 1 from left to right, so the digit is the sum of the weights where the corresponding bit is set.

Note that for the digits 0 through 9, BCD and pure binary are identical. They only diverge once you have more than one decimal digit: the decimal number 42 in BCD is 0100 0010, but in pure binary it is 101010.

How to convert decimal to BCD

The conversion is genuinely simple — it is a lookup, not a calculation. Three steps:

1. Split the decimal number into its individual digits. 254 becomes 2, 5, 4.
2. Replace each digit with its 4-bit 8421 code. 2 → 0010, 5 → 0101, 4 → 0100.
3. Join the nibbles in the original digit order. 0010 0101 0100. That is the BCD representation of 254.

Worked example — 2025:

1. Digits: 2, 0, 2, 5.
2. BCD codes: 0010, 0000, 0010, 0101.
3. Combined: 0010 0000 0010 0101 — 16 bits, four nibbles.

Compare with pure binary: the decimal number 2025 is 11111101001 (11 bits). BCD uses five more bits for exactly the same value. That is the price of per-digit readability.

Packed BCD vs unpacked BCD

BCD has two common storage layouts, and it matters which one you mean when you say "the BCD value of 42".

• Unpacked BCD — each decimal digit occupies a full byte. Only the low nibble carries the digit; the high nibble is usually zero (or set to 1111 in the extended form used by EBCDIC). Decimal 42 in unpacked BCD is two bytes: 0000 0100 and 0000 0010.
• Packed BCD — two decimal digits share one byte. The more-significant digit sits in the high nibble, the less-significant in the low nibble. Decimal 42 in packed BCD is one byte: 0100 0010, written as 0x42.

Packed BCD is what you meet in most real systems: COBOL's COMP-3 packed-decimal format, IBM's packed-decimal instructions, the DS1307 real-time clock chip, and the values this tool emits when you choose the Packed hex output format. The rule of thumb is: if the number of decimal digits is odd, packed BCD pads the leading nibble with zero to fill the byte.

💡 Why "0x42" for decimal 42? The packed representation is not a hex value that happens to be 42 — it is the hex digits 4 and 2 stitched into one byte. When you read packed BCD, you read each nibble as a decimal digit, not as a hex value that contributes to a single number. That is the whole point of the encoding: the byte 0x42 visually contains 4 and 2.

Byte boundaries and odd digit counts

Packing works cleanly when a decimal number has an even number of digits. When the digit count is odd, there is one leftover nibble that cannot pair with another, so systems pad it. There are two conventions in practice:

This tool uses the leading-zero convention because it preserves the numeric value without ambiguity: 0x07 obviously means decimal 7, while 0x70 means decimal 70. When the "padded 0x0 for byte fill" pill appears on a result, that is what happened. If you need trailing-zero padding — as some embedded protocols do — you can pad manually by appending a 0 to your input first.

Invalid BCD codes — the six that never occur

A 4-bit nibble has 16 possible states, but BCD only uses 10 of them. The six patterns 1010, 1011, 1100, 1101, 1110 and 1111 — the binary values 10 to 15, or hex A to F — are never valid digits in a standard 8421 BCD stream.

If you see one of these nibbles in a stream that is supposed to be BCD, something is wrong — a data corruption, a wrong-format assumption, or a stream that is actually pure binary. This tool flags every invalid nibble it encounters in BCD → Decimal mode so you can pinpoint where the encoding breaks.

Excess-3 (XS-3) — the self-complementing alternative

Excess-3, sometimes called XS-3 or Stibitz code, is a variant of BCD in which every digit's code is shifted by 3. The decimal digit 0 is encoded as 0011 (three), 1 as 0100 (four), all the way up to 9 as 1100 (twelve). The rule is: take the 8421 BCD code and add 3.

Why bother? XS-3 is self-complementing. Because the code for each digit is exactly three above its value, the 9's complement of a decimal digit can be obtained by inverting every bit — the same trick as 1's complement in binary. That makes decimal subtraction hardware dramatically simpler, which is why XS-3 appeared in early decimal computers and handheld calculators of the 1970s.

This converter supports XS-3 as an alternative encoding alongside 8421, so you can compare the two nibbles side by side in the per-digit breakdown table. In the step table, the "Bit positions (8·4·2·1)" column always shows which bit positions are set — a fixed geometric view of the nibble — while the "8421" and "Excess-3" columns show the resulting codes so you can compare.

BCD addition and the +6 correction

Arithmetic on BCD is not the same as arithmetic on pure binary — there is a correction step. To add two BCD digits, add them as ordinary binary first, then check the result:

• If the binary sum is between 0 and 9 (0000–1001), it is a valid BCD digit — no correction needed.
• If the binary sum is between 10 and 15 (1010–1111), it is an invalid BCD code — add 6 (0110) to wrap it back into range and produce a carry-out of 1.
• If the binary sum generated a carry out of bit 4, the result is also invalid — apply the same +6 correction.

Worked example — 7 + 5 in BCD:

1. 0111 + 0101 = 1100 (binary sum = 12).
2. 1100 is invalid BCD (it is 1010–1111), so add 0110.
3. 1100 + 0110 = 1 0010.
4. Result: 0010 with a carry-out of 1 — decimal 12. Correct.

This is why BCD arithmetic units are more complex than binary adders — every digit position needs its own correction comparator and a 4-bit adder for the +6 step. This tool only converts representation; it does not perform BCD arithmetic — but knowing the +6 rule helps when you are debugging a device that is producing unexpected BCD results.

Where BCD is used — real applications

• Digital clocks and watches. A clock display shows hours, minutes and seconds as separate decimal numbers. Storing the time as BCD means each digit drives one display segment directly — no arithmetic conversion needed between the counter and the display.
• Real-time clock chips. The DS1307, DS3231 and most other I²C real-time clock ICs store the date and time in BCD. Reading the seconds register gives you two nibbles: the tens-of-seconds digit and the ones-of-seconds digit. The value 0x42 in that register means 42 seconds — not the binary number 66.
• Seven-segment displays. Every digit of a seven-segment display is driven by a BCD decoder chip (like the classic 7447 or the CD4056). Feed it a 4-bit BCD nibble and it lights the segments for that digit.
• Financial and accounting systems. Money is decimal — one hundred cents to the dollar, and results must be exact. Pure binary floating-point cannot represent 0.10 exactly, which causes rounding errors that compound over many transactions. BCD (and its modern successor, IEEE 754-2019 decimal floating-point) avoids that entirely.
• COBOL packed decimal (COMP-3). Enterprise mainframe databases store monetary fields in packed decimal — two digits per byte, with the last nibble reserved for the sign. When you access one of these fields from a modern system you must unpack it from BCD.
• Taxi meters, petrol pumps, and industrial instruments. Any device that displays a decimal value to the user tends to use BCD internally so the display path stays trivial.
• Legacy BIOS date storage. The real-mode BIOS date functions used to return the date packed into two bytes as BCD (0x25 for the month 25, for example).

BCD vs pure binary — when each is right

The choice between BCD and pure binary is a trade-off between storage density and decimal precision. Pure binary is about 20% more compact but cannot represent decimal fractions exactly; BCD is less compact but decimal arithmetic on it is exact.

Use BCD when: the digits need to be individually addressable, the value will be displayed as decimal digits, decimal arithmetic must be exact, or you are interfacing with hardware that expects BCD. Use pure binary when: raw numeric magnitude is all that matters, storage is tight, and the value will not be shown as separate decimal digits.

Common mistakes when converting decimal to BCD

• Confusing BCD with pure binary. They are identical for 0–9 but completely different for 10 and above. Decimal 45 in binary is 101101; in BCD it is 0100 0101. If your output only has one 1 followed by more bits, you probably converted to binary by mistake.
• Using hex A–F in BCD digits. A valid BCD nibble only ever has the decimal values 0–9. Writing the nibble 1010 to mean "ten" in a BCD context is wrong — it is an invalid code that a decoder will reject.
• Forgetting to pad odd-length packed BCD. If you have three decimal digits — say 254 — packed BCD needs an even number of nibbles to fill bytes. The leading nibble is padded with 0000: 0000 0010 0101 0100, four nibbles / two bytes. See the "Byte boundaries" section above for the two padding conventions.
• Reading packed BCD as hex. The byte 0x42 in packed BCD means decimal 42, not decimal 66. The two nibbles are decimal digits, not hex-value contributors.
• Assuming all 4-bit patterns are BCD. Only 10 of the 16 nibbles are valid. If you convert a random byte to "BCD" you will hit 1010–1111 roughly 37% of the time.
• Using BCD to store negative numbers without a sign convention. BCD is unsigned. To store negatives you must reserve a nibble for the sign, and there is no single universal convention — different systems use different sign nibbles. COBOL COMP-3 uses 0x0C for +, 0x0D for −, and 0x0F for unsigned.
• Expecting BCD arithmetic to be as fast as binary. Adding two BCD nibbles and getting a correct decimal result requires a correction step — if the binary sum of a nibble exceeds 9, you must add 6 (0110) to fix it. See the "BCD addition" section above.

Privacy and data storage

Everything runs in your browser. The conversion, the per-digit breakdown, the BCD-vs-binary comparison, the batch processing and the reference table filter all happen locally in JavaScript. Nothing you type is uploaded to a server. There is no account, no login and no network request after the page has loaded — the tool works offline once the page is cached. Your input is not stored anywhere; refreshing the page clears it.

Limitations

• The converter handles the two most common encodings — standard 8421 BCD and Excess-3 (XS-3). It does not implement the other variants (2421, 5421, biquinary) that appear in some textbooks.
• Negative numbers and sign nibbles are not supported. A decimal value must be non-negative (or unsigned), and a BCD stream must not contain sign nibbles. COBOL COMP-3 sign-nibble decoding is out of scope.
• Only one decimal point is allowed, and only when it separates integer digits from fractional digits. BCD does not have a native decimal-point representation — the tool keeps the point visible so the value remains unambiguous, but does not encode it as a nibble.
• Batch conversion is line-based. Each non-empty line is treated as one value. Multi-line values are not supported — join them before pasting.
• The reference table covers single-digit codes 0–9. Multi-digit conversions are what the tool itself does; the table is only the base lookup.
• The tool does not perform BCD arithmetic. It converts representation only — you cannot add or subtract two BCD values with it. The "+6 correction" section explains the algorithm if you want to implement it yourself.

Decimal to BCD — frequently asked questions

Related tools on AIToolsPros