About

Binary-Coded Decimal (BCD) encodes each decimal digit of a number into a fixed 4-bit binary nibble. Unlike pure binary, BCD preserves decimal digit boundaries, which matters in financial systems, embedded controllers, and legacy mainframe protocols (IBM System/360 used packed BCD natively). Misinterpreting packed vs. unpacked format corrupts data silently - a 0xF padding nibble read as a digit produces garbage. This tool converts ASCII character codes into their BCD representations (both packed and unpacked) and reverses the process. It assumes standard printable ASCII range (0x20 - 0x7E). Note: BCD only represents decimal digits 0 - 9, so each ASCII code is first decomposed into its constituent decimal digits before encoding.

Packed BCD stores two digits per byte, halving storage compared to unpacked format, but requires careful handling of odd-length digit strings (this tool pads with 0xF as per IBM convention). Unpacked BCD zeros the upper nibble of each byte, wasting space but simplifying per-digit access. This tool approximates standard BCD encoding conventions and does not handle sign nibbles (0xC/0xD) used in COBOL signed fields.

Formulas

BCD encoding decomposes each ASCII character's decimal code into individual digits, then maps each digit to a 4-bit nibble.

For a character with ASCII code c, extract the decimal digits:

digits = decimalDigits(c)

Unpacked BCD: each digit d_i maps to one byte:

byte_i = 0000 d_i (binary), i.e., upper nibble = 0x0, lower nibble = d_i

Packed BCD: pair digits into bytes:

byte_j = (d_2j << 4) | d_2j+1

If the total digit count is odd, the final nibble is padded with 0xF:

byte_last = (d_n << 4) | 0xF

Where c = ASCII character code (decimal), d_i = the i-th decimal digit of c, 0xF = padding nibble (1111 binary) per IBM packed decimal convention, and << = bitwise left shift operator.

Reference Data

ASCII Char	Decimal Code	Hex Code	Decimal Digits	Unpacked BCD (Hex)	Packed BCD (Hex)
0	48	0x30	4, 8	04 08	48
1	49	0x31	4, 9	04 09	49
9	57	0x39	5, 7	05 07	57
A	65	0x41	6, 5	06 05	65
B	66	0x42	6, 6	06 06	66
Z	90	0x5A	9, 0	09 00	90
a	97	0x61	9, 7	09 07	97
z	122	0x7A	1, 2, 2	01 02 02	12 2F
Space	32	0x20	3, 2	03 02	32
!	33	0x21	3, 3	03 03	33
+	43	0x2B	4, 3	04 03	43
.	46	0x2E	4, 6	04 06	46
/	47	0x2F	4, 7	04 07	47
@	64	0x40	6, 4	06 04	64
[	91	0x5B	9, 1	09 01	91
~	126	0x7E	1, 2, 6	01 02 06	12 6F
{	123	0x7B	1, 2, 3	01 02 03	12 3F
}	125	0x7D	1, 2, 5	01 02 05	12 5F
%	37	0x25	3, 7	03 07	37
#	35	0x23	3, 5	03 05	35

Frequently Asked Questions

Unpacked BCD stores one decimal digit per byte - the upper nibble is always 0x0 and the lower nibble holds the digit value (0 - 9). This wastes 4 bits per digit but allows direct byte-level digit access. Packed BCD stores two digits per byte (first digit in upper nibble, second in lower nibble), halving storage. However, odd digit counts require a padding nibble, typically 0xF. IBM mainframes (COBOL, PL/I) use packed BCD extensively for decimal arithmetic.

BCD is a decimal encoding - it can only represent digits 0 - 9 in each nibble. ASCII character "A" has decimal code 65, which is not a single digit. The converter splits 65 into digits 6 and 5, then encodes each as a BCD nibble. This is the standard approach for encoding arbitrary numeric values in BCD format. Characters with codes above 99 (e.g., "z" = 122) produce three BCD digits.

When a packed BCD digit sequence has an odd number of digits, the last byte only has one meaningful digit in the upper nibble. The lower nibble is filled with 0xF (1111 binary) to indicate padding. This is the IBM convention. Some systems use 0x0 padding instead. This tool follows the 0xF convention. When decoding packed BCD back to ASCII, 0xF nibbles are stripped as padding.

Technically yes - any integer can be decomposed into decimal digits and BCD-encoded. However, this tool restricts input to printable ASCII (0x20 - 0x7E, codes 32 - 126) to avoid ambiguity with control characters. Control characters (codes 0 - 31) have no visual representation and their BCD encoding, while valid, is rarely useful outside specific protocol implementations.

This is a real challenge. ASCII code 65 produces BCD digits [6, 5], but so would two separate characters with codes 6 and 5 (if they existed in printable range). The reversal uses a delimiter-aware approach: each character's BCD digit group is separated by a space in the output. During BCD-to-ASCII conversion, you must provide the hex bytes with proper spacing per character group. The tool parses space-delimited byte groups to reconstruct each original character code.

No. EBCDIC is a different character encoding used on IBM mainframes with a completely different code page mapping. Signed packed BCD (used in COBOL COMP-3 fields) uses the final nibble as a sign indicator (0xC = positive, 0xD = negative, 0xF = unsigned). This tool treats 0xF strictly as padding, not as a sign. For signed BCD conversion, additional logic for sign nibble interpretation is required.