Get your API key
Best PDFShift alternatives in 2026: 5 options compared

Best PDFShift alternatives in 2026: 5 options compared

Looking for a PDFShift alternative? PDF4.dev, Doppio, APITemplate, DocRaptor, and Gotenberg compared on pricing model, templates, free tier, and API design.

8 min read

PDFShift is a solid HTML to PDF conversion API, but it is deliberately minimal: you send HTML, you get a PDF, and that is the whole product. Five alternatives are worth evaluating in 2026 depending on what you are missing. PDF4.dev adds stored templates, Handlebars variables, and an MCP server for AI agents. Doppio wins on per-render price at volume. APITemplate adds a no-code editor. DocRaptor adds print-grade CSS. Gotenberg removes the vendor entirely if you can self-host. This comparison covers pricing models, feature gaps, and a migration path with code.

Why do developers look for a PDFShift alternative?

The most common reason is the missing template layer, followed by the credit pricing model. PDFShift converts HTML you build yourself, on every call. That is fine for one-off conversions, and limiting for document workflows.

  • No stored templates. Every render sends the complete HTML. If your invoice layout lives in your application code, changing a footer means a deploy. Template-based APIs store the layout and accept only data.
  • Output-size credit pricing. One PDFShift credit covers 5 MB of generated output, so a 14 MB PDF costs 3 credits (per PDFShift's public pricing page, July 2026). Per-document APIs charge the same for a 200 KB receipt and a 20 MB brochure. Image-heavy documents shift the math against credit billing.
  • Free plan is for testing. 50 credits per month with a 15 MB file cap and a 30 second timeout is enough to evaluate, not to run a side project indefinitely.
  • No visual editor. Designers and non-developers cannot touch the documents. Layout changes always route through engineering.
  • No AI agent integration. There is no MCP server, so agent workflows require custom wiring around the REST API.

If none of these bite, staying on PDFShift is reasonable: it is focused, documented, and does conversion well. If two or more bite, here is the field.

PDFShift alternatives at a glance

The table below compares the five main alternatives on the axes that actually drive the switch: pricing model, template support, free tier, and deployment model.

PDFShiftPDF4.devDoppio.shAPITemplateDocRaptorGotenberg
ModelConversion APITemplates + APIConversion + templatesTemplate editor + APIConversion APISelf-hosted container
Pricing basisCredits (5 MB output each)Per renderPer renderPer renderPer documentFree (your infra)
Free tier50 credits/mo, testing-orientedYes, no credit card400 renders/mo50 renders/moTrial onlyUnlimited
Stored templatesNoYes (Handlebars + helpers)YesYes (drag and drop)NoNo
Visual editorNoYesBasicYesNoNo
EngineChromiumChromiumChromiumChromiumPrince XMLChromium + LibreOffice
MCP / AI agentsNoYes (14 tools)NoNoNoNo
Ops burdenNoneNoneNoneNoneNoneYours (scaling, CVEs)

Feature and pricing details reflect public vendor pages as of July 2026 and change often. Check each vendor's pricing page before committing.

When is PDF4.dev the right PDFShift alternative?

PDF4.dev fits when the HTML you send to PDFShift is really a template in disguise: the same layout rendered with different data on every call. You store the layout once as a Handlebars template, then each render sends only JSON.

The practical differences from PDFShift:

  • Templates with variables. {{customer_name}}, {{#each line_items}}, plus built-in helpers like {{formatCurrency total "EUR" "de-DE"}} and {{formatDate issued_at "long"}}. Layout changes happen in the dashboard editor, not in a code deploy.
  • Per-render billing. A 20 MB image-heavy report costs the same as a one-page receipt.
  • MCP server for agents. Claude, Cursor, and ChatGPT can list templates, render PDFs, and fetch logs as native tool calls. See the AI integration guide for client setup.
  • Delivery options. Binary, base64, or a signed URL with a 24 hour TTL, which keeps large PDFs out of agent context windows.

A complete render call:

curl -X POST https://pdf4.dev/api/v1/render \
  -H "Authorization: Bearer p4_live_xxx" \
  -H "Content-Type: application/json" \
  -d '{
    "template_id": "invoice",
    "data": {
      "customer_name": "Acme Corp",
      "invoice_number": "INV-2026-041",
      "total": 1500
    },
    "delivery": "url"
  }'

Raw HTML conversion (the PDFShift-style workflow) also works: pass html instead of template_id, so you can migrate call-for-call first and adopt templates later.

Which alternative wins on price?

For raw conversion volume, Doppio's entry tier is the most aggressive in this group; for image-heavy documents, any per-render pricing beats PDFShift's output-size credits. Doppio's paid plan starts at $16 per month for 4,000 renders, and its free tier of 400 renders per month is genuinely usable for small projects. APITemplate starts around $29 per month for roughly 1,000 renders with the visual editor included. DocRaptor starts around $44 per month, the premium being the Prince engine rather than volume.

The pricing-model difference matters more than the sticker price:

ScenarioCredit pricing (PDFShift)Per-render pricing
1,000 one-page invoices (~100 KB each)~1,000 credits1,000 renders
1,000 photo reports (~12 MB each)~3,000 credits1,000 renders
One 40 MB catalog~8 credits1 render

Approximate figures based on PDFShift's published 1 credit = 5 MB rule. Actual credit consumption depends on exact output size.

If your PDFs embed photos, scans, or charts, per-render billing is structurally cheaper. If you generate mostly small text documents, the models converge and the feature set should decide.

What about self-hosting with Gotenberg?

Gotenberg replaces the vendor bill with an ops bill: it is a free, open source Docker container exposing Chromium and LibreOffice conversion over HTTP, and you run it yourself. One docker run gotenberg/gotenberg:8 gives you an HTML to PDF endpoint with no per-document cost.

The trade-offs are the usual self-hosting ones:

  • Scaling is yours. Chromium is memory-hungry; concurrent rendering needs horizontal replicas and a queue.
  • Security patching is yours. In May 2026, three Gotenberg vulnerabilities were disclosed together, including CVE-2026-42593, an unauthenticated arbitrary PDF read via the stamp and watermark routes. Managed APIs patched nothing that week; self-hosters did.
  • No templates, no editor, no logs UI. Gotenberg is stateless conversion only, like PDFShift but on your hardware.

Gotenberg makes sense for high-volume internal workloads where data cannot leave your network. For a deeper feature-by-feature look, see the Gotenberg comparison page.

How do you migrate off PDFShift?

A PDFShift integration is one HTTP call, so migration is mostly renaming fields: point your client at the new endpoint, move the API key to the new auth header, and map the option names. Your existing code sends a source field containing HTML or a URL to api.pdfshift.io/v3/convert/pdf. The equivalent PDF4.dev call:

// Before: build the full HTML, send it on every call.
// After: reference a stored template and send only the data.
const res = await fetch("https://pdf4.dev/api/v1/render", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.PDF4_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    template_id: "monthly-report",
    data: { month: "July 2026", revenue: 48200 },
    format: { preset: "a4", margins: { top: "20mm", bottom: "20mm", left: "15mm", right: "15mm" } },
  }),
});
const pdf = Buffer.from(await res.arrayBuffer());

