A structurally valid USPS barcode can still encode garbage — validating IMb from the bars

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 USPS spec (USPS-B-3200) defines the pipeline roughly like this:

1. The tracking + routing fields pack into a single large integer via positional arithmetic (the routing code contributes up to ~10^11 of the space — this is effectively base conversion with mixed radixes).
2. An 11-bit frame check sequence (CRC) is computed over that integer's byte representation.
3. The integer is converted into ten 3-digit codewords (more base conversion).
4. Each codeword maps to a 13-bit constant-weight character — every valid character has exactly five bits set (weight 5) or two bits set (weight 2, selected by one FCS bit); the remaining FCS bits flip specific character bits.
5. The 130 character bits interleave onto the 65 bars (each bar's ascender/descender halves come from different characters).

So validation has levels:

• Level 0 — geometry: 65 bars, valid states. Catches print defects, nothing else.
• Level 1 — character validity: de-interleave the bars and check that every 13-bit character is in 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 that got truncated upstream, a library that silently handles 130-bit arithmetic
wrong. All of those produce beautiful, scannable, wrong barcodes.

A few implementation notes for anyone building this:

• You need exact big-integer arithmetic (the payload exceeds 64 bits — 10^11 × the tracking fields). 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 against barcodes from encoders you trust, then — the fun part — against deliberately corrupted ones. A validator that never fails anything is just a mirror. (My rule for the whole product: anything the tool can't actually determine gets reported "not evaluable" — never silently passed.)

I ship this as part of Preflight, a document-QC tool for print/mail — the free analyzer detects
IMbs and validates structure in the browser: https://preflightdocs.com/tools/imb-barcode-validator?utm_source=devto&utm_medium=article&utm_campaign=imb
The full FCS round-trip and field decode run in the USPS module. But the algorithm above is all
public spec (USPS-B-3200) — if you maintain mail software, you can build Level 2 yourself, and
you probably should.