Workflow 8 min read 21 October 2026

PDF Mail Merge: Generating Personalised PDFs at Scale

Q: Can I generate PDF/A-compliant personalised PDFs programmatically?

Yes, with the right tools. iText (Java) : Use PdfADocument instead of PdfDocument and specify the conformance level (PDF/A-1b, PDF/A-2b, etc.). iText handles the compliance constraints (font embedding, colour profiles, metadata). PDFBox (Java) : Generate a standard PDF and then validate/convert with callas pdfaPilot or veraPDF. Ghostscript : Convert generated PDFs to PDF/A-2b using gs -dPDFA=2 -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -sColorConversionStrategy=UseDeviceIndependentColor -dPDFACompatibilityPolicy=1 . For JavaScript/Node.js, pdf-lib does not natively support PDF/A output — programmatic PDF/A generation in JavaScript requires more complex tooling or a conversion step via Ghostscript or LibreOffice.

Mail merge for PDFs — generating hundreds of personalised documents from a data source — is a common enterprise need. This guide covers AcroForm field population with FDF/XFDF, template-based generation with iText and Apache PDFBox, Word-to-PDF mail merge pipelines, and cloud services for bulk personalised PDF generation.

PDF mail merge — generating batches of personalised PDFs from a data source — is one of the most common document automation tasks in business. The same template needs to become hundreds of customised certificates, invoices, contracts, letters, or reports, each filled with different recipient data. Despite being common, it is technically fragmented: there is no single universally supported "PDF mail merge" standard. Depending on your tools and template approach, the technique may involve AcroForm field population, programmatic PDF generation from scratch, HTML-to-PDF rendering, Word-to-PDF conversion, or cloud document generation APIs. This guide covers each approach — when to use it, how to implement it, and what the tradeoffs are.

AcroForm field population with FDF and XFDF

The most standards-aligned approach to PDF personalisation uses AcroForm fields in the template PDF and populates them programmatically: Template preparation — Create the PDF template with AcroForm text fields placed where personalised data should appear. Each field has a /T (title) value that serves as the field name — the key used to set its value programmatically. In Acrobat Pro: Tools > Prepare Form to add and configure fields. For programmatic template creation, use pdf-lib, iText, or PDFBox. FDF (Forms Data Format) — FDF is a file format that contains field name/value pairs for a specific PDF form. An FDF file references the PDF template and provides the values for each field. The PDF viewer merges the FDF data into the template. FDF is simple (flat structure, easy to generate programmatically) but limited to text fields, checkboxes, and radio buttons. XFDF (XML Forms Data Format) — XFDF is the XML-based equivalent of FDF, more widely supported in modern tools. It provides the same field population capability with better Unicode support and more complete annotation handling. Generating populated PDFs — For bulk generation without user interaction: - **pdf-lib (JavaScript)**: form.getTextField('recipientName').setText(name) then save - **pypdf (Python)**: Fill field values via writer.update_page_form_field_values() - **iText (Java/.NET)**: form.setField("recipientName", name) - **pdftk (command-line)**: pdftk template.pdf fill_form data.fdf output output.pdf flatten The final step — flatten — converts the interactive form fields to static content. This prevents recipients from editing the populated values.

Programmatic PDF generation from scratch

For complex layouts, dynamic content length, or content that doesn't fit a fixed-template model, generating the entire PDF programmatically from a data source is more flexible: pdf-lib (JavaScript/Node.js) — Draw text, images, shapes, and set positions programmatically. Excellent for client-side browser generation (as in this editor) and Node.js server-side generation. For mail merge, iterate over records and generate one PDF per record (or all pages in one PDF using separate page additions). ReportLab (Python) — A mature Python library for programmatic PDF generation. The Platypus framework provides flow-based layout similar to HTML/CSS. Excellent for data-driven reports, certificates, and any document where content length varies by record. iText/PDFBox (Java) — Enterprise-grade programmatic PDF generation with comprehensive font support, table layout, and Unicode handling. iText is the standard choice for Java-based enterprise document generation pipelines. Puppeteer/wkhtmltopdf (HTML-to-PDF) — Generate personalised HTML using a template engine (Handlebars, Jinja2, Mustache) and convert to PDF. Puppeteer uses Chromium's rendering engine, producing high-quality output with excellent CSS support. This approach is fastest for developers comfortable with web technologies and is particularly good for complex layouts that would be tedious to reproduce with a drawing API. Tradeoffs: AcroForm population is simplest for fixed templates. Programmatic generation is most flexible. HTML-to-PDF conversion provides the best developer experience for complex layouts but produces larger files and limited PDF/A compliance.