A sensible migration sequence:

  1. Swap the conversion call first. Send the same HTML you already build to the new API's raw-HTML mode and diff the output PDFs on your top 10 documents.
  2. Extract templates second. Move each recurring layout into a stored template with variables, then delete the HTML-building code path.
  3. Re-check page options. Margins, headers, footers, and page size options have different names on each API; a print CSS pass usually ports unchanged since the engine is the same Chromium.
  4. Keep both keys live for a week. Route a small percentage of traffic to the new API before cutting over.

Since PDFShift and most alternatives share the Chromium engine, output differences are usually margin defaults rather than layout breakage. The HTML to PDF benchmark has fidelity comparisons across engines if you are also considering DocRaptor's Prince.

Which PDFShift alternative should you pick?

Match the alternative to the reason you are leaving. This decision table covers the common cases:

You needPickWhy
Stored templates + variablesPDF4.devHandlebars templates with helpers, visual editor, per-render billing
AI agents generating documentsPDF4.devOnly option with a native MCP server
Cheapest volume conversionDoppio$16/mo entry for 4,000 renders
Non-developers editing layoutsAPITemplateDrag and drop template editor
Print-grade pagination (books, catalogs)DocRaptorPrince XML: running headers, page counters, footnotes
Data cannot leave your networkGotenbergSelf-hosted Docker, free, you own the ops
Just cheaper raw conversion, no workflow changeDoppio or PDF4.dev raw-HTML modeSame Chromium output, per-render billing

If you only need to convert a handful of files rather than integrate an API, the free browser-based HTML to PDF converterTry it free handles one-off jobs with no signup.

For the broader market view beyond PDFShift's direct competitors, see best PDF generation APIs in 2026 and the PDFMonkey alternatives roundup, which covers the template-first side of the market in more depth.

Free tools mentioned:

Html To PdfTry it free

Start generating PDFs

Build PDF templates with a visual editor. Render them via API from any language in ~300ms.