Fillable PDF forms from HTML

Updated November 3, 2026 · 6 min read

Set pdfForm: true to turn standard HTML inputs into interactive AcroForm fields. The visual layout is rendered by Chromium exactly as it is for a normal PDF; the form fields are added on top of the rendered page.

Quick start

Use an HTML document with normal form controls. Add pdfForm: true and, for non-Latin input, a targetLang value.

const result = await client.generate({
  htmlContent: `
    <label>Full name <input name="fullName" value="Ada Lovelace"></label>
    <label>Email <input type="email" name="email" value="ada@example.com"></label>
    <label><input type="checkbox" name="terms" checked> Accept terms</label>
  `,
  format: 'A4',
  pdfForm: true,
  targetLang: 'en',
  downloadBuffer: true
});

curl -X POST "https://api.forkpdf.com/v1/generate-pdf" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "x-project-id: YOUR_PROJECT_ID" \
  -H "Content-Type: application/json" \
  -d '{
    "htmlContent": "<label>Full name <input name=\"fullName\" value=\"Ada Lovelace\"></label>",
    "format": "A4",
    "pdfForm": true,
    "targetLang": "en",
    "streamOnly": true
  }'

Supported controls

These controls are skipped because PDF has no equivalent form field: submit, reset, button, image, file, password, range, color, and hidden. Disabled and zero-sized controls are also skipped.

Labels and field names

Use a wrapping <label>, a for attribute, or aria-label so the generated field has a readable tooltip. Keep each field name unique; duplicate names can make filling and extraction ambiguous.

<label for="fullName">Full name</label>
<input id="fullName" name="fullName" value="Ada Lovelace">

<label>Email <input type="email" name="email"></label>

Pre-filled values

Text inputs use their HTML value; checkboxes and radios use checked; selects use selected. The generated PDF opens with the same values the HTML rendered.

Language and fonts

targetLang injects a font that covers the selected script so users can type into the fields. Supported values are en, hi, th, ja, zh, ko, and ar. The default is Latin.

For Hindi, Thai, Arabic, Japanese, Chinese, or Korean form input, set targetLang to the matching value. Otherwise typed text may not render with the correct glyphs.

Compliance and fillable forms

pdfForm can be combined with PDF/UA-1/2, standalone PDF/A-2/3/4, and matching PDF/UA + PDF/A combinations. PDF/UA requests keep AcroForm widgets and add tagged Form structure, readable field names, and widget metadata. PDF/A-only requests keep plain AcroForm widgets and do not add tagged form structure.

PDF/A-only forms are a PDF/A conformance claim, not a PDF/UA or accessibility claim. Use a PDF/UA combination when tagged form fields and screen-reader semantics are required.

{
  "htmlContent": "<label>Full name <input name=\"fullName\" value=\"Ada Lovelace\"></label>",
  "pdfForm": true,
  "targetLang": "en",
  "compliance": { "pdfUa": 2, "pdfA": "4" }
}

Response and storage

Use streamOnly: true for a raw PDF response, or downloadBuffer: true in the SDK. With stored output, the normal download URL and project storage behavior applies. This API does not provide a form-fill, form-submission, or form-hosting service.

Limitations

• PDF/A-only forms are not tagged and do not provide PDF/UA accessibility semantics. Use PDF/UA-1/2 for tagged forms.
• Tagged PDF/UA forms are machine-validated. The accessibility variant has representative NVDA + Edge testing; Adobe Reader announces labels and order but not text-field values, and Chrome does not expose the form fields in the tested build.
• Unsupported controls are skipped, not converted.
• Disabled and zero-sized controls are skipped.
• Use unique field names. Duplicate names are supported by the layout but make downstream processing ambiguous.
• There is no form-fill or form-extraction API in this release.
• Font choice is controlled by targetLang and the caller-supplied form font; check non-Latin input in your target reader.