If you have ever opened a government form, typed into what looked like a normal text field, and had a PDF tool simply fail to save your input, you likely ran into the AcroForm-versus-XFA divide, and it is one of the more genuinely confusing corners of the PDF format for anyone who has not had a reason to learn about it before.
AcroForm is the original, and far more widely supported, PDF form standard. It defines form fields — text boxes, checkboxes, radio buttons, dropdowns — as annotation objects layered directly on top of a normal PDF page, each with a defined name, position, and value. Because AcroForm fields are a well-documented part of the core PDF specification, essentially every PDF library, including pdf-lib, can read a form's field definitions, look up a field by name, and write a new value into it directly, entirely client-side.
XFA (XML Forms Architecture) is a different, more elaborate form technology that Adobe introduced and, for a period, some government agencies and large enterprises adopted for particularly complex forms — the kind with dynamically appearing sections, conditional field logic, or multi-page repeating tables. An XFA form does not store its fields as simple annotation objects the way AcroForm does; it embeds an entire separate XML-based form description and rendering model inside the PDF, and historically relied on Adobe's own proprietary form-rendering engine (built into Adobe Acrobat and Reader) to actually interpret and display that XML correctly.
This matters enormously for a browser-only tool for one specific reason: there is no open, standard, widely-implemented way to render or fill an XFA form outside of Adobe's own proprietary engine. pdf-lib, pdf.js, and effectively every other open-source PDF library treat XFA as, at best, an opaque blob they can see exists but cannot meaningfully interpret or edit. This is not a minipdftoosz-specific limitation — it is the honest state of open-source PDF tooling generally, and it is exactly why the Fill PDF Forms tool states plainly on its own page that XFA forms are not supported, rather than silently failing or producing a broken result without explanation.
Telling the two apart before you start is usually straightforward. If a form opens and behaves identically in a plain browser PDF viewer as it does in Adobe Reader, with fields that look and act the same way, it is almost certainly AcroForm and will work fine with Fill PDF Forms. If a form specifically warns "please open in Adobe Reader for full functionality," behaves differently or refuses to display fields correctly in other viewers, or comes from certain older government portals that were built specifically around Adobe's LiveCycle Designer tooling, there is a real chance it is XFA-based.
The good news is that XFA forms have become considerably rarer over the past several years, as most agencies and enterprises that once relied on them have migrated to standard AcroForm or web-based form systems instead — XFA was always something of an evolutionary dead end even within Adobe's own product line, and Adobe itself has been de-emphasizing it. For the AcroForm forms that make up the overwhelming majority of what people actually encounter day to day — tax documents, applications, intake forms, agreements — Fill PDF Forms handles field detection and value-filling entirely locally, with no upload of the form or the personal information you type into it.