Benchmarking 12 HTML-to-PDF APIs Across 14 Rendering Checks

We sent the same 4-page HTML invoice to 12 PDF generation APIs and checked every page that came back against 14 rendering checks, plus speed and file size. PDFGate and DocRaptor passed all 14, with DocRaptor using a version of the page written for its Prince engine. Everything we used, the HTML, the script, and all the output PDFs, is public, so you can rerun it yourself.

---

Results at a glance

API	Checks passed	Average time	File size	Fillable fields	Average time with fields
PDFGate	14/14	1.5 s	227 KB	✅	2.1 s
DocRaptor	14/14 (own HTML version)	2.8 s*	90 KB	✅	3.0 s*
PDFShift	13/14 (print styles on)	1.9 s	271 KB	❌	—
PDFCrowd	13/14	3.0 s	293 KB	✅	2.9 s
APITemplate.io	13/14 (backgrounds on)	3.2 s	312 KB	❌	—
Browserless	13/14	3.3 s	319 KB	❌	—
PDFMonkey	13/14 (own HTML version)	3.7 s	227 KB	✅	9.5 s
Api2Pdf	13/14	4.2 s	310 KB	❌	—
ConvertAPI	13/14 (print settings on)	4.3 s	308 KB	❌	—
PDF.co	13/14	10.0 s†	262 KB	❌	—
CloudConvert	12/14	1.8 s	289 KB	❌	—
cloudlayer.io	12/14	2.1 s	360 KB	❌	—

We ran these tests in October 2026. The table is sorted by score, then by speed. Each time is the average of at least five requests without fillable fields, so every API is compared the same way. The last column shows the four APIs that can create fields, with fields on.

• *DocRaptor's free plan only gives you five real documents a month, so we timed it in test mode and used one real document for the output (3.8 seconds).
• †PDF.co's normal mode timed out on our invoice, so we used its async mode, where you start a job and check back until it's done. The time includes those checks.

Test breakdown:

A check passes if what it tests shows up in the PDF. For the text row, every character has to be visible: black-and-white emoji still pass, empty boxes don’t. For the chart, it only has to appear. For forms, all three inputs have to become fields you can type into. Every PDF the APIs produced is in the repository (github.com/pdfgate/pdf-generation-api-benchmark, folder results).

How we tested

Feature pages tell you what an API supports, not what your document will look like. So we built the test around one realistic document: a 4-page invoice, where every section checks one thing that tends to break when HTML becomes a PDF.

• Layout: CSS grid, a gradient background, box shadows and an inline SVG logo.
• Page breaks: a forced break, a table header that should repeat, a block that must not split, and a "Page X of Y" footer built with CSS @page rules.
• JavaScript: totals calculated on load and a bar chart drawn on a canvas.
• Text: the Inter web font, plus Greek, Japanese, right-to-left Arabic and emoji.
• Forms: a text box, a dropdown and a checkbox.

Every API got the same HTML, with the options its own documentation offers for print documents: A4 paper, backgrounds on, JavaScript on, fillable fields on where available, and print styles on for PDFShift and ConvertAPI. Every check was pass or fail against a reference render from plain headless Chrome. Two APIs needed their own version of the page: DocRaptor, because its Prince engine is not a browser and needs ES5 JavaScript, flexbox and its own form rule, and PDFMonkey, because its fillable fields need text markers instead of inputs. Writing a separate version is part of the cost of choosing them.

Where the APIs differed

Everyone passed the web font, CSS variables, shadows, the SVG logo, the forced page break and the block that must not split.

Emoji and international text

Japanese rendered everywhere, because our page loads a Japanese web font. Emoji and Arabic, which the page loads no font for, were a different story.  CloudConvert printed the emoji as empty boxes, PDF.co and PDFCrowd printed them in black and white, and PDFMonkey printed the Arabic line as empty boxes. The fix is usually a web font that covers the characters. For emoji, "Noto Color Emoji" from Google Fonts works on any Chrome-based API.

JavaScript and charts

Every Chrome-based API ran our JavaScript, filled in the totals and drew the chart. DocRaptor did neither with the browser version of the page, because Prince doesn't support full ES6. The ES5 rewrite fixed both. One difference you only see when you zoom in: Chrome stores a canvas in the PDF as a picture, so on every Chrome-based API our chart looks soft when printed or enlarged, while Prince redraws it as vector shapes. For sharp charts on Chrome, draw the canvas at two or three times its display size, or use SVG.

Page numbers and repeating headers

Two APIs left out the "Page X of Y" footer on every page. cloudlayer.io runs Chrome 107, which predates support for CSS page margin boxes. PDFCrowd reports a current Chrome but still drops them, even when told to follow the page's @page rules; it expects you to use its own footer_html option. The repeating table header worked everywhere.

Text you can copy and search

This wasn't one of our 14 checks, but we noticed it while reading the PDFs back. In the files from cloudlayer.io and PDFCrowd, the invoice amounts look correct on screen, but in the text layer they're empty characters: copy them, search for them or parse them with software, and you get nothing. Every other API produced a clean text layer.

Fillable form fields

