Label Formats Measured: 9 Carrier APIs Compared

Why label format is a DX problem, not a formatting footnote

Ask five integration engineers "what format does the label API return?" and you'll get five different wrong assumptions. Some assume PDF is universal. Some assume ZPL means native thermal output. Almost nobody checks default size until a Dymo prints blank or a Zebra spits out a label with three inches of dead space. This is a carrier API label format problem, and it's been under-documented across the industry.

The clearest public example sits in an EasyPost GitHub issue from 2018, still relevant because the underlying conversion behavior hasn't changed: a developer reported that 4x6" PNG labels are resized to 11.5x8" when converted to PDFs using the label conversion API, and no documentation was found for how to specify output label dimensions. That's not a cosmetic bug. That's a production label that no longer fits the sticker stock, triggering returns, re-prints, and support tickets. This happens because teams treat "convert to PDF" as a lossless operation instead of what it actually is: a re-render with its own default canvas size.

Method: what we checked and what we didn't

Every row in the table below traces to vendor-published developer documentation, pulled directly between late September and October 6, 2026. No figure is estimated, interpolated, or reconstructed from third-party plugins unless explicitly marked. Where a vendor's own docs didn't state a format or size, we wrote "Not published" rather than guess.

This benchmark does not cover:

• Actual visual rendering quality or print sharpness on physical thermal printers
• DPI fidelity testing on hardware (that's a hardware test, not a docs audit)
• GLS, DPD, and InPost, whose label formats we've already covered in prior posts on this blog
• Customs document formats (commercial invoices, CN22/CN23), which is a separate topic entirely

The label format matrix: 9 providers compared

The table covers native carrier/direct APIs (UPS, FedEx, DHL eCommerce Americas, DHL Freight) alongside multi-carrier platforms (ShipEngine, Shippo, EasyPost, Sendcloud, ShippyPro) plus Cargoson as a multi-carrier reference point.

Note on ShippyPro: we could not locate a public API reference with the same granularity as the other eight vendors as of October 6, 2026. Rather than estimate, that row stays marked "Not published." If you have a current ShippyPro API doc link with format specifics, we'd genuinely like to see it for a follow-up.

Where "supports ZPL" doesn't mean what you think

"Native ZPL" and "ZPL" are not the same claim, and vendors are inconsistent about flagging the difference. Sendcloud is the most transparent of the nine here, stating plainly that for carriers that do not support native ZPL, Sendcloud converts PDF labels to ZPL using a carrier-approved internal conversion process. Compare that to UPS or DHL eCommerce Americas, where ZPL output is generated directly by the carrier's own label engine with no PDF intermediary — a materially different reliability profile.

Resolution is the second trap. Most ZPL label generation defaults to 203 DPI, but DHL Freight's Print API explicitly offers PDF (Base64 format), ZPL (for 203 DPI label printers), ZPL300 (for 300 DPI label printers), ZPL600 (for 600 DPI label printers). Send a ZPL600 payload to a 203 DPI Zebra and you get a misprint, not an error — the printer will attempt to render it and the barcode will likely come out unscannable.

FedEx's thermal/laser split is the classic support-ticket generator. The format field and the stock type field have to agree, and they frequently don't in third-party plugin configs. FedEx's docs are explicit that ImageType is required to format the thermal label for the printer you use, with valid values EPL2 or ZPLII, while labels printed with a laser printer are generated in PDF format and do not need to be scaled or resized. Mix the two — request PDF with a thermal stock type, or ZPL with a paper stock type — and FedEx will either reject the request or render something unusable.

Default size traps

Size defaults vary not just by vendor but by format within the same vendor, which is the part most integration docs bury. EasyPost's own support article lists this explicitly: PDF: 8.5x11, EPL: 4x5, ZPL: 4x5, PNG: 4x6. That means switching a single config flag from PNG to PDF — with no other change — silently triples your canvas size. The same support article flags that UPS results in a 4x7 if you don't override, but if you desire to print 4x6 it only works on ZPL unless you reach out to Support to enable 4x6 for PNG, and that over-specifying 4x7 or 4x8 just returns a 4x6 with 1 or 2 inches of blank space.

FedEx's own docs list seven possible label sizes including "4x6" (default), "8.5x11", "4X8", "4x9", "7X4.75", "8.5X11_BOTTOM_HALF_LABEL", "8.5X11_TOP_HALF_LABEL", but a 2024 GitHub pull request from the MASQ-Group integration project documents what happens when the format and stock type parameters are requested together without a matching preset: FedEx renders that as a 4×6 label in the corner of a US Letter page when PDF is paired with 4x6 stock type without the correct combination.

The integration risk is structural, not accidental: a payload that works in sandbox at 4x6 PNG can silently render at 8.5x11 in production the moment someone omits the size parameter, because the vendor's fallback default kicks in instead of throwing an error.

What this means for multi-carrier platform selection

Platform breadth varies a lot once you look past the marketing copy. EasyPost and Shippo expose the most granular per-carrier size and format combinations, down to carrier-specific tokens like 4×6 inch PDF (102 x 153 mm, token PDF_4x6) for Shippo. Sendcloud and (as far as publicly documented) ShippyPro abstract most of this down to a practical default of PDF, with ZPL and PNG as derived options. Cargoson's carrier-specific documentation pages — covering connections like DHL Freight HR, DHL Express NL, and DHL Global Forwarding IT — consistently list the same trio of PDF, PNG, ZPL across different carrier integrations, though the pages don't break out which of those are native to the underlying carrier versus converted by the platform.

If you're evaluating a multi-carrier platform like nShift, Descartes, MercuryGate, or Cargoson against a direct carrier integration, don't accept "we support ZPL" as a complete answer. Ask for the native-versus-converted breakdown per carrier, and ask what DPI the ZPL output targets by default. That single question would have prevented the EasyPost PDF-resize bug and the FedEx stock-type mismatch documented above.

Open questions and follow-ups

• We did not test actual print output or DPI fidelity on physical thermal hardware. That's a natural candidate for a future Setup Diary or Bugwatch post with a real printer rig.
• GLS, DPD, and InPost were excluded here because we've already covered their PDF-only label behavior in earlier posts, and repeating that data would add nothing new.
• ShippyPro's native-versus-converted breakdown remains unverified from public docs as of this writing. If that changes, we'll update this table.
• Non-EU/US regional carriers beyond the nine covered here remain "Not published" pending direct sandbox access — we won't guess at formats we haven't pulled from primary sources.

If your team is choosing between a direct carrier integration and a multi-carrier API, pull the label format section of the vendor's docs before you pull the rates section. It's a five-minute read that saves a week of thermal-printer support tickets.