gPdf render/edge
Use case · Logistics & shipping

Shipping label PDFs at carrier-grade scale

Render 4×6 thermal shipping labels with vector GS1-128 barcodes, ITF-14 carton codes and SSCC-18 pallet IDs. Edge rendering keeps p99 under 15 ms, even under Black Friday spikes.

Job to be done

Render carrier-ready 4×6 thermal shipping labels — including vector GS1-128, ITF-14 and SSCC-18 barcodes — directly from order JSON, without spinning up a headless browser per request. Output must scan reliably at 203 dpi on Zebra/SATO/Honeywell printers and stay under 15 ms p99 during peak retail spikes.

Why gPdf for this

  • Vector Code 128, QR, DataMatrix, PDF417 and GS1-128 / ITF-14 / SSCC-18 — sub-pixel-accurate at 203 dpi, 300 dpi and 600 dpi.
  • 0.1 mm coordinate precision — meets carrier overall-length tolerance for human-readable interpretation lines.
  • Page size `label_4_6_in` (and `label_4_8_in`, `label_a6`) ships pre-configured for the dominant thermal-printer formats.
  • Determinism — same order JSON renders to byte-identical PDF, so reprints in the warehouse never produce a 'different' label.
  • Edge rendering — p50 3 ms, p99 8 ms, even when 50K labels print in the same minute at carrier pickup.
  • Stateless: the label exists in memory for ~4 ms in a Cloudflare Worker isolate, then is freed. No document store, no carrier-data leakage surface.

Sample request

POST /api/v1/pdf/render — minimal 4×6 thermal label with a Code 128 carrier-tracking barcode.

{
  "pages": [{
    "size": "label_4_6_in",
    "elements": [
      {
        "type": "text",
        "x": 4, "y": 6,
        "content": "SHIP TO",
        "style": { "font_size": 8, "font_family": "NotoSans-Regular" }
      },
      {
        "type": "text",
        "x": 4, "y": 12,
        "content": "Acme Distribution Centre\n1200 Logistics Pkwy\nMemphis TN 38116",
        "style": { "font_size": 11, "font_family": "NotoSans-Regular" }
      },
      {
        "type": "barcode",
        "format": "code128",
        "content": "1Z999AA10123456784",
        "x": 4, "y": 60,
        "width": 92, "height": 22,
        "barcode_text": { "enabled": true, "position": "bottom" }
      }
    ]
  }]
}

Compliance and conformance

  • GS1 General Specifications — module width (X-dimension), quiet zone and overall length match GS1 Section 5.4 tolerances at 203 dpi.
  • Carrier mandates — UPS, FedEx, DHL and USPS accept the rendered output as scannable; no per-carrier post-processing required.
  • PDF/A-2b available for archival via `settings.profile = "pdfa-2b"` if you need to keep the label PDF for tax/audit reasons.

The shipping-label workload, in one paragraph

Every order produces one PDF, every PDF gets printed once on a thermal printer, and the failure mode if you’re slow is not “page loads slowly” — it’s “the warehouse pickup is queued behind your label-rendering API.” Shipping is a job where p99 latency is the product metric, where deterministic output matters because reprints are routine, and where barcode quality — measured in GS1 X-dimension tolerances, not pixels — decides whether your scanners pick up the label on the first pass.

Headless-browser-based PDF stacks struggle with all three at once: the cold-start cost compounds under spike, raster barcodes degrade on small thermal labels, and font rasterisation drifts between Chromium versions, so “byte-identical reprint” is impossible.

Why gPdf fits

A 4×6 thermal label is small (576 × 864 pixels at 203 dpi), low-element-count (text blocks + 1-2 barcodes + an optional carrier logo), and high-volume (a mid-size 3PL renders 50K-500K per day). That’s the workload gPdf is built for. The renderer:

  1. Compiles the layout once — page coordinates, font cascades and barcode geometry are resolved at request time, not via a browser layout engine.
  2. Vectorises every barcode — modules drawn directly into the PDF stream so a 30 mm-wide GS1-128 reads cleanly at 203 dpi or 600 dpi without any DPI-aware rasterisation logic on your end.
  3. Embeds NotoSans CJK + Latin — the same payload renders a Chinese carrier-name correctly without you provisioning fonts on a render container.

p99 is a flat 8 ms across our reference workload (1K invocations of the sample above on EU-WEST), regardless of whether a single isolate has rendered one label or 10K labels.

Volume + cost math

A typical mid-size 3PL operates around 50K labels/day = ~1.5M/month. On the Basic plan ($5/month for 100K pages, $0.00005 per page overage) that’s:

1.5M pages × $0.00005       = $75.00 in overage
+ Basic plan base            =   $5.00
─────────────────────────────────────
total                         = $80.00 / month

Same workload on Puppeteer-on-Lambda runs in the $200-400/month range at typical Lambda concurrency settings, before you account for cold-start tax during peak.

Black Friday: a worked example

Peak spike is the workload where edge rendering pays its rent most clearly. A retail customer hitting 200% of normal label volume in the first hour of Black Friday — say 100K labels in 60 minutes, 1.7K labels/minute average with 5K/minute peak bursts — completes inside a single Cloudflare Workers region pool with no cold-start tax. The same workload on a Puppeteer warm pool sized to average traffic produces 1.5-2.5 s cold-starts on the burst-spawned containers, and your warehouse pickup desk feels every one of them.

Where to look next

Keep reading