XFA Forms Explained

XFA (XML Forms Architecture) is the more powerful, more complex, and increasingly deprecated form technology in the PDF ecosystem. XFA forms support dynamic layouts, data binding, and rich logic that standard PDF "acroform" cannot. They are also less compatible, harder to work with, and officially deprecated in PDF 2.0. This guide explains what XFA is, where you'll still encounter it, and what to do about it.

What XFA actually is

XFA is an XML-based forms specification originally developed by JetForm, acquired by Adobe in 2002. Key properties:

XML for form definition: the form structure, layout, and behavior are XML.
Dynamic: layouts can change based on data (rows added, sections shown/hidden).
Data binding: form fields bind to an external XML data source.
Scripting: FormCalc and JavaScript for logic.
Render targets: PDF, web (HTML/JS), print.

When wrapped in a PDF, the PDF contains an XFA XML payload. A PDF viewer that supports XFA renders the form; one that doesn't shows... it depends.

Acroform vs XFA

Two form technologies coexist in PDFs:

Acroform (traditional PDF forms):

Defined inside the PDF's native object structure.
Fields are PDF annotations of type Widget.
Layout is fixed.
JavaScript for logic; FormCalc not supported.
Universal viewer support.

XFA (the newer, more complex):

Defined in embedded XML.
Dynamic layout.
FormCalc and JavaScript.
Limited viewer support; deprecated in PDF 2.0.

Where you'll see XFA

XFA forms remain in use in:

Government forms: many tax authorities (CRA Canada, IRS some forms, US SSA, French tax authorities, etc.) issued XFA forms.
Enterprise apps: PeopleSoft, SAP, banking, insurance.
Adobe LiveCycle / Experience Manager Forms: the authoring tools.

In 2026, new XFA forms are increasingly rare. Existing ones persist for years; legacy support is the dominant context.

Why XFA was attractive (and why it isn't anymore)

The attractions in the 2000s:

Dynamic forms: tables that grow with data; conditionally shown fields.
Data binding: a tax authority could pre-fill the form with personal data via XML.
Same form for print and web: render the XFA template to either.
Rich logic: complex validation and calculation.

Why XFA fell:

Adobe deprecated XFA in PDF 2.0 (ISO 32000-2). Officially not part of the standard.
Few non-Adobe tools support it well. Browser PDF viewers, mobile readers, and many desktop readers either flatten XFA to a static PDF (lossy) or refuse to open it.
Modern web forms (HTML + JavaScript) are now better for dynamic interactivity.
Adobe Reader's XFA support has had bugs and quirks across versions.

Viewer behavior with XFA

Different viewers handle XFA differently:

Adobe Acrobat / Reader: full support.
Foxit Reader / PhantomPDF: substantial support.
Apple Preview: typically shows a static rendering; not editable.
Browser-built-in viewers (Chrome, Edge, Firefox pdf.js): usually show an "XFA forms not supported" message or a static rendering.
Mobile viewers: typically broken or static.

For Canadian tax filers, the famous example: the CRA's T1 return is an XFA form. Filing it requires Adobe Reader; the browser viewer can't help.

XFA in PDF 2.0

ISO 32000-2 (PDF 2.0) explicitly deprecates XFA. The XFA payload may still be inside a PDF 2.0 file, but conformant viewers are not required to process it.

In practice, this means: new tools and viewers may drop XFA support; existing tools maintain it but with shrinking priority.

The 2026 advice: don't author new XFA forms. Use acroform with JavaScript, or move to web forms.

Working with XFA forms

For users (filling them out):

Use Adobe Reader (current version): the most reliable.
Save before closing: some XFA forms refuse to save in older Reader versions.
If a browser viewer fails: download the PDF and open in desktop Reader.
For data import: the form may accept an XML data file for pre-fill.

For developers extracting XFA data:

xfa-tools and PDFBox: extract the XFA XML.
Manual XML parsing if you know the schema.

For converting XFA to acroform:

Adobe Acrobat Pro: has a "Convert Forms" feature, but quality varies.
Re-author the form as an acroform; often the cleanest path.

XFA static vs dynamic

XFA forms come in two flavors:

Static XFA: fixed layout; like a fancy acroform.
Dynamic XFA: layout changes with data; the "killer feature" of XFA.

Static XFA can often be converted to acroform with reasonable results. Dynamic XFA is much harder to translate; the dynamic behavior is what makes it dynamic.

Authoring tools

For new XFA forms (against advice):

Adobe LiveCycle Designer: now retired but still in use for legacy projects.
Adobe Experience Manager Forms: Adobe's current XFA authoring.

For acroform (the recommended path):

Adobe Acrobat Pro: built-in form editor.
Foxit PhantomPDF: similar capabilities.
Programmatic libraries: iText, pdf-lib, PDFBox.

For form-creation guidance, see making a PDF fillable, how to create fillable PDF form, and PDF form field types explained.

Migration patterns

For organizations stuck with legacy XFA:

Pattern A: maintain. Keep using Acrobat / Reader; train users; live with declining tooling support.

Pattern B: re-author as acroform. Rebuild static-equivalent forms. Lose dynamic behavior; gain compatibility.

Pattern C: move to web forms. Build HTML forms that submit data; generate a static PDF on submission for archival.

In 2026, Pattern C is the dominant choice for new development. Pattern A or B for legacy.

FormCalc

XFA's domain-specific calculation language:

Spreadsheet-like syntax.
Built for the kinds of calculations a form needs (sums, conditionals, lookups).
Not transferable to other contexts.

When converting XFA, FormCalc must be rewritten in JavaScript (for acroform) or whatever target form environment you choose.

Accessibility

XFA's accessibility story is mixed:

Adobe added accessibility support in later XFA versions.
Screen reader compatibility varies; Adobe Reader handles most XFA reasonably.
Conversion to acroform typically improves accessibility because tooling around acroform is better.

For broader accessibility guidance, see PDF accessibility guide and WCAG 2 for PDF accessibility.

Common gotchas

"This document does not support XFA forms". Browser viewers; tell the user to download and open in Reader.

Form saves blank. Some XFA forms require Reader Extensions (a digital signature from Adobe) to allow saving with filled data. Without it, only printing is supported.

Pre-fill XML mismatch. The XML data file format must match the form's binding. Schema drift breaks pre-fill.

Dynamic table rows lost. Conversion to static formats freezes the row count; dynamic behavior is lost.

Embedded JavaScript not running. Different viewer; different sandbox; scripts that worked in Acrobat fail elsewhere.

Inspecting an XFA PDF

To see if a PDF is XFA:

Open in a text editor; look for /XFA in the catalog.
Or with qpdf --qdf: explore the AcroForm entry.
Or with pdfinfo: some versions report XFA status.

The XFA XML is a stream attached to the AcroForm dictionary. Decompress and read to see the form template.

Practical recipe

If you have an XFA form to deal with:

For users: install Adobe Reader, latest version.
For organizations with legacy XFA: keep a maintenance plan (training, support); start migration planning.
For new forms: use acroform with JavaScript, or HTML forms.
For developers: budget extra time when XFA enters the project; tooling is sparse.

For PDF operations adjacent to XFA forms (combining, extracting pages, signing the filled output), Docento.app handles them locally without uploading.

Takeaway

XFA forms represent a powerful technology that didn't fit the broader PDF ecosystem. Adobe's deprecation in PDF 2.0 and the rise of web forms make XFA a legacy concern in 2026. If you have XFA forms in production, plan a migration. If you're starting fresh, use acroform or HTML forms. Save the XFA expertise for the legacy work that remains. See also making a PDF fillable, PDF form field types explained, and interactive PDFs with JavaScript.