gPdf vs iText for logistics labels

iText is excellent when the product needs a PDF SDK

iText is a mature PDF SDK. That matters. If your product manipulates existing PDFs, signs documents, fills forms, merges files, implements niche PDF workflows, or needs deep Java/.NET control over low-level PDF objects, iText is often the right level of ownership.

The product question for logistics teams is different: do you need a PDF SDK, or do you need reliable labels, invoices, receipts, and operational documents to be generated every day? For structured document generation, buying or adopting a library is only the first line item. You still build the service around it.

Same document family, different product boundary

With iText, the application owns the SDK integration. That usually means Java or .NET services, font setup, barcode configuration, PDF/A settings, deployment, monitoring, capacity planning, and an on-call path for render failures.

With gPdf, the application sends JSON or template_id + data over HTTPS. The renderer, edge deployment, bundled fonts, barcode primitives, password-protected output, metadata controls, PDF/A profiles, Factur-X/ZUGFeRD packaging, and visual design workflow are part of the service boundary.

Product fit: low-level PDF control vs generated business documents

Choose iText when the PDF layer is a core part of the product: legal-tech archives, e-signature platforms, document management systems, PDF repair/manipulation tools, or embedded Java/.NET systems that cannot call an external API.

Choose gPdf when the product is not a PDF editor. Logistics, ecommerce, ERP, fintech, ticketing, and back-office systems usually need predictable PDFs from structured data. In those cases, the best product is often not the most programmable SDK; it is the shortest reliable path from data to a finished document.

Development time: SDK implementation vs API template

A typical “from zero to a thermal label that actually scans on a Zebra ZT411” measurement:

iText path — Java; simplified, real code adds the build setup, font registration, scan-rate test harness, and a CI pipeline that runs it:

PdfWriter writer = new PdfWriter("label.pdf");
PdfDocument pdf = new PdfDocument(writer);
PageSize labelSize = new PageSize(288, 432);     // 4×6 in @ 72 dpi
Document doc = new Document(pdf, labelSize);
// Address block, sender block, carton ID, service code…
// (15–25 more lines positioning text and configuring Barcode128 with
// GS1 Application Identifiers, fonts, FNC1 framing, then a JUnit test
// that loads the PDF and validates the barcode renders at 203 dpi)
Barcode128 code = new Barcode128(pdf);
code.setCode("(01)00012345678905(21)SN12345");
code.setCodeType(Barcode128.CODE128);
// … position, sizing, human-readable interpretation line …
doc.close();

Typical first-success time (from mvn init to a label that scans cleanly): 2–5 engineering days.

gPdf path — any language; the example below is curl:

curl -X POST https://api.gpdf.com/api/v1/pdf/render \
  -H "Authorization: Bearer $GPDF_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "pages": [{
      "size": "label_4_6_in",
      "elements": [
        { "type": "text", "x": 4, "y": 12,
          "content": "Acme Distribution Centre\n1200 Logistics Pkwy\nMemphis TN 38116" },
        { "type": "barcode", "format": "gs1_128",
          "content": "(01)00012345678905(21)SN12345",
          "x": 4, "y": 60, "width": 92, "height": 22,
          "barcode_text": { "enabled": true, "position": "bottom" }
        }
      ]
    }]
  }' -o label.pdf

Typical first-success time: about 5 minutes, including reading the JSON sample and printing the PDF on the same Zebra ZT411.

The gap is not engineering talent. It is where the product boundary sits. With iText, your team builds the label service. With gPdf, the label service is the product you call.

Studio and template changes

Logistics is the rare domain where the document spec changes from outside your team. UPS revises an SSCC encoding rule. SF Express adds a check digit. FedEx publishes a new HAZMAT block layout. Whatever rendering stack you picked has to absorb the change.

With iText: a developer reads the carrier bulletin, modifies Java/.NET code, runs unit and integration tests, builds the service, deploys to staging, deploys to production, and rolls forward across regions. During the rollout window, warehouses may still print the old format.

With gPdf: edit the template JSON in code or use gPdf Studio to visually adjust the layout by adding and dragging elements. The renderer itself does not move; only the template changes. If the carrier change is in a barcode format gPdf already supports, the production integration can remain template_id + data.

Price model: license path vs infrastructure-style page pricing

The iText pricing decision is not just “library cost.” iText publishes an AGPL path and commercial licensing paths. The AGPL path can be no-cost for compatible open-source use, but it carries source-disclosure obligations. Commercial licensing releases teams from those AGPL constraints, and iText describes subscription and OEM options as quote-based or volume-based.

gPdf prices the generation service directly. The public list price starts at $5/month for 100K pages on Basic, with the same published per-page math used across the pricing page and machine-readable pricing endpoints.

For the volumes most logistics teams ask about:

