The one-line difference
iText (now part of Apryse) is a heavyweight Java/.NET PDF SDK — drawing model, low-level object access, ironclad compliance, and enterprise pricing. makesPDF is a hosted REST API: you POST markdown or a compact DSL string and get a PDF/A-2A + PDF/UA-1 compliant PDF back. Same compliance bar, very different developer surface, and dramatically lower friction for teams that don't need an SDK.
Feature matrix
| iText / Apryse | makesPDF | |
|---|---|---|
| Shape | Java / .NET SDK | Hosted REST API (/api/v1/*) |
| Authoring surface | Imperative API (Document.add(new Paragraph(...))) |
Markdown, builder DSL, JSON |
| Runtime | Your JVM / .NET process | Cloudflare Workers (we host) |
| Compliance | PDF/A-1/2/3, PDF/UA, PDF/X — full coverage | PDF/A-2A + PDF/UA-1 |
| veraPDF-validated | Yes | Yes |
| Markdown input | No | Yes (POST /api/v1/md) |
| Low-level PDF object access | Yes (full SDK) | No (rendered output only) |
| Agent-first | No | Yes — skill file, MCP, x402 |
| First-party CLI | No | Yes (@makespdf/cli) |
| License | AGPL-3.0 (community) / Commercial (enterprise) | Proprietary hosted; skill file MIT |
| Pricing | Enterprise contract, often 5–6 figures | Per-render credits + x402 wallet |
Same input, two outputs
A "Hello, Ada" report.
iText — Java SDK:
import com.itextpdf.kernel.pdf.PdfDocument;
import com.itextpdf.kernel.pdf.PdfWriter;
import com.itextpdf.layout.Document;
import com.itextpdf.layout.element.Paragraph;
PdfWriter writer = new PdfWriter("hello.pdf");
PdfDocument pdf = new PdfDocument(writer);
Document doc = new Document(pdf);
doc.add(new Paragraph("Hello, Ada").setBold().setFontSize(24));
doc.add(new Paragraph("Welcome to the report."));
doc.close();
…plus a build.gradle entry, a license decision (AGPL or commercial), and your operations team owning the JVM that runs it.
makesPDF — one HTTP call:
curl -X POST https://makespdf.com/api/v1/md \
-H "Authorization: Bearer $MAKESPDF_API_KEY" \
-H "Content-Type: application/json" \
-d '{"markdown": "# Hello, Ada\n\nWelcome to the report."}' \
-o hello.pdf
Why people switch
- Most teams don't need an SDK. They need a PDF endpoint that takes data and returns a compliant document. The imperative drawing model is overkill for invoices, receipts, reports, and agent-generated content.
- AGPL is a procurement landmine. The community iText is AGPL-3.0; many enterprises have to take the commercial license, and the contract negotiation is non-trivial. A hosted API removes the SDK from your build entirely.
- Markdown is the right shape for content. Most documents are mostly content. Generating markdown from a database is a fraction of the work of an imperative SDK call tree.
- Agents. A public skill file is the right primitive for LLMs. Asking a model to emit Java that calls iText's API is awkward.
- Operational footprint. No JVM to size, no SDK upgrade churn, no license compliance tracking.
When iText / Apryse is still the right call
- You need deep PDF manipulation beyond rendering — splitting, merging, redacting, digitally signing, form-filling, low-level object editing. That's the SDK's strength; we don't compete on that surface.
- PDF/X print-production workflows with CMYK + ICC profiles + spot colors. We're PDF/A-2A archival, not print pre-press.
- Highly regulated environments that mandate an on-prem SDK with formal certifications and vendor support contracts.
- You already have years of iText code and the migration cost outweighs the operational savings.
Migration
If your iText usage is "build a Document, add Paragraphs, save," you're rendering content — that maps cleanly to markdown + /api/v1/md, or the builder DSL for precise table-heavy documents (invoices, statements). If you're using iText for digital signing, form-filling, or post-processing existing PDFs, those use cases stay with iText.