Cloud PDF generation services and batch processing at scale

For high-volume generation (thousands of documents per day), cloud services provide infrastructure, monitoring, and compliance features that would be expensive to build internally: DocSpring, PDFco, Pdfcrowd — Template-based cloud PDF generation APIs. Upload a template PDF, define field mappings, and call the API with data records. Services handle scaling, storage, and delivery. Adobe Document Generation API — Uses Word DOCX templates with JSON data. The service populates the template with data and converts to PDF. Well-suited for organisations already using Adobe Sign and Acrobat Sign for document workflows. AWS, Azure, GCP document processing — Cloud providers offer document processing services that can be combined: generate HTML from templates, render to PDF with headless Chrome, store in object storage, and send via SES/SendGrid. This approach requires more assembly but provides the most control. FDF/XFDF generation and delivery — For organisations already using Acrobat as the viewer, generating XFDF data files and distributing them alongside the template PDF via email or a document management system is a low-infrastructure approach — the recipient's Acrobat populates the form when they open the FDF file. Accessibility consideration — Programmatically generated PDFs for distribution to large audiences should include PDF tags for accessibility. Both pdf-lib (with the tagged PDF extension) and ReportLab (with the rlPyCairo backend) can produce tagged output. iText is the most mature for tagged programmatic PDF generation.

Frequently asked questions

What is the difference between filling a PDF form and flattening it?

Filling a PDF form means setting the values of AcroForm or XFA form fields — text fields, checkboxes, radio buttons, dropdowns — while keeping the fields interactive. The document remains a live form that can be opened and re-edited in a PDF viewer. Flattening a filled form converts the interactive field annotations into static page content — the filled values become ordinary text drawn on the page, and the form fields are removed. Flattened forms cannot be re-edited. For distributing completed forms (certificates, invoices, personalised letters), flattening is appropriate — it prevents recipients from altering the filled values. For distributing forms intended to be completed by recipients, do not flatten. The pdftk command flatten option and Acrobat Pro's flatten option both perform flattening.

How many personalised PDFs can I generate per minute with pdf-lib in Node.js?

This depends heavily on document complexity, but for simple single-page AcroForm fill-and-flatten operations, pdf-lib in Node.js can typically process 200–500 documents per minute on a standard server. For complex documents with many images, large fonts, or many pages, throughput drops proportionally with document complexity. For higher throughput, consider: parallel processing across multiple Node.js workers (using worker_threads or separate processes); preprocessing the template to load fonts and resources once rather than per document; using streaming output to avoid loading the full output PDF into memory. For very high volume (tens of thousands per hour), consider iText or PDFBox on a Java backend, which have more optimised PDF generation internals, or cloud PDF generation services with auto-scaling.

Can I generate PDF/A-compliant personalised PDFs programmatically?

Yes, with the right tools. iText (Java): Use PdfADocument instead of PdfDocument and specify the conformance level (PDF/A-1b, PDF/A-2b, etc.). iText handles the compliance constraints (font embedding, colour profiles, metadata). PDFBox (Java): Generate a standard PDF and then validate/convert with callas pdfaPilot or veraPDF. Ghostscript: Convert generated PDFs to PDF/A-2b using gs -dPDFA=2 -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -sColorConversionStrategy=UseDeviceIndependentColor -dPDFACompatibilityPolicy=1. For JavaScript/Node.js, pdf-lib does not natively support PDF/A output — programmatic PDF/A generation in JavaScript requires more complex tooling or a conversion step via Ghostscript or LibreOffice.

Try it yourself

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

Edit PDF Fill PDF Form Sign PDF Open editor