AcroForm vs Overlay PDF Filling

Not all PDFs are built the same way. Some PDFs contain native fillable form fields. Others only look like forms but are actually flat layouts. Doqlo supports both paths: native AcroForm filling when supported fields exist, and overlay fields when values need to be placed visually on a stable PDF layout.

The goal is the same in both cases: map CSV data to the PDF, preview rows, and export completed PDFs in bulk. The right fill method depends on how the PDF was built.

Two ways to fill PDFs in Doqlo

Doqlo Bulk Fill supports two main field-placement paths.

AcroForm filling uses the PDF's own supported form fields. Overlay filling uses visual positions on the page. Both can produce completed PDFs from CSV rows, but they solve different document situations.

With native AcroForm filling, you map CSV columns to fields already in the PDF. With overlay filling, the PDF supplies the stable visual layout, and you place overlay fields where values should appear.

Neither path is universally better. A PDF with good supported native fields usually fits the native workflow. A flat PDF, certificate, label, or static layout usually fits the overlay workflow if the layout stays stable.

What is AcroForm filling?

AcroForm is a common PDF form technology. A PDF with native AcroForm fields can contain interactive fields such as text fields, checkboxes, single-select dropdowns, or radio groups.

If the PDF already contains supported native AcroForm fields, native filling is usually the cleanest path because the PDF itself provides the field structure. Doqlo can map CSV columns to supported existing AcroForm fields on supported non-XFA PDFs.

Native filling is useful when the field names, field positions, and answer choices are already part of the PDF and match the values you need to produce from CSV rows. It is also helpful when the output should preserve the idea that the PDF itself contains a form layer.

There are limits. A visible blank line or box is not always a native PDF field. Some PDFs look fillable but are flat. Some PDFs use unsupported form structures. Some fields may exist but not be in the supported field scope. Native filling in Doqlo is scoped to supported non-XFA AcroForm fields.

What is overlay filling?

Overlay filling places values visually on top of a stable PDF layout. Instead of relying on native form fields embedded in the file, you choose where the values should appear on the page.

In Doqlo Bulk Fill, overlay fields are placed on the PDF canvas and mapped to CSV columns. During preview and export, Doqlo draws the row value at the selected position. The PDF layout stays the same. The data changes row by row.

Overlay fields are visual placement fields. They let you place CSV values on top of the page, but they do not turn the original PDF into a native AcroForm form.

Overlay fields also do not remove or rewrite underlying PDF content. They are for placing values on a page, not for editing the source PDF structure or removing existing content.

This path is useful when the PDF is flat, when the original PDF is missing the fields you need, or when the workflow needs row-specific text in a place the PDF author did not expose as fillable.

When to use native PDF form fields

Use native PDF form fields when the PDF already has supported native fields and those fields match the values you need to fill.

This is usually the right starting point when:

• the PDF contains supported native AcroForm fields
• the needed fields already exist in the right places
• the form structure is stable across every output
• text fields, checkboxes, single-select dropdowns, or radio groups are already part of the PDF
• you want to use the existing PDF form layer instead of placing visual overlays for the same values

Native filling can be especially useful for structured business forms that were designed to be filled electronically. Examples include onboarding forms, internal approval forms, customer intake forms, service forms, registration forms, and forms exported from another system with a real AcroForm layer.

Do not skip validation just because the PDF has native fields. Preview representative rows, especially rows with blank values, long text, checkbox values, dropdown choices, or radio options. Export a test PDF before running the full batch.

When to use overlay fields

Use overlay fields when the PDF has no usable native fields, when the fields you need are missing, or when visual placement matters more than preserving native field structure.

Overlay fields are usually the right path when:

• the PDF is flat but visually stable
• the PDF looks like a form but does not expose usable native fields
• a supported native form is missing a place where row data needs to appear
• you need to add row-specific text in an area the original form did not provide
• the same positions should be filled for every CSV row
• the final visual output matters more than the PDF retaining native fields

Common examples include flat HR forms, certificates, forms printed from another system, static notices, fixed-layout internal forms, packing slips, labels, and training documents.

Overlay workflows depend on a stable layout. If different rows need different pages, sections, or variable spacing, prepare separate PDFs or stabilize the layout before building the Bulk Fill workflow. Preview long values, blank values, and rows near the end of the CSV before export.

When a workflow can use both

Some PDFs need both paths.

A PDF can use native fields for the fields it already has, and overlay fields for extra values the original PDF did not expose as fillable fields.

For example, a supported AcroForm might contain the main applicant fields, checkboxes, and dropdowns. The same workflow might also need a row-specific internal ID, batch code, label, or note in a place where the original PDF has no native field.

This mixed workflow still has boundaries. Overlay fields are not arbitrary PDF editing. They do not create new native fields, change existing native field definitions, or remove source content.

Where XFA fits in

XFA is not the same as standard AcroForm. Some XFA PDFs may look like ordinary fillable PDF forms, but they can behave very differently from supported non-XFA AcroForm PDFs.

Doqlo native form filling is scoped to supported non-XFA AcroForm fields. If your PDF is XFA, it may need to be flattened or otherwise prepared before it fits a standard Bulk Fill workflow. XFA will be covered separately because it is a different compatibility problem from ordinary flat PDFs.

In practical terms, treat XFA as a compatibility question before you plan the mapping. If the document can be prepared as a stable visual layout, an overlay workflow may be the workable path.

How to choose the right fill method

Use this decision path before you map fields:

1. Does the PDF have supported native fields? Start with native AcroForm filling when supported fields exist and match the values you need.

2. Are some needed values missing from the native fields? Add overlay fields for those positions.

3. Does the PDF have no usable native fields but the layout is stable? Use overlay fields and map them to CSV columns.

4. Is the PDF XFA or does the layout change per row? Prepare the PDF first or use a different workflow.

The useful question is "what structure does this PDF already provide?" Native filling uses existing supported field structure. Overlay filling uses stable visual layout.

Common mistakes to avoid

• Assuming every visible blank is a native PDF form field
• Trying native filling on a flat PDF
• Using overlay fields on a layout that changes per row
• Expecting overlay fields to create native PDF form fields
• Expecting overlay fields to remove or hide underlying content
• Skipping preview and test export
• Changing CSV columns after mapping without reviewing the setup again
• Treating XFA as ordinary AcroForm

These mistakes are usually avoidable with a short test run. Map a small number of fields, preview several rows, and export one test PDF before building the full workflow.

Limitations

Native filling is scoped to supported non-XFA AcroForm fields. Native filling is for supported existing text fields, checkboxes, single-select dropdowns, and radio groups. It does not create new native fields or turn a flat PDF into a native PDF form.

Overlay filling requires a stable visual layout. Overlay fields place values visually; they do not create native PDF form fields.

Overlay fields do not remove or rewrite existing PDF content. They can place values over the page, but they are not a secure content-removal tool.

Doqlo does not infer every mapping from arbitrary PDFs. You should review fields, map columns deliberately, preview representative rows, and export a test PDF before running the full batch.

Some XFA PDFs may need preparation before they fit a standard workflow. If the PDF cannot be used as a supported native AcroForm and cannot be prepared as a stable visual layout, it may not be a good fit for Bulk Fill.

Next steps

If you already know your PDF has supported native fields, start with a native Bulk Fill setup. If the PDF is flat or missing the fields you need, test an overlay workflow with a small CSV first.

For related workflows, read Fill Flat PDFs with Overlay Fields, Fill PDF Forms from Excel or CSV, PDF Mail Merge, and the Bulk Fill Overview.