Workflow 11 min read 22 October 2026

XFA to AcroForm Migration: The Complete Practical Guide

XFA forms are deprecated in PDF 2.0 and incompatible with most modern PDF viewers. This guide explains how XFA differs from AcroForm, which migration paths are realistic, what tools exist, and what to do when automated conversion is not enough.

XFA (XML Forms Architecture) was Adobe's attempt to bring XML-based dynamic forms to PDF, introduced in Acrobat 6 and widely deployed in enterprise document management through the 2000s and early 2010s. XFA forms look like PDFs but are actually XML applications rendered inside the PDF container — a different beast entirely from the standard AcroForm interactive form fields that every PDF viewer supports. In PDF 2.0 (ISO 32000-2:2017), XFA was officially deprecated. Most modern PDF viewers — including Firefox, Chrome, Edge, and recent Safari — simply do not support XFA. An XFA form viewed in a non-supporting viewer renders as a blank page or shows a generic "This document requires Adobe Acrobat" message. Adobe itself has been gradually deprecating XFA support in newer Acrobat versions. If you have XFA forms in your organisation's document inventory, migration to AcroForm is no longer optional — it is an operational necessity. This guide explains the migration paths available, what tools exist, what conversion fidelity to expect, and what to do when automation is not enough.

XFA vs AcroForm: what actually differs

Understanding why XFA migration is complex requires understanding what XFA actually is: XFA forms are XML applications. The XFA form definition lives in an XML packet embedded in the PDF's /AcroForm /XFA stream entry. This XML defines form fields, layout, data binding, validation scripts (JavaScript/FormCalc), event handlers, master pages, subforms, and dynamic content. When Acrobat renders an XFA form, it essentially runs an XML application engine — not a PDF renderer. The visible form is generated dynamically from the XFA XML. XFA features that have no AcroForm equivalent: - Dynamic layout: form sections that grow or collapse based on field values (e.g., add rows to a table) - Data binding: fields bound to XML data nodes via XPath expressions - FormCalc scripting: a proprietary scripting language used by many XFA forms - Subform repeat: dynamically repeating subform instances - Flow content: flowing text that wraps across pages AcroForm fields are first-class PDF objects: Widget annotation dictionaries in the /AcroForm /Fields array. Each field has a position, appearance, type, value, and JavaScript event handlers. AcroForm is a fixed-layout model — fields are placed at absolute coordinates, just like other PDF annotations. The key implication: any XFA form feature that requires dynamic layout, data binding, or FormCalc scripting has no direct AcroForm equivalent. Migration of these features requires design decisions about how to approximate the functionality in the static AcroForm model.

Migration strategies and tools

Static XFA forms (simplest case) — Many XFA forms in practice are static: they use XFA's XML form definition but don't actually use dynamic layout or data binding. They appear and behave identically to AcroForm forms. For these, automated conversion tools can often produce high-quality AcroForm equivalents. Adobe Acrobat Pro — Acrobat can save some XFA forms as "static PDF" which renders the XFA to a fixed page and creates AcroForm widgets over the form fields. The output quality varies; complex forms with scripts typically lose functionality. File > Export > Export to Different Format > Flattened PDF can produce a static (non-interactive) version. iText 7 / Bouncy Castle — iText's Java/C# library has XFA-to-AcroForm migration utilities. The XFAFlattener renders XFA to a fixed PDF and provides hooks for script translation. Commercial license required for non-AGPL use. iText publishes XFA migration documentation. Adobe LiveCycle Designer — If the original LiveCycle Designer source (.xdp files) is available, the cleanest migration is to redesign the form natively in AcroForm using Acrobat Pro or an alternative form builder. This is labour-intensive but produces the best result. FormBridge — A commercial service specifically targeting XFA-to-HTML5/AcroForm migration for enterprise form estates. Custom extraction scripts — For large form libraries, parsing the XFA XML directly with an XML library and generating AcroForm equivalents programmatically (using iText, pdfbox, or pdf-lib) can process bulk forms. This requires XFA schema knowledge and significant development effort.

Handling scripts: JavaScript and FormCalc

XFA forms often contain validation, calculation, and visibility logic written in JavaScript or FormCalc. This is the hardest part of XFA migration: JavaScript migration — AcroForm supports JavaScript via /AA (additional actions) triggers (field change, mouse enter/exit, validate, calculate). XFA's JavaScript model differs: it uses the XFA object model (xfa.form.*, xfa.data.*) rather than the AcroForm/Acrobat JavaScript API. Scripts must be rewritten to use the AcroForm object model. Logic that depends on dynamic layout or data binding has no AcroForm equivalent and must be redesigned. FormCalc — FormCalc is a proprietary scripting language with no AcroForm equivalent. FormCalc scripts must be converted to JavaScript or the logic must be reimplemented. Adobe published FormCalc documentation that aids in translation, and some common FormCalc functions (Sum, If, Concat) have straightforward JavaScript equivalents. Practical approach: 1. Audit your XFA form inventory: categorise forms as static (no scripts), simple-scripts (JS/FormCalc without dynamic layout), or complex (dynamic layout, data binding). 2. Static forms: use automated conversion tools. 3. Simple-script forms: convert and manually translate scripts. 4. Complex forms: plan a redesign, possibly replacing with HTML5 web forms integrated with your document management system. PDF/UA compliance is an important consideration during migration — AcroForm fields must have accessible labels (/TU tooltip, correct tab order). See PDF Forms Best Practices for accessible form field requirements.

Frequently asked questions

Why do XFA forms show as blank in Chrome or Firefox?

Chrome, Firefox, and most modern PDF viewers (except Adobe Acrobat/Reader) do not have an XFA rendering engine. XFA forms contain a minimal PDF "fallback" that typically shows the message "Please open this document with Adobe Acrobat Reader" or renders as a blank page. Only Adobe's own tools implement the full XFA rendering engine (Acrobat, Reader, and LiveCycle/Experience Manager Forms). This is why XFA forms are a compatibility hazard: an organisation distributing XFA forms cannot guarantee recipients can open them unless they explicitly require Adobe Reader. Migrating to AcroForm eliminates this dependency.

Can I convert an XFA form to HTML instead of AcroForm?

Yes, and for many use cases this is the better long-term strategy. HTML5 forms with a back-end submission handler are universally accessible, work on all devices, and support dynamic layout natively. Adobe Experience Manager Forms (the successor to LiveCycle) can render XFA form definitions as both PDF/AcroForm and HTML5 — a migration path for organisations already using Adobe's platform. For standalone form conversion, tools like DocuFiller and form builder platforms offer XFA import and HTML5 export. The trade-off is that HTML forms do not produce a signed/certified PDF with embedded form data — if your workflow requires a signed PDF record, AcroForm migration is necessary.

Does PDF/A support AcroForm interactive fields?

PDF/A-1 does not support interactive form fields — PDF/A-1 documents must be flattened (all dynamic content removed). PDF/A-2 and PDF/A-3 support AcroForm interactive fields with restrictions: JavaScript actions are prohibited; form submission actions to URLs are prohibited; fields must have complete visual appearances embedded. PDF/UA requires that form fields have accessible names via /TU. For archiving form submissions (filled-in forms), the recommended approach is to flatten the form into a static PDF/A document after submission — preserving the submitted values as static page content rather than interactive fields.

Try it yourself

Everything in this article can be done directly in the free PDFTheGuide editor — no account required.

Fill PDF Form Edit PDF Open editor