Bulk HTML to PDF: Batch Convert Thousands of Files by API

The converter at the top of this page renders a single file entirely in your browser, free and without a signup. It is the right tool for a one off. But the moment you have a folder of 500 invoices, a nightly export of statements, or a content pipeline turning thousands of articles into PDFs, clicking through them by hand stops being an option, and so does keeping a browser tab open long enough to finish.

Batch conversion is a server job. You want a process that reads a list of files or URLs, converts each one, handles the ones that fail without stopping the whole run, and writes the results somewhere durable. That is a loop plus a rendering engine, and the hard part has always been the engine, not the loop.

A batch run is one of four ways documents get generated automatically, and it is the one that breaks hardest because everything works fine in testing with five files. The guide to automating PDF generation covers all four patterns and where each one fails.

The pattern is simple. Build your list of inputs, then send each one to the render endpoint, running several in parallel to keep the batch fast without overwhelming anything. Because the browser fleet lives on the API side, you are not babysitting Chromium processes or watching memory climb; you send requests and collect files.

Concurrency is the one dial that matters. Fire all 5,000 requests at once and you will hit rate limits and time outs; send them one at a time and a big batch drags on for an hour. A pool of roughly 5 to 20 in flight at a time is the usual sweet spot, tuned to your plan. Each response comes back with the PDF and, if you asked for it, a timestamped archive id. If a single document fails, you retry that one rather than the batch. This is the same render path documented on the URL to PDF API and convert HTML to PDF pages, run in a loop.

Bulk generation is exactly where records matter most, because volume is where disputes and audits eventually surface. If you render 10,000 statements a month, the odds that someone asks about one of them approach certainty. Most batches of that size run on a timer rather than a button, and running report generation on a schedule covers the job design that keeps a monthly run idempotent and safe to retry. Add archive=true to each render in the batch and every document is stored as a timestamped snapshot under your account, retrievable by id, with retention you control. A bulk run then produces two things at once: the files your users need, and the record your auditor will want. The compliance archiving guide covers what to keep and how long.

You can, and for small steady batches it is fine. The trouble is that batch load is exactly what exposes a self hosted browser fleet: Chromium leaks memory and leaves zombie processes, a big run spikes RAM until the box falls over, and you end up building a queue, a process reaper, and a restart policy before the batch is reliable. That engineering is real and recurring. We break the true cost down in the library versus API comparison and in the Puppeteer alternative page. An API absorbs the fleet operations so your batch script stays a batch script.