How is a PDF SDK priced?

A PDF SDK is typically priced on one of five models, often in combination:

1. Per developer (per seat) — You pay for each developer who builds against the SDK. It’s simple to reason about and scales with team size, not usage.
2. Per application — One license covers one app or product, regardless of how many developers or end users it has.
3. Per platform — Web, iOS, Android, and server are each priced separately; costs multiply as you ship on more platforms, and the headline price is for one platform only.
4. Usage- or volume-based — You pay per document processed, per API call, or per credit. This model is common for cloud/API products: predictable per unit, but variable month to month.
5. Perpetual vs. subscription — A perpetual license is paid once (often with a yearly maintenance fee for updates), while a subscription is billed annually and lapses if you stop paying. Most modern SDKs have moved to annual subscriptions.

Most commercial vendors don’t publish list prices and route you to a sales quote, because the final number depends on the components you license, your platforms, and your volume.

Commercial vs. open source PDF SDK licensing

The licensing model determines your legal obligations, not just your bill.

The AGPL copyleft trap

Several popular “free” PDF libraries (iText is the best-known example) are dual-licensed: AGPLv3 for free use, or a paid commercial license. AGPLv3 is a strong copyleft license, and its network clause is the catch: If users interact with your application over a network — which describes most web apps and SaaS products — using the AGPL edition can require you to make the complete source code of your calling application available to those users. Some AGPL editions also require keeping the library’s producer metadata in every generated file.

For a commercial product, that’s usually a non-starter, so teams end up on the paid commercial tier anyway. The practical lesson: “Free” is only free if you can meet the copyleft obligations. Always check whether a free tier is permissive (MIT/Apache) or copyleft (GPL/AGPL) before you build on it.

What actually drives the cost

The entry price is rarely the real cost. The variables that move TCO the most:

• Platforms — Per-platform pricing means web + iOS + Android + server can be 3–4× the headline figure.
• Components — Capabilities like OCR, Office to PDF, HTML to PDF, digital signatures, and data extraction are often licensed as separate components rather than bundled in one base SDK. This is normal and can be efficient — you pay only for what you deploy — but the cost risk is not realizing a capability is licensed separately until you start scoping. Confirm what’s in the base vs. added so you compare like for like.
• Setup/onboarding fees — Some vendors charge a required one-time fee on top of the subscription.
• Distribution/runtime royalties — A few licenses charge based on the number of deployed copies or end users, which can dominate cost at scale.
• Support tier — Service-level agreements (SLAs), dedicated support, and security questionnaires are often gated behind higher tiers.
• Telemetry — Volume/capacity licenses may require streaming usage data to the vendor to count processed documents; this can be a problem for air-gapped or privacy-sensitive deployments, where offline licensing matters.

How to compare PDF SDK pricing (a TCO framework)

Because list prices are scarce and models differ, compare on total cost of ownership over roughly three years, not entry price. A practical checklist:

1. List the capabilities you’ll actually deploy — Viewer, annotations, forms, signatures, OCR, conversion, and AI. Map which are base vs. paid add-ons in each quote.
2. Count your platforms — And ask whether pricing is per platform or unified across client, server, and cloud.
3. Model your volume — For usage-based options, estimate documents/API calls per month at launch and at scale.
4. Ask about all fees — Setup, support tier, renewal uplift, and any distribution royalties.
5. Check the license type — Commercial, permissive, or copyleft (AGPL). Confirm whether your source must be disclosed.
6. Confirm deployment constraints — Self-hosted vs. cloud, air-gapped/offline licensing, data residency, and telemetry.
7. Normalize the quotes — Get every vendor to a three-year, all-in number for the same capability set and platforms.

Where vendors publish verifiable data — for example, independent PDF SDK benchmarks or head-to-head comparison pages — use it to verify claims before you get to pricing.

How Nutrient prices

For transparency, here’s Nutrient’s model. The Nutrient PDF SDK uses component-based pricing: Viewer is the foundation for client-side SDKs, and you license the components you actually ship on top of it — annotations, forms, digital signatures, OCR, redaction, document comparison, and so on. Server SDKs (.NET, Java, Python, and Node.js) and Document Engine follow the same model — you license only what your code calls, with no separate core tier. Licenses are annual or multiyear subscriptions scoped to the components, platforms, and deployment model you use — client-side, on-premises (including fully air-gapped), or cloud — with no copyleft obligations. OEM (unlimited deployment, no per-customer overhead) and per-usage models are available for SaaS products. A 30-day trial with full features is available, no card required. Talk to a solutions engineer to get a quote.

Nutrient’s four DWS cloud APIs — Processor, Viewer, Data Extraction, and Accessibility — are usage-based with publicly listed self-serve plans. A free tier is available (watermarked output, no card required). Paid plans (Starter and Growth) are billed monthly by credits or sessions, with a 10 percent discount for annual billing. High-volume custom plans are available for teams processing more than 10,000 credits per month. See plans and pricing.

Conclusion

PDF SDK pricing comes down to two questions: how you’re charged (the pricing model), and what rights you get (the licensing model). The sticker price rarely tells the story — per-platform multiplication, separately licensed components, setup and royalty fees, telemetry requirements, and the AGPL copyleft trap are what actually move the total. Decide the capabilities and platforms you’ll ship, confirm the license type, and normalize every vendor to a three-year total cost of ownership for the same scope. To put that into practice, work through the PDF SDK buyer’s guide, check Nutrient’s pricing, and talk to a solutions engineer for a quote scoped to your architecture.

Frequently asked questions

Explore related topics