Four representations of the same number — hex, decimal, binary and packed BCD. Edit any box and the other three update live. Everything runs on big integers, so 12-digit amounts and 8-byte fields never lose precision.
C for positive, D for negative and F for unsigned; decoding treats A/C/E/F as positive and B/D as negative. An odd digit count is padded with a leading 0 nibble to fill whole bytes. Use a minus sign for negatives in the decimal, hex and binary boxes.Packed decimal squeezes each decimal digit into 4 bits — one nibble — so a byte holds two digits: 1234 is stored as 0x12 0x34, and the bytes read exactly like the number itself, which is the easiest way to spot it in a hex dump. Compare that with ASCII, where every digit takes a whole byte (1234 becomes 31 32 33 34): BCD cuts the space in half.
That is why mainframe clearing files use it everywhere. Batch files run to millions of records, and storing amounts, PANs and dates as BCD halves both the file size and the transfer time. It also maps one-to-one onto COBOL COMP-3 (packed decimal) fields, so mainframe programs can do decimal arithmetic on it directly, no conversion step. When an ISO 8583 message is BCD-encoded, an n12 field like the DE4 amount packs into 6 bytes — same mechanism.
Signed packed decimal puts the sign in the last nibble (the low half of the final byte); everything before it is digits. The IBM convention:
| Sign nibble | Meaning | Notes |
|---|---|---|
0xC | Positive | The standard encoding for positive values (credit) |
0xD | Negative | The standard encoding for negative values (debit) |
0xF | Unsigned (treated as positive) | What unsigned fields use — a COBOL PIC 9 COMP-3 (no S) looks like this |
0xA, 0xE | Positive | Accept when decoding; never produce when encoding |
0xB | Negative | Accept when decoding; never produce when encoding |
The rule of thumb: encode only C / D / F; decode A, C, E and F as positive, B and D as negative. The tool's three modes cover the three shapes you actually meet: digits-only BCD with no sign nibble (ISO 8583 amount fields), signed COMP-3 ending in C/D, and unsigned COMP-3 ending in F.
Encoding 1234 as signed packed decimal, step by step:
1, 2, 3, 4 — four digits plus one sign nibble makes five, an odd count that won't fill whole bytes.0: now 0, 1, 2, 3, 4 plus the sign — six nibbles, exactly 3 bytes.C. Lay them out: 0 1 | 2 3 | 4 C.0x01 0x23 0x4C.Verify it backwards: reading 01 23 4C, the last nibble is C (positive), the remaining nibbles are 0 1 2 3 4, and dropping the leading zero gives 1234. For -1234 only the last nibble changes to D: 0x01 0x23 0x4D. Run those through the tool above and compare.
A note on amounts: ISO 8583 amount fields carry an integer in the currency's minor unit (USD 1234.56 travels as 123456), and where the decimal point sits depends on the currency's exponent. This tool only converts the integer between representations. For the exponent lookup and the conversion rules, see why amounts have no decimal point and the currency codes and exponents lookup.
Padding on the wrong side (0x0C vs 0xC0). The 0 that fills an odd digit count always goes at the front; the sign nibble always sits last. Encode 5 as 0xC5 (sign in the high nibble) or pad at the tail, and every digit shifts one nibble — and it will often still "decode" to a plausible-looking wrong value, which makes this one brutal to spot by eye.
Reading F as the digit 15. The trailing F of unsigned BCD is a sign filler, not a digit. 123F means 123, whereas a generic hex-to-decimal converter reads the whole thing as 0x123F = 4671 — which is exactly why BCD fields can't be fed through ordinary base conversion.
Confusing zoned decimal with packed decimal. Zoned decimal (COBOL DISPLAY) stores one digit per byte with a zone nibble of F in the high half — in EBCDIC, F1 F2 F3 is the characters 123 — and the sign overlays the high nibble of the last byte. Packed is two digits per byte. Apply the packed layout to a zoned field and your lengths are off by a factor of two.
Mismatched odd-digit padding. If the sender pads odd digit counts with a leading 0 and the receiver slices by the raw digit count (or vice versa), every nibble after the pad shifts. When a decoded BCD field looks "off by one position everywhere", check that both sides agree on the digit count and the padding rule first.