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 — [e-mail]

Attach a blank fillable PDF and your field values to an email, send it to [e-mail], 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:

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

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.