Most APIs print form inputs as flat boxes. Only four of the 12 produced real fields, and not in the same way. PDFGate and PDFCrowd turn your existing <input>, <select> and checkbox elements into fields with a single option (enableFormFields and enable_pdf_forms). DocRaptor needs a Prince CSS rule on the inputs, and PDFMonkey needs its own text markers instead of inputs. The other eight have no option for it in HTML to PDF.

One thing you’ll notice in PDFGate’s output is that the form fields have no visible border. PDFGate replaces each HTML input with a transparent PDF field, so the input’s own border is dropped. If you want a box around a field, wrap the input in an element and put the border on the wrapper.

Speed and file size

PDFGate was the fastest API in our test at 1.5 seconds, followed by CloudConvert (1.8 seconds) and PDFShift (1.9 seconds). PDF.co (10.0 seconds) was the slowest and varied the most, from 5.4 to 16.1 seconds. Turning fillable fields on adds about half a second for PDFGate, almost nothing for DocRaptor and PDFCrowd, and close to six seconds for PDFMonkey. File sizes ranged from 90 KB for DocRaptor, whose Prince engine writes very compact PDFs, to 360 KB for cloudlayer.io. Speed depends on where you call from, so read these numbers as a comparison between APIs, not a promise for your own servers.

The 12 PDF generation APIs

Prices below are for monthly billing in each provider's own currency, checked in October 2026.

PDFGate · from $9/month. Converts HTML and URLs with Chrome, then adds fillable fields, compression, watermarks, password protection, form data extraction and e-signatures under the same API. It passed every check with the standard page. It doesn't support async mode with webhooks or PDF/A output, and has a 14-day trial instead of a free plan.

DocRaptor · free for 5 documents/month, then from $15/month. Built on the Prince print engine. With the rewritten page it returned the nicest file in the test: a vector chart, the smallest file, and print features browsers don't have, like footnotes and PDF/UA output. The trade-offs are the extra HTML work and the highest price per document here.

PDFShift · 50 free credits/month, then from $9/month. A focused Chromium API that matched our reference with print styles on (use_print), except for the form. Adds async conversion with webhooks, upload to S3 or Google Cloud Storage, image output, watermarks and password protection.

PDFCrowd · 100 test credits, then from $1/month. Creates fillable fields from plain HTML inputs and adds PDF/A and tagged PDFs. Page numbers have to be rebuilt with its own footer option.

APITemplate.io · 50 free PDFs/month, then from $24/month. Mainly a template service that also converts raw HTML, URLs and Markdown, with four data regions to choose from. With backgrounds on (print_background) it matched our reference except for the form. No fillable fields, password protection or watermarks from the API.

Browserless · 1,000 free units/month, then from $35/month. A hosted browser rather than a PDF service; its /pdf endpoint behaved exactly like plain Chrome, with only the form flat. You pay per block of browser time, and get screenshots, scraping and full Puppeteer or Playwright automation in the same account.

Api2Pdf · $1/month plus usage. Headless Chrome billed by bandwidth and compute time; each of our invoices cost $0.0008. Its time includes downloading the file from the link it returns. Files are deleted after 24 hours, and there's no fillable field support.

ConvertAPI · 250 free conversions, then from €30/month. A general conversion service with hundreds of converters. Its Chromium converter matched our reference with print settings on, apart from the form. Strong on compliance (ISO 27001, SOC 2, HIPAA, EU and US regions), but every extra step like PDF/A or watermarks is a separate conversion with its own cost.

PDFMonkey · 20 free documents/month, then from €5/month. Template-based, cheap and hosted in the EU. Fillable fields need its own text markers, which it couldn't find in the Inter web font; it took four rounds to get a clean form, and fields nearly triple the conversion time.

PDF.co · from $8.99/month billed annually. A broad PDF toolkit with editing, merging and data extraction next to HTML to PDF, on a Chrome 108 renderer. Every status check on an async job costs 2 credits, so one invoice used 9 credits to convert and 36 to check on it.

CloudConvert · 10 free conversions/day, then from €9.52/month. Converts almost any file format. Every conversion is a job of import, convert and export tasks, which you can chain with PDF/A, encryption and merging, in a German or US region.

cloudlayer.io · 30-day trial, then from $49/month. Generates PDFs and images from HTML, URLs and templates, with a visual editor, on a Chrome 107 renderer. The $49 entry price is high for small projects.

Which one should you choose?

Need	APIs to consider
HTML invoices with JavaScript and charts	PDFGate, PDFShift, Browserless
Editable forms and document signing	PDFGate; PDFCrowd for forms alone
Books, print layouts and PDF accessibility	DocRaptor
High volume with usage-based pricing	Api2Pdf, CloudConvert
Office/document format conversion and compliance	ConvertAPI
Templates managed by non-developers	PDFMonkey, APITemplate.io
PDF generation inside browser automation	Browserless

Test it with your own documents

No benchmark can tell you how your own documents will come out. Before you commit, run your three most complex real documents through your top two candidates, and check the fonts, the page breaks and the last page, because that's where most problems hide. Our test document and script are public at github.com/pdfgate/pdf-generation-api-benchmark, so you can swap in your own HTML and compare. For a closer look at HTML to PDF features like page breaks, headers and cookie banners, see our full comparison of HTML to PDF APIs.

---