Engineering · 2026-07-05
A structurally valid USPS barcode can still encode garbage
Validating Intelligent Mail barcodes from the bars — why “it scans” proves almost nothing, and how the USPS-B-3200 FCS round-trip catches encoder bugs nothing else does.
Every piece of US commercial mail carries an Intelligent Mail barcode — 65 vertical bars, each in one of four states (full, ascender, descender, tracker). Encoded inside: a barcode ID, service type, mailer ID, serial number, and the delivery-point routing code. If it’s wrong, mail gets misrouted, automation discounts evaporate, and assessments follow.
Here’s the part that surprised me when I built a validator: most “IMb checks” only verify that the bars look like an IMb. Sixty-five bars, four valid states each, plausible geometry — pass. But the encoding pipeline between your data and those bars is long, and a bug anywhere in it produces a barcode that is structurally perfect and semantically garbage.
The pipeline (USPS-B-3200)
- The tracking + routing fields pack into a single large integer via positional arithmetic — the routing code contributes ~1011 of the space; this is effectively base conversion with mixed radixes.
- An 11-bit frame check sequence (CRC) is computed over that integer’s byte representation.
- The integer converts into ten 3-digit codewords (more base conversion).
- Each codeword maps to a 13-bit constant-weight character — weight 5, or weight 2 selected by one FCS bit; the remaining FCS bits flip specific character bits.
- The 130 character bits interleave onto the 65 bars — each bar’s ascender and descender halves come from different characters.
Three levels of validation
Level 0 — geometry. 65 bars, valid states. Catches print defects, nothing else.
Level 1 — character validity. De-interleave the bars and check every 13-bit character against the constant-weight codebook. Catches some corruption; still passes many encoder bugs.
Level 2 — the FCS round-trip. Reverse the whole pipeline — characters → codewords → the big integer (undoing the base conversion) — recompute the 11-bit CRC from the recovered payload, and compare it against the FCS bits actually embedded in the characters. A mismatch proves the barcode was produced by a broken encoder, even though every bar and every character looks valid.
Level 2 is the one that catches real production incidents: an off-by-one in codeword packing, a routing code truncated upstream, a library that silently mishandles 130-bit arithmetic. All of those produce beautiful, scannable, wrong barcodes.
Implementation notes
- You need exact big-integer arithmetic — the payload exceeds 64 bits, and any float contamination anywhere corrupts the round-trip.
- The reverse base conversion is the fiddly part: the spec is written encode-forward, so the decode is “run the multiplications backwards as divisions and prove you get clean remainders.”
- Test against the spec’s published example vectors first, then encoders you trust, then — the fun part — deliberately corrupted barcodes. A validator that never fails anything is just a mirror.
That last point is the design rule behind the whole product this ships in: anything the tool can’t actually determine is reported “not evaluable” — never silently passed.