The one-line difference
PDFShift is a hosted HTML-or-URL → PDF service backed by Chromium. POST a URL or an HTML string, get a PDF back. makesPDF is the same shape but with a different input surface (markdown, builder DSL, structured JSON), an owned deterministic engine instead of headless Chromium, PDF/A-2A + PDF/UA-1 compliance by construction, and an agent-native API (skill file, MCP, x402 wallet payments).
Feature matrix
| PDFShift | makesPDF | |
|---|---|---|
| Shape | Hosted REST API | Hosted REST API (/api/v1/*) |
| Engine | Headless Chromium | Owned deterministic layout engine |
| Inputs | URL, HTML string | Markdown, builder DSL, JSON |
| Markdown-native | No | Yes (POST /api/v1/md) |
| Determinism | Subject to Chromium drift | Byte-stable across deploys |
| Tagged PDF (PDF/UA-1) | No | Yes, by default |
| PDF/A archival | No | Yes (PDF/A-2A) |
| veraPDF-validated | No | Yes |
| Agent-first | No | Yes — skill file, MCP, x402 |
| First-party CLI | No | Yes (@makespdf/cli) |
| Pricing model | Per-credit monthly | Per-render credits + x402 wallet |
Same input, two outputs
PDFShift — POST a URL or HTML:
curl https://api.pdfshift.io/v3/convert/pdf \
-u "api:YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{"source": "<html><body><h1>Hello, Ada</h1><p>Welcome.</p></body></html>"}' \
-o hello.pdf
makesPDF — POST markdown:
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."}' \
-o hello.pdf
The PDFShift output is whatever Chromium prints from your DOM — a flat untagged PDF unless you've hand-tuned the HTML for accessibility. The makesPDF output has a real H1/P structure tree, validated against veraPDF.
Why people switch
- Markdown removes the CSS-print stylesheet. Most documents are content. Generating markdown from a database is a fraction of the work of producing a print-quality HTML page.
- Compliance. Chromium-based services emit, at best, a partial structure tree. PDF/UA-1 needs more than that. We tag by construction.
- Determinism. PDFShift's output shifts when Chromium does. makesPDF's renderer is a single owned pipeline; same input → same bytes across deploys.
- Agents. A public skill file, an MCP server, and a CLI that ships the skill offline give AI agents a typed surface to emit. PDFShift is REST + docs.
- x402 wallet payments. Stateless agents can pay per render in USDC without an account.
When PDFShift is still the right call
- Your input is already a polished URL — a public dashboard, a styled report page — and you want a PDF snapshot of exactly that. URL-to-PDF is literally PDFShift's strength.
- You need arbitrary CSS features Chromium supports and we don't (CSS Grid templates, JS-driven canvases, web fonts loaded from a CDN at print time).
- You're comparing on price-per-credit alone and the credit math comes out cheaper for your volume.
For new integrations — especially markdown-first content or AI-driven document generation — the structured-input path is faster to build and easier to keep compliant.
Migration
Most PDFShift integrations are converting a templated HTML string. Switch to rendering markdown into /api/v1/md, or use the builder DSL for documents with precise table layouts. Both endpoints are language-agnostic JSON.
If you need to snapshot an existing URL, that's not the makesPDF use case — keep PDFShift for that surface and use makesPDF for the documents you generate from data.