A barcode that prints crisply in your office printer and scans cleanly in your office tests can fail at a 3PL’s thermal printer 5,000 miles away, and you’ll never see the failure mode in any test environment. The bug doesn’t show up in CI, doesn’t fail QA in Adobe Acrobat, and looks pristine on a 4K monitor. It quietly costs supply-chain teams $0.25 per unit at Amazon’s FBA inbound, $5–10 per non-compliant carton at Walmart, and occasionally entire pallets refused at the receiving dock. The bug is that the barcode in the PDF is a picture of a barcode, not actual barcode drawing instructions. By the time the picture has been resized through the print pipeline, the bars no longer have the precision a scanner needs.

This article is for three audiences. Anyone can read the first section and know what’s at stake and what to ask their PDF vendor. QA and operations leads will want the second section on how the print-quality grade collapses. Engineers will want the third section on what’s actually inside the PDF and how to verify any file in three minutes. Each layer ends with a clean takeaway, so you can stop wherever you have what you need.

In one table

Question	If your barcode is drawing instructions (vector)	If your barcode is a picture (raster PNG)
Size in the PDF	~1 KB	~50–300 KB
Survives resizing for any printer	Yes — printer redraws from math	No — every resize loses sharpness
ISO 15416 print-quality grade	Stays at A	Drops from A to C/D in production
Walmart SSCC-18 chargeback risk	Low	High
Amazon FBA $0.25-per-unit relabel	Rare	Routine on bad templates
Effort to switch	Choose a renderer that emits paths	Engineering project

If your team is evaluating a PDF generation service for any workflow that ends in a scan, the most diagnostic question is the row this table is built on: does it produce drawing instructions, or a picture? The rest of this article is the long version of that question.

For everyone: what actually happens, and what it costs

Story 1 — The Walmart pallet that nobody could read

A supplier’s product manager signs off on a new shipping-label template. It looks great in Adobe Acrobat. It prints fine on the office printer. The first load — fifty pallets, two hundred cartons — rolls out to a Walmart distribution centre.

At the receiving dock, the lumper team (the contracted unloaders) scans each pallet’s SSCC-18 — the 18-digit serial number that uniquely identifies that physical pallet. Three pallets out of fifty don’t read on the first or second scan pass. The lumper team escalates to the receiving lead. The lead pulls up the EDI 856 ASN — the electronic manifest the supplier sent ahead, listing every SSCC that should be on this load. The WMS can see that three SSCCs from the manifest are now physically present but unreadable. That’s a discrepancy.

What follows isn’t dramatic; it’s procedural. An EDI 824 application advice fires back to the supplier flagging the load. Receiving has to manually key in the unreadable SSCCs from the human-readable text below the barcode. The load slips its receiving slot. A compliance chargeback under “labelling violation” hits the supplier’s account: in 2026 most major retailers charge $5–10 per non-compliant carton, sometimes per pallet. For this load, that’s $30–60 of direct cost — a rounding error.

The real cost is the next part. Repeated labelling violations move the supplier to buyer review status, which slows future POs through tighter compliance audits and pushes them to less-favoured routing tiers. A handful of bad pallets per quarter doesn’t trigger this; a systematic problem from a misconfigured PDF stack does, because the same template ships every load.

The post-mortem on that supplier’s engineering side often takes weeks because nobody on the team thinks of “the barcode in the PDF” as a thing that has any meaningful internal structure. They think of it as just the barcode. The discovery — that the PDF contained a 300 dpi PNG bitmap, which the thermal printer at the DC had to resample to 203 dpi, smearing the bar widths past tolerance — usually arrives only after the first chargeback summary forces a deeper look.

Story 2 — The Amazon FBA shipment with the slow-bleed chargeback

This one is quieter, larger, and harder to spot.

A Fulfilled-by-Amazon seller ships 50,000 units of a SKU into FBA inbound. Each unit has a label with an FNSKU (Amazon’s per-SKU identifier) printed as a barcode. On a typical bad template, 2–5 % of units arrive with unscannable barcodes at the FBA warehouse — bars too smeared for the inbound scan to read on the first attempt. Amazon does not refuse the shipment. They route the affected units to manual relabelling and charge the seller a fixed fee per relabel. As of 2026 that fee is $0.25 per unit.