The list-price column is the easy part. The harder part is everything else on the bill: license/compliance path, service runtime, HA footprint, engineering hours, regional deployment, carrier-spec maintenance, and support.

That full TCO breakdown — including engineer-month estimates by volume tier, infrastructure cost ranges, and the curve of how an SDK-based service absorbs operational cost as volume grows — lives in the long-form analysis:

→ Shipping label TCO: iText vs gPdf at 100K → 100M pages/month

Edge generation and operations cost

iText can be extremely fast in-process. The operational cost is where the renderer lives. If a warehouse in Europe calls a label service in one US region, the label render can be fast inside the JVM but still slow from the user’s point of view. Multi-region deployment fixes that, but then the team owns deployment, monitoring, capacity, and rollout in every region.

gPdf moves the generation service to Cloudflare’s edge. For label and invoice workloads, the product value is not only p50 render time; it is avoiding the need to run a PDF service beside every warehouse, carrier integration, or regional backend.

Compliance and document-quality cost

iText has deep PDF capabilities, including workflows that gPdf does not try to replace. That is exactly why iText is strong for teams that need low-level control.

For business-document generation, gPdf productizes the common output requirements: CJK fonts, vector barcodes, PDF/A profiles, Factur-X/ZUGFeRD packaging, metadata, password-protected output, and template-driven generation. The cost comparison should include how much of that your team wants to assemble and test inside its own service.

When iText is still the right answer

A comparison that pretends the competitor never wins is marketing fluff. iText remains the better pick when:

• You manipulate PDFs, not just render them. Signing, form filling, splitting, page-level edits — gPdf renders new PDFs from JSON and stays out of those workflows.
• Your stack is Java/.NET first. If the rest of your services run on the JVM and adding an outbound HTTP dependency feels like a regression, iText keeps everything in-process.
• You run air-gapped or strictly offline. Outbound HTTPS is the wrong shape for some warehouse-floor or government deployments. iText runs anywhere a JVM does.
• PDF tooling is your product. If you are a PDF vendor, an e-signature platform, or a legal-tech archive, owning the SDK is the right level of control. gPdf is built for teams whose product is logistics, invoicing, or commerce — not PDFs themselves.
• You need niche PDF spec coverage (XFA forms, advanced digital-signature handlers, attestation profiles) that gPdf does not ship.

For “I need a scannable label on a parcel and I have a million parcels a month”, gPdf is the lower-friction path. For “I need to manipulate an existing legal PDF inside my Java backend”, iText is.

Related PDF generation scenarios

Teams comparing iText and gPdf often search for Java PDF SDK alternatives, iText alternatives for invoices, shipping label PDF generation, GS1-128 PDF barcode generation, PDF/A API, Factur-X API, ZUGFeRD PDF generation, JSON to PDF API, low-code PDF template design, and edge PDF generation.

FAQ

Is iText free?

iText has an AGPL path for compatible open-source use and commercial licensing for teams that cannot or do not want to comply with AGPL obligations.

Does gPdf replace iText?

No. gPdf is a PDF generation service for structured new documents. iText remains stronger for deep PDF manipulation, signing, form filling, splitting, and low-level SDK control.

Why compare price if iText pricing is quote-based?

Because buyers still need a TCO model. The comparison should include license/compliance path, infrastructure, engineering time, support, and regional operations, not only the SDK line item.

Migration shape

For teams moving label rendering from iText to gPdf, the diff is roughly:

- // Before: a Java label-rendering service
- PdfWriter writer = new PdfWriter(out);
- PdfDocument pdf = new PdfDocument(writer);
- Document doc = new Document(pdf, new PageSize(288, 432));
- // 20–40 lines wiring fonts, positions, Barcode128 with GS1 AIs
- doc.close();
+ // After: HTTPS POST the structured DocumentRequest from any language
+ const res = await fetch('https://api.gpdf.com/api/v1/pdf/render', {
+   method: 'POST',
+   headers: { Authorization: `Bearer ${KEY}`, 'Content-Type': 'application/json' },
+   body: JSON.stringify(labelDocumentRequest),
+ });
+ const pdf = Buffer.from(await res.arrayBuffer());

Once the cut is done, the Java label service collapses to a single fetch call from whatever language already orchestrates orders. The JVM disappears from the label path; carrier-spec changes stop being a deploy event; the on-call rotation stops getting paged for label-rendering OOMs.

See also

• Shipping label TCO: iText vs gPdf at 100K → 100M pages/month — long-form cost math, engineer-months, infra ranges.
• Shipping labels use case — sample payloads, p99 numbers, Black Friday math.
• JSON Render API reference — endpoints, request shape, security model.
• GS1-128 barcodes at 0.1 mm precision in JSON — barcode geometry deep-dive.