What is the best way to generate PDFs in a web app?

For most teams, rendering HTML and CSS with a headless browser gives the best balance of design flexibility and developer familiarity. Libraries suit simple documents and hosted services suit teams avoiding infrastructure.

Why should PDF generation run in the background?

Rendering can be slow and memory heavy. Running it on a queue keeps web requests fast, allows retries, and prevents spikes from slowing down other users.

How do I handle the rupee symbol and regional fonts?

Embed the fonts you need directly in the template instead of relying on server fonts, and test with real names and addresses in the scripts your customers use.

How should generated PDFs be stored securely?

Keep them in private cloud storage and share them through short-lived signed links. Decide a retention period that matches your privacy commitments.

What happens if I find a template bug after many documents are created?

Keep the source data and a template version for each file so you can regenerate affected documents and explain differences between old and new versions.

PDF Generation in Web Apps: Invoices, Reports and Certificates

Sooner or later, almost every business app needs to produce a PDF. An invoice for a customer, a monthly report for a client, a certificate for a student, a quotation for a prospect, or a signed agreement for a vendor. It sounds simple until you try it. Fonts render differently, tables split across pages in ugly places, Indian rupee symbols go missing, and the generation job that worked in testing times out the moment real data arrives.

This guide walks through the main approaches to PDF generation in web apps, how to choose between them, and how to build a pipeline that stays reliable as volume grows. It is written for founders and product teams who want documents that look professional without a fragile tangle of workarounds.

Why PDFs are harder than they look

A PDF is a fixed-layout format designed for printing. A web page is a flowing layout designed for screens of every size. Turning one into the other involves decisions about page size, margins, page breaks, headers, footers, fonts, and images. Each decision can go wrong in a way that only shows up with real content, such as a customer with a very long company name or an order with sixty line items.

There is also a business angle. Documents like invoices and contracts carry legal and financial weight. Mistakes in totals, missing tax details, or a broken layout reflect directly on your credibility. So it is worth treating document generation as a proper feature with tests, not a quick afterthought.

The three main approaches

1. HTML to PDF with a headless browser

You design the document in HTML and CSS, then render it with a headless browser engine that prints it to PDF. This is the most popular approach because web developers already know the tools, and the result matches what a browser would show. It handles modern CSS, web fonts, and complex layouts well. The trade-offs are memory use, since a browser is heavy, and the need to manage a pool of rendering workers if volume is high.

2. Programmatic PDF libraries

Libraries let you build a PDF by code, placing text, tables, and images at defined positions. They are lightweight and fast, and they produce small files. The downside is that layout becomes your job. Wrapping text, flowing tables across pages, and keeping a consistent design means writing more code, and designers cannot easily change the template without a developer.

3. Template-based or hosted document services

Some services let you upload a template and send data to receive a finished PDF. They remove infrastructure work and are useful for teams that want speed. The costs are per-document fees, a dependency on an outside vendor, and the need to review where customer data is sent and stored.

Real-world example: invoices for a small distribution business

Picture a distribution company with a few hundred customers. Staff currently export orders to a spreadsheet, copy numbers into a document template, and email PDFs by hand. Mistakes creep in, and the process takes someone half a day each week.

The team moves to an app that generates invoices automatically when an order is marked delivered. The invoice template lives as an HTML file with placeholders. A background job fills it with order data, renders it to PDF with a headless browser, stores the file in cloud storage, and emails a secure link to the customer. For example, a business like this might reclaim several hours a week and reduce re-issued invoices, though the actual savings depend on volume and how error-prone the old process was. For Indian businesses, this approach also fits naturally with GST e-invoicing automation, since the same data that feeds the tax portal can feed the printed document.

Step-by-step: building a reliable PDF pipeline

Decide the document types and owners. List every document your product must produce and who is allowed to change its design. A clear owner prevents template sprawl.
Choose the generation approach. For most web apps, HTML to PDF is the best starting point. Choose a library for very simple documents and a hosted service when you want to avoid running infrastructure.
Design the template for print. Use a print stylesheet, set the page size explicitly (A4 for India), define margins, and add rules to avoid breaking rows or headings across pages.
Embed fonts. Include the fonts you need, including support for the rupee symbol and any regional scripts. Never rely on fonts installed on the server.
Generate in the background. Do not render PDFs inside the web request. Put the job on a queue, return quickly to the user, and notify them when the file is ready.
Store files safely. Save the output in private cloud storage and serve it through short-lived signed links. Keep the original data used to generate it so you can regenerate the document if needed.
Handle failures and retries. Rendering can time out or crash. Retry a limited number of times, log the failure with the document ID, and alert the team if a backlog builds.
Test with ugly data. Run the template against very long names, special characters, empty fields, and large item counts. Compare outputs visually with snapshot tests.

