Most teams can't open the file that prints their statements — parsing AFP in the browser

Preflight — Thu, 09 Jul 2026 20:14:48 +0000

AFP — Advanced Function Presentation — predates the web. It came out of IBM in the 1980s, moves to production printers over IPDS, and still composes a huge share of the world's bank statements, insurance documents, and healthcare EOBs. If you work anywhere near transactional print, AFP files flow through your systems daily.

And yet: ask a team to answer "is this AFP batch structurally sane?" and watch what happens. The tooling that can even open the format is enterprise software — licensed per seat, installed somewhere specific, owned by another department. The format's documentation (MO:DCA — Mixed Object Document Content Architecture) is public via the AFP Consortium, but public and approachable are different things. Most vendors in this space sell conversion — AFP in, PDF out. Almost nobody just tells you whether the file is well-formed.

The format is friendlier than its reputation

An AFP file is a flat sequence of structured fields. Every field starts with a 0x5A carriage-control byte, then a two-byte big-endian length, a three-byte identifier (SFID), a flag byte, two reserved bytes, and payload. That's the whole framing story. No cross-references to resolve, no compression dictionary to bootstrap — you can walk an AFP file with a while loop.

Structure comes from Begin/End pairs. BDT…EDT wraps the document; BPG…EPG wraps each page; groups, presentation-text objects, and overlays nest inside in last-opened-first-closed order. Names inside the fields are EBCDIC — code page 500, another small museum piece — and resource references (fonts via MCF, overlays via IPO, page segments via IPS) are eight-character EBCDIC names pointing at objects that live outside the file, in a resource library on the production system.

What a structural validator can honestly check

Our free validator does four things, all derivable from the bytes alone:

Framing — every field opens with 0x5A, declares an in-bounds length, and the stream ends exactly at a field boundary. Truncation is the classic transfer failure; FTP in ASCII mode has ruined more AFP files than any parser bug.
Begin/End nesting — a plain stack.
The document envelope — exactly one BDT…EDT, pages nested inside.
Inventory — every structured field with its name, byte offset, and length, plus the page count and every referenced resource name.

Just as important is what it refuses to do. An SFID we don't recognize is reported as unknown — counted, located, flagged as a warning — not guessed at. Whether a referenced font or overlay actually exists in your resource library is not knowable from the file, so we say exactly that instead of implying it was verified. (My rule for the whole product: anything the tool can't actually determine is reported "not evaluable" — never silently passed.)

Why client-side was the whole point

AFP files are statements and EOBs — they carry names, addresses, account numbers, health information. The reason "just upload it to a converter site" never became the norm in this industry is that nobody responsible for that data should be uploading it anywhere casually. So the validator runs entirely in the browser: the parser is compiled into the page, the file is read locally, and there is no upload endpoint behind it. Parsing a structured-field stream is cheap — a multi-hundred-page statement run inventories in milliseconds on a laptop — and the file never touches a network.

Try it (free, no signup, there's a 20-second demo on the page): https://preflightdocs.com/tools/afp-validator?utm_source=devto&utm_medium=article&utm_campaign=afp

The MO:DCA reference is public via the AFP Consortium — if your team fights this format, the structural walk above is entirely buildable from spec, and honestly, more people should.

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

Preflight — Thu, 09 Jul 2026 20:14:42 +0000

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:

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).
An 11-bit frame check sequence (CRC) is computed over that integer's byte representation.
The integer is converted into ten 3-digit codewords (more base conversion).
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.
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.

DEV Community: Preflight

Most teams can't open the file that prints their statements — parsing AFP in the browser

The format is friendlier than its reputation

What a structural validator can honestly check

Why client-side was the whole point

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