Registry
PDF form compatibility registry
Can that government form actually be filled programmatically? Each entry is a real public form tested on its unmodified upstream blank — field schema, XFA and encryption quirks, per-tool results, provenance hash, and the exact request that worked. No vendor-doc claims: every cell traces to a recorded run.
The forms
| Form | Jurisdiction | Fields | Traits | pdfops API | pdf-lib | @cantoo/pdf-lib | pypdf | renders? |
|---|---|---|---|---|---|---|---|---|
| California DE 1 | California (state) | 112 | clean AcroForm | verified + deterministic flatten | verified (111/111) | verified (111/111) | text fields verified (91/91) | values render (91/91) |
| California FL-100 | California (state) | — | encrypted | fails at parse | fails at load | fails at load | text fields verified (66/66) | no filled output to render |
| CRA TD1 (2026) | Canada federal | — | encrypted | fails at parse | fails at load | fails at load | text fields verified (24/24) | no filled output to render |
| HMRC 64-8 | United Kingdom | 77 | clean AcroForm | verified + deterministic flatten | verified (76/76) | verified (76/76) | text fields verified (59/59) | values render (59/59) |
| IRS Form 1040 | US federal | 199 | hybrid XFA | verified + deterministic flatten | verified (199/199) | verified (199/199) | text fields verified (126/126) | values render (126/126) |
| IRS Form 2848 | US federal | 92 | hybrid XFA | verified + deterministic flatten | verified (91/91) | verified (91/91) | text fields verified (70/70) | values render (70/70) |
| IRS Form W-4 | US federal | 48 | hybrid XFA | verified + deterministic flatten | verified (48/48) | verified (48/48) | text fields verified (43/43) | values render (43/43) |
| IRS Form W-9 | US federal | 23 | hybrid XFA | verified + deterministic flatten | verified (23/23) | verified (23/23) | text fields verified (15/15) | values render (15/15) |
| OPM Optional Form 306 | US federal | 40 | signature fields | verified + deterministic flatten | verified (38/38) | verified (38/38) | text fields verified (25/25) | values render (25/25) |
| DS-11 | US federal | 84 | clean AcroForm | verified + deterministic flatten | verified (83/83) | verified (83/83) | text fields verified (63/63) | values render (63/63) |
| USCIS Form I-9 | US federal | 128 | clean AcroForm | verified + deterministic flatten | verified (128/128) | verified (128/128) | text fields verified (115/115) | values render (115/115) |
| Official Form 101 | US federal courts | 159 | clean AcroForm | verified + deterministic flatten | verified (155/155) | verified (155/155) | text fields verified (127/127) | values render (127/127) |
| AO 440 | US federal courts | 34 | clean AcroForm | verified + deterministic flatten | verified (31/31) | verified (31/31) | text fields verified (29/29) | values render (29/29) |
Machine-readable version of everything on these pages: registry.json. Last test run: 2026-08-06.
Methodology
Each blank is fetched from the issuer's own URL (recorded per entry, pinned by sha256 — several issuers re-publish changed files at the same URL). Six independent legs then run against the same bytes:
- pdfops API — inspect → fill every supported field → re-inspect the output to verify each value landed → fill twice with
flatten=trueand compare sha256 (byte-determinism check) → re-inspect the flattened output (expect zero remaining fields). - pdf-lib (upstream 1.17.1) — load, enumerate, fill, save, reload, verify each value in-process.
- @cantoo/pdf-lib (the maintained fork, 2.6.5) — the exact same steps as the pdf-lib leg, run separately so fork-vs-upstream divergence on real forms shows up as data instead of folklore.
- poppler render check —
pdftotextover the pdf-lib-filled output must contain every filled text value: a value that lands in/Vbut never paints is not filled in any way a human reviewer accepts. Apdftoppmpage-1 raster sha256 is recorded alongside (font-stack-sensitive, so informational rather than pass/fail). - pypdf — load (including empty-user-password decryption where its optional cryptography dependency allows), enumerate, fill text fields, write, re-read, verify. Fill scope is text fields only — claiming checkbox/radio success across viewers would overstate it.
- qpdf — structural
--checkand--show-encryption.
Values are synthesized per field type and honor maxLength (the 1040's 2-character split boxes are why that matters). Signature and pushbutton fields are skipped by design — a value-filling API should not fake a cryptographic signature. Failures are recorded as results, not retried into silence: the registry exists as much for the form that breaks tooling as for the one that works.
An automated weekly recheck re-downloads every source URL and compares hashes; when an issuer revs a form, the entry is re-tested against the new file before the page changes.
Limitations, honestly
- 13 forms today — a corpus, not a census. Entries are added where the quirk teaches something (XFA hybrids, encryption, signature fields), not to inflate the count.
- Some issuers (USCIS, SSA, DOL) block automated fetching of their blanks; forms from those sources (e.g. the I-9) are on the roadmap but need a manual-fetch lane before they can be re-verified automatically, so they are not listed yet.
- ACORD forms (e.g. ACORD 25) are license-restricted and cannot be redistributed here; an entry that links out without hosting the blank may come later.
- "Verified" means the value round-tripped through re-inspection on the tested date with the listed versions — not a guarantee about other versions, viewers, or e-filing portals' server-side validation.
Test your own form
The same chain that produced these results runs on any PDF: drop yours into the inspector to see its fields and the exact fill call, or start from a flat scan with make-fillable. The fill itself is one request — POST /api/fill-form, no key needed for the first 100 calls/IP each month (docs).