DS-11 — programmatic fill compatibility

Verdict at a glance

File facts

• Source: https://eforms.state.gov/Forms/ds11_pdf.PDF (issuer page: here)
• Blank tested: state-ds-11.pdf · 2508 KB · sha256 6b30860f0b54cba9df1a54d4eb007dc93a6c785b5253516604530b1c1898e2f6
• License: US federal government work — public domain (17 U.S.C. § 105). The hash-verified blank is redistributed here unmodified.
• Structure: 6 pages · AcroForm
• Fields: 84 (63 text, 20 checkbox, 1 button)

Quirks & limitations

• The class-pattern question this entry was fetched to answer: is a State Department form built like USCIS's (dynamic XFA wrapped in owner-password AES encryption, verified in this registry's uscis-i-9 entry) or like the courts' (plain AcroForm, verified in uscourts-ao-440 and uscourts-101)? Measured directly: DS-11 is a plain, unencrypted AcroForm with no XFA dictionary on /AcroForm at all — confirmed via cantoo/pdf-lib load plus `qpdf --show-encryption` reporting 'File is not encrypted'. State's sibling renewal form DS-82 (checked alongside it for this entry, not itself added to the registry) is the same shape — plain AcroForm, unencrypted, 71 fields including 6 real RadioGroups — so this isn't a one-off; State's form family reads as its own class, distinct from both USCIS and the IRS's hybrid-XFA pattern.
• eforms.state.gov has no bot-wall: a plain `curl` with a browser User-Agent fetched this 2.5 MB, 6-page blank on the first try, no 403 and no residential-IP/CDP workaround needed — a contrast worth recording next to uscis.gov's Akamai 403-to-datacenter-IPs behavior in the i-9 entry.
• 84 fields (63 TextField, 20 CheckBox, 1 pushbutton). Several visually-mutually-exclusive questions are built as sets of independent, ungrouped CheckBox fields rather than a single RadioGroup — verified field-by-field via pypdf's raw field dict: the 'previous passport status' question (Submitting/Stolen/Lost/In your possession) is four separate /Btn fields ('Book Status Submitting', 'Book Status Stolen', 'Book Status Lost', 'Book Status Possession'), each with Ff=0 (no radio flag set) and its own independent /Off + one on-state pair. Nothing in the AcroForm structure stops a filler from checking more than one simultaneously — a filler has to enforce mutual exclusivity itself. This is the same failure shape this registry separately documents in uscourts-101's Yes/No questions; seeing it twice, from two unrelated agencies' Acrobat-authored forms, is what turns it from an anecdote into a pattern worth checking for on any new form.
• 6 pages, but all 84 fields sit on the last two — pages 1-4 are eligibility rules, document checklists, and the privacy-act notice with zero form fields; the entire fillable application (identity, parents, spouse, passport book/card status) is packed onto pages 5-6. Verified by walking each field's widget /P (page) reference against the page tree, not by eyeballing the render: page 5 carries 30 widgets, page 6 carries 69. A filler that assumes fields are spread evenly across a 6-page form, or front-loaded like most other forms in this registry, will misjudge this one.

Tested request

This exact shape ran against the live API during the recorded test (values here shortened to two fields; the test filled all 83 supported fields). With flatten=true, two identical runs produced byte-identical output — sha256 2bf6aa87075741910fbf1ff37396af06d98f1effb1f934de1a9e63c6ec158dd3.

curl -X POST https://pdfops.dev/api/fill-form \
  -F "pdf=@state-ds-11.pdf" \
  -F 'fields={"Address Line 2":"PDFops","List all other name you have used":"PDFops"}' \
  -F "flatten=true" \
  -o filled.pdf

Enumerate all 84 field names first with the inspector or POST /api/inspect.

Field schema

Frequently asked

← All forms in the registry · Inspect your own PDF · Make a flat PDF fillable