Getting the layout right

Good PDFs follow a few design habits. Repeat table headers on each page so a long list stays readable. Keep totals together in a block that never splits across pages. Place page numbers and document IDs in the footer so printed copies can be traced. Use consistent spacing, and avoid tiny fonts that become illegible when printed. If your documents include a logo, supply it at high resolution in a vector format when possible.

Performance and scale

If you generate a handful of documents a day, almost any approach works. If you produce thousands at month end, plan for it. Run rendering workers separately from your main application so a spike does not slow down users. Reuse browser instances where possible, because starting a fresh browser for every file is slow. Cache static assets like fonts and logos. And consider generating documents ahead of time when you know a batch is coming, rather than on demand.

Security and privacy considerations

PDFs often contain sensitive information, so treat them accordingly. Never place document links on public, guessable URLs. Use signed links that expire. If you accept user content in templates, sanitise it so nobody can inject scripts or load external resources during rendering. Restrict the rendering environment from reaching your internal network, since a headless browser can follow links. Finally, decide how long to keep generated files, and align this with your data retention commitments.

Key benefits of automating PDF generation

Fewer manual errors. Data flows from the system of record to the document with no copy and paste.
Consistent branding. Every invoice, report, and certificate looks the same and reflects your standards.
Faster cash collection. Invoices that go out automatically on delivery tend to arrive sooner than those waiting in someone's queue.
Audit trails. Stored documents with their source data make disputes and audits much easier to resolve.
Staff time back. People who used to assemble documents can focus on work that needs judgement.

The same foundation extends to contracts, proposals, and onboarding packs. Our article on document generation and contract automation for SMEs shows how to add approvals and e-signature steps on top of a solid PDF pipeline.

A document is often the only part of your software that a customer's accountant, lawyer, or manager ever sees. It deserves the same care as your homepage.

Common mistakes to avoid

Generating inside the web request. It blocks users and fails under load.
Forgetting to version templates. Without versions, you cannot explain why an old invoice looks different from a new one.
Recalculating totals in the template. Compute amounts once in your business logic and pass the final values in. Duplicate math invites mismatches.
Ignoring accessibility. Tagged PDFs with readable text help screen reader users and improve searchability.
No regeneration plan. Decide in advance what happens when a template bug is found after thousands of files exist.

When to get help

If documents are central to your product, such as a compliance tool, a fintech platform, or a school management system, it pays to get the architecture right early. Our team builds document workflows as part of broader web development projects, and we are happy to review an existing setup that has become slow or fragile.

A quick checklist before you ship document generation

Does every template have a named owner and a version number?
Have you tested very long names, empty fields, and large item counts?
Are fonts embedded, including the rupee symbol and any regional scripts?
Do background jobs retry safely without creating duplicate documents?
Are files private, with expiring links and a retention rule?
Can you regenerate any past document from stored source data?

Working through this list before launch is far cheaper than discovering the gaps after a customer has complained about a broken invoice.

Conclusion

PDF generation looks like a small task but touches layout, performance, security, and compliance. Start with HTML to PDF for flexibility, render in background workers, embed your fonts, store files privately, and test with messy data. Keep totals calculated in one place, and version your templates. Do that, and your invoices, reports, and agreements will look professional, arrive on time, and stop eating hours of manual effort every week.

Frequently Asked Questions

What is the best way to generate PDFs in a web app?: For most teams, rendering HTML and CSS with a headless browser gives the best balance of design flexibility and developer familiarity. Libraries suit simple documents and hosted services suit teams avoiding infrastructure.
Why should PDF generation run in the background?: Rendering can be slow and memory heavy. Running it on a queue keeps web requests fast, allows retries, and prevents spikes from slowing down other users.
How do I handle the rupee symbol and regional fonts?: Embed the fonts you need directly in the template instead of relying on server fonts, and test with real names and addresses in the scripts your customers use.
How should generated PDFs be stored securely?: Keep them in private cloud storage and share them through short-lived signed links. Decide a retention period that matches your privacy commitments.
What happens if I find a template bug after many documents are created?: Keep the source data and a template version for each file so you can regenerate affected documents and explain differences between old and new versions.