PDFops v0.10: fill a PDF by email, make any PDF fillable

v0.10 is the no-code on-ramps release. The API is unchanged — same two primitives, fill and merge — but there are now two ways to use PDFops before you've written a line of code, and one of the oldest dead-ends in PDF automation ("this PDF has no form fields") finally has a fix that doesn't involve Acrobat.

Fill a PDF by email — fill@pdfops.dev

Attach a blank fillable PDF and your field values to an email, send it to fill@pdfops.dev, and the reply comes back with the filled PDF — plus the exact curl command that produced it, so the jump from "it works" to "it's in my codebase" is copy-paste. Values go in the body as plain key: value lines, as raw JSON, or as a values.json attachment. Add flatten: true to bake the result flat.

Limits are deliberate: blank templates only (a PDF that already contains data is refused — attachment contents are never stored or logged, and refusing filled-in forms means this address can't become the thing that forwards someone's data around), 5 MB per PDF, evaluation volume rather than production volume. The full contract is on /fill-by-email.

Make any flat PDF fillable — in the browser

Most PDFs that should be forms aren't — they're flat: text and layout baked into the page, no interactive field layer. Until now, every PDFops surface answered that with "sorry, no AcroForm fields." The new make-fillable tool closes that gap: drop the flat PDF, draw text and checkbox fields where they belong, rename them to something your code will recognize, and download a standard AcroForm PDF that works in Acrobat, Preview, browsers, and every PDF library.

It runs entirely in your browser — rendering (pdf.js) and field creation (pdf-lib) both happen client-side, so the PDF never leaves your machine. On export you also get the ready-to-POST /api/fill-form call with your own field names already in it.

The chain, end to end

Those two pieces compose. Starting from a PDF with no fields at all:

1. Draw the fields on /tools/make-fillable and export — you now have a real template. (No PDF handy? The tool ships with a sample flat PDF.)
2. Prove the template with zero code: email it with values to fill@pdfops.dev, get the filled PDF back.
3. Automate it: the reply already contains the equivalent API call — wire it into your webhook, cron, or edge function. Guides for Python, Node.js, and JavaScript.

Deterministic fills, and flatten=true

Since late July, /api/fill-form and /api/merge are byte-deterministic: the same template and the same values return a byte-identical PDF, every time, across deployments. If you snapshot-test documents in CI or need audit-grade reproducibility, you can now assert on a hash — the how and why is in snapshot-testing PDFs in CI. fill-form also accepts flatten=true, which bakes the filled fields into the page content so the output is no longer editable — re-inspecting a flattened fill reports zero fields.

Also since the last release notes

• Paid tiers are live. Free keyed tier (250 requests/month, email in, key out, no card), Indie $16/mo for 4,000, Pro $79/mo for 25,000 — with a usage dashboard and GET /api/usage.
• POST /api/invoice — a complete, deterministic invoice PDF from JSON, no template needed, with a free browser generator on top.
• PDFops vs pdf-lib — an honest in-process-vs-hosted comparison, including when you should just use pdf-lib.
• Fixed: the curl example in the API-key signup email had a bug that broke every new user's first copy-paste call. It's fixed, with an apology to everyone who hit it.

Try it

The 30-second version, no signup:

curl -X POST https://pdfops.dev/api/fill-form \
  -F "pdf=@your-template.pdf" \
  -F 'fields={"customer_name":"Acme Co","total":"$1,250.00"}' \
  -o filled.pdf

Or skip the terminal entirely: make a PDF fillable, fill it by email, or use the playground. Questions, bugs, or a workflow these primitives don't cover? Tell us — the roadmap is driven by what people actually hit.

← All posts · Docs · Pricing