For one 50K-unit shipment with a 5 % failure rate, that’s $625 in direct chargebacks. For a seller doing this every month, that’s $7,500/year of pure waste — and that’s only the explicit chargeback line. The bigger hidden cost: relabelled units take longer to receive into FBA, so they’re not available for the buy box, so promotional traffic slips, so revenue dips at exactly the wrong moment in the launch cycle.

Sellers often discover this only when they go digging through Amazon Seller Central’s FBA inbound defect & reimbursement report. Until then, the line item gets written off as “Amazon weirdness”. The actual root cause — a barcode generator that emits a 300 dpi PNG instead of a vector barcode — is months upstream and rarely connected to the chargeback report by anyone other than someone who has done this investigation before.

Story 3 — The carrier exception line at UPS / FedEx

This third case has no direct chargeback, which is precisely why it’s the most invisible.

When a parcel hits a UPS or FedEx sorting facility, the conveyor scanner reads the carrier tracking barcode in milliseconds. If the read fails — bars smeared past tolerance, quiet zone cropped, modulation grade D — the parcel doesn’t get rejected. It gets pulled off the main belt and routed to the exception-handling line, where a human types the tracking number from the human-readable text. The parcel re-enters the network with a 12–24 hour delay.

Carriers don’t typically chargeback for this directly. The cost surfaces elsewhere:

Customer service tickets spike with “you said it shipped, where is it?”
Customer NPS slides on shipments that were genuinely on time, just routed through manual.
Carrier account audits over time flag the supplier as a labelling concern. Future pickups get scrutinised, contract renewals get tougher, rate negotiations get worse.

A single bad parcel costs nothing measurable. Ten thousand bad parcels a month over a year cost a relationship.

The thread that runs through all three

In every story, the bug isn’t in the data, the design, the printer, or the scanner. It’s in one upstream choice: the barcode arrived at the printer as a picture, not as drawing instructions. Pictures don’t survive being resized for unfamiliar printers. Drawing instructions do.

Why this is so common

The hard part isn’t producing a vector barcode in isolation — modern barcode libraries can emit precise SVG output. The hard part is embedding that vector barcode into a PDF as native PDF path operators instead of as an embedded image. Translating SVG paths into PDF path operators requires the PDF generator and the barcode engine to be co-designed. The shortcut — call a barcode library, take its PNG output, embed the PNG as an Image XObject — is enormously easier to wire up at the framework level. So most PDF stacks take it. From the warehouse’s perspective, that one architectural shortcut is what arrives on the thermal printer and earns the chargeback.

That’s the layperson takeaway. If you stop reading here, you have enough to ask any PDF vendor the right question and to ask your engineering team to run the three-minute verification at the bottom of this article.

For QA and ops leads: how the grade actually collapses

The standards your warehouse scanner already uses

Two ISO standards define what “good barcode” means at a receiving dock:

ISO/IEC 15416 — for 1D linear codes (Code 128, GS1-128, ITF-14, EAN, UPC).
ISO/IEC 15415 — for 2D matrix codes (QR, DataMatrix, PDF417, Aztec).

A laboratory verifier measures seven parameters across the printed symbol and reports a single overall grade from A (4.0) down to F (0.0). The ANSI scale is the same thing in different letters. Vendor manuals from Walmart, Amazon, Target, Costco, and the major carriers all reference these standards and typically require grade C or better. Below C is treated as out-of-spec; below D triggers the chargeback machinery you read about above.

The seven parameters and what raster barcodes do to each:

Parameter	What the verifier checks	Why a raster PNG hurts it
Decodability	Are bar widths within spec tolerance?	Resampling shifts widths off-spec — usually the first parameter to drop
Edge contrast	Sharp bar/space transitions?	Anti-aliasing during resize creates grey transition pixels
Modulation	Uniform light/dark contrast across the symbol?	Print-driver dithering turns solid bars into dot patterns
Defects	Any spurious specks or voids?	Resample artefacts become real ink dots on the label
Min reflectance	Are bars dark enough?	Resampling can leave internal voids in narrow bars
Symbol contrast	Overall bar-vs-background contrast?	Lossy PDF compression flattens contrast
Quiet zone	Required white margin around the symbol?	Auto-cropping tools eat into it

A vector barcode keeps every parameter near A because there’s no source pixel grid to resample. A raster barcode usually loses half a grade per parameter; stack five or six of those and the average lands at C or D. The data is identical. The encoding is identical. The barcode looks identical on screen. Only the printed symbol differs — and the verifier (and the warehouse scanner) measures the printed symbol, not what your QA team sees in Acrobat.

Why printers compound the damage

A raster PNG embedded in a PDF passes through six resampling stages between “click Print” and “label exits the printer”. Each one costs roughly half a grade.

Viewer rasterises for screen. Acrobat / your PDF reader interpolates the source PNG onto your monitor’s pixel grid. Looks fine — that’s what fools QA.
Print driver rasterises for paper. The driver picks bilinear or bicubic interpolation to fit the source pixels onto the printer’s grid. Edge contrast collapses.
Colour conversion. Pipelines that pass through CMYK or grayscale conversion apply another resample, often combined with halftone dithering. Modulation collapses.
“Fit to printable area”. Many drivers default to 99 % page scaling to dodge edge clipping. Decodability drifts a fraction of a grade.
PDF/A flattening. Archival-PDF conversion often re-rasterises any region containing transparency. Another half-grade gone.
Thermal head smear. Ribbon and direct-thermal media smear by 2–4 mil under heat. Vector renderers compensate; raster sources can’t.

Stack the costs and a barcode that left the renderer at grade A reaches the scanner at grade C–D. That’s the operational arithmetic. Vector path operators skip stages 2–4 entirely, because there’s no source pixel grid to resample — the printer’s own rasteriser computes bars at native DPI from a mathematical specification.

If you’re a QA lead and you stop reading here, the action item is one ISO 15416 verifier rental ($1–2K/week, vendors like Cognex, Keyence, REA VeriCube). Sample fifty production labels from your highest-volume retailer flow. If the average grade is below B, you have a raster-barcode problem.

For engineers: what’s actually inside the PDF

Two ways a barcode can sit on a page

PDF defines exactly two kinds of visible object:

A path — a list of drawing operators (re rectangle, f fill, m/l move/line, S stroke) at floating-point coordinates. The printer’s own rasteriser evaluates these at the device’s native resolution.
An Image XObject — an embedded bitmap with width/height in pixels, encoded as PNG / JPEG / raw stream. The renderer must map the source pixel grid onto the device pixel grid, which always requires resampling.

A vector Code 128 with 60 bars produces ~60 re/f pairs in the content stream — under 1 KB total. The float coordinates are accurate to 0.001 mm. A raster Code 128 produces a single Do /Im0 operator pointing at an embedded PNG, typically 270 KB at 300 dpi.

% Vector — what the renderer should produce
0 0 0.40 22 re f       % bar 1: 0.40mm wide, 22mm tall
0.99 0 0.40 22 re f    % bar 2 ...
1.97 0 0.40 22 re f    % ~60 lines like this, ~1 KB total

% Raster — what most stacks actually produce
348 0 0 84 0 0 cm      % scale a 348×84 pixel image to 92mm × 22mm
/Im0 Do                % insert the embedded PNG (~270 KB)

Vector keeps the original specification all the way to the printer. Raster freezes the bars at the source DPI and forces every downstream printer to guess.

Verifying any PDF in 3 minutes

Three checks, no special tools beyond poppler-utils and qpdf (free on every Linux/Mac/WSL):

1. Zoom to 800 %. Vector barcodes stay crisp at any zoom. Raster pixelates dramatically — you can count the source pixels. Fastest informal check.

2. List embedded images:

$ pdfimages -list shipping-label.pdf
page  num  type    width  height color comp bpc enc      object  x-ppi  size
─────────────────────────────────────────────────────────────────────────────
   1    0  image     348      84  gray    1   1 ccitt     8 0     300   270K

If you see a row that matches your barcode’s aspect ratio (say 348 × 84 for a wide 1D code, or square for a 2D), the barcode is a raster image. Vector barcodes don’t appear in this output at all.

3. Inspect the content stream:

$ qpdf --qdf shipping-label.pdf - | grep -A2 -B2 ' re$'

A vector Code 128 with 60 bars produces a dense cluster of re/f operators. If you see one Do /Im0 operator with no nearby rectangles where the barcode should be, it’s a raster image.

A pro-grade verifier (Cognex, Keyence, REA VeriCube) runs $5K+ and gives you the formal ISO 15416 report. Most teams don’t get there until after a chargeback already triggered the investigation; the three checks above tell you which side of the problem you’re on for free.

What gPdf does

gPdf’s barcode rendering comes from xBarcode, a sister product built by the same team. xBarcode is a Rust barcode engine — fully self-developed, not a wrapper around a third-party library — that the gPdf renderer calls directly. For matrix and linear symbologies — Code 128, GS1-128, QR, Data Matrix, PDF417, Aztec, ITF, EAN, UPC and most of the other 30+ supported formats — xBarcode computes the bar/cell pattern and gPdf emits it into the PDF content stream as re/f rectangle operators at float coordinates. No intermediate PNG, no source DPI, no raster surface.

Two consequences worth flagging:

The engine is publicly verifiable. xBarcode also runs as an independent free online tool at xbarcode.ai. Anyone can paste a payload, download the SVG / PNG / EPS, and inspect the path output before assuming anything about what gPdf produces. The path output is what lands in your gPdf PDFs. That’s the credibility check that “we emit vector barcodes” claims usually don’t survive.
Performance is measurable. xBarcode generates a standard 1D code in ~4 µs on a single core (v1.5.4) — the published benchmarks put it at 6× faster than fast_qr and 30× faster than rxing. End-to-end through gPdf’s Cloudflare Workers runtime, that translates to ~30 ms p50 worldwide.

Beyond the path output, xBarcode handles the GS1 layer that most third-party barcode libraries skip entirely: a registry of 750+ Application Identifiers with strict / lenient validation modes, automatic FNC1 separator insertion, and per-AI length and character-set checks. Your (01)09504000059101(17)260315 element string gets validated against the spec before encoding, not after a chargeback.

PDF/A-1b through 4 are compatible by construction; no flattener pass needed. Determinism is exact: the same DocumentRequest produces byte-identical content streams across isolates and releases.

When raster might still be acceptable

Two real cases:

Internal-only documents that don’t need to scan reliably. Raster doesn’t matter — but neither does it save anything, since vector is also free.
A photographic logo with a barcode locked into the artwork for marketing reasons. Scan reliability becomes conscious technical debt, not an oversight.

For everything else — shipping labels, FNSKU labels, payslips, invoice line-item barcodes, voucher PDFs, ticket QR codes, retail trade-item labels, pharmaceutical serialisation — vector is the only choice that doesn’t ship a print-pipeline gamble downstream.

Bottom line

When you choose a PDF stack for any workflow that ends in a scan, the question to ask isn’t “does it support QR / Code 128 / GS1-128”. It’s:

When I ask for a barcode, is the result drawing instructions or an embedded picture?

If the answer is picture, your scan-failure rate has a floor that no amount of X-dimension calibration, font-substitution care, or printer maintenance can lower. The Walmart chargebacks, the Amazon $0.25 line items, the carrier exception delays — they’re not vendor problems or warehouse problems. They’re a property of the bytes leaving your renderer.

The cheapest action today is pdfimages -list against your last 100 outbound label PDFs. Count the rows that come back with a barcode-shaped image object. Treat that count as the size of an unannounced compliance audit waiting to happen.

Vector vs raster barcodes in PDFs: the chargeback you don't see coming