Best HTML to PDF APIs in 2026, Compared on Quality and Reliability

An HTML page can look fine in a browser and still produce a broken PDF. A chart might be missing because its data arrived too late. A long table might split badly, or a page number might disappear from the footer. When an application creates hundreds of documents automatically, these mistakes are easy to miss.

Choosing an HTML to PDF API involves more than checking whether it accepts HTML or a URL. You need to know when it decides a page is ready, how it handles printed layouts and what happens when requests fail or usage grows.

This article compares 12 hosted services using features, limits and prices documented as of 5 November 2026. It examines their capabilities rather than reporting a new speed or uptime test.

The APIs at a glance

PDFGate

• Rendering engine: Chrome
• Ways to wait for content: Selector, network idle, delay, images, clicks
• Headers and footers: HTML templates with page numbers
• Access to restricted pages: HTTP authentication, custom headers
• Published processing limit: Up to 15 minutes for page loading

ConvertAPI

• Rendering engine: Chrome
• Ways to wait for content: Selector, delay, lazy content
• Headers and footers: HTML templates with page numbers
• Access to restricted pages: Cookies, headers, basic auth
• Published processing limit: 120 seconds by default, up to 1,200

Browserless

• Rendering engine: Chrome
• Ways to wait for content: Selector, network idle, delay, JS function, event, fonts
• Headers and footers: HTML templates with page numbers
• Access to restricted pages: Cookies, headers, basic auth, saved profiles
• Published processing limit: Paid session limits of 15 to 60 minutes

PDFShift

• Rendering engine: Chrome
• Ways to wait for content: JS function, network idle, delay, lazy images
• Headers and footers: HTML templates with page numbers
• Access to restricted pages: Cookies, headers, basic auth
• Published processing limit: 100 seconds by default, up to 900

PDFCrowd

• Rendering engine: Not published
• Ways to wait for content: Selector, delay
• Headers and footers: HTML templates with per-page rules
• Access to restricted pages: Cookies, headers, basic auth
• Published processing limit: 60 seconds per conversion

DocRaptor

• Rendering engine: Prince
• Ways to wait for content: JavaScript completion function
• Headers and footers: CSS paged media
• Access to restricted pages: Basic auth
• Published processing limit: 1 minute synchronous, 10 minutes asynchronous

Api2Pdf

• Rendering engine: Chrome
• Ways to wait for content: Selector, network idle, delay, JS expression
• Headers and footers: HTML templates with page numbers
• Access to restricted pages: Custom headers
• Published processing limit: 90 seconds, or 5 minutes on V2 XL

CloudConvert

• Rendering engine: Chrome
• Ways to wait for content: Selector, network idle, delay
• Headers and footers: HTML templates with page numbers
• Access to restricted pages: Custom headers on URL capture
• Published processing limit: Async jobs, 5-hour default task timeout

cloudlayer.io

• Rendering engine: Chrome
• Ways to wait for content: Selector, network idle, delay, auto scroll
• Headers and footers: Header from an HTML element
• Access to restricted pages: Cookies, basic auth
• Published processing limit: 30 seconds by default, maximum not published

PDF.co

• Rendering engine: Chrome
• Ways to wait for content: Full or minimal page load
• Headers and footers: HTML templates with page numbers
• Access to restricted pages: Basic auth listed in API tester
• Published processing limit: 30 seconds synchronous

APITemplate.io

• Rendering engine: Chrome
• Ways to wait for content: Fixed delay
• Headers and footers: HTML templates with page numbers
• Access to restricted pages: None documented
• Published processing limit: 100 seconds in main regions

PDFMonkey

• Rendering engine: Chrome
• Ways to wait for content: No explicit waits documented
• Headers and footers: Settings, CSS counters or Paged.js
• Access to restricted pages: Templates only, no URL input
• Published processing limit: 30 seconds to 5 minutes by plan

he published processing limits are not a direct speed comparison. Some figures describe page loading, while others refer to entire requests, browser sessions or asynchronous jobs. None of them establishes how often a service is available.

Waiting for JavaScript and images

Imagine generating a report from a dashboard. The page opens, but its charts still need to fetch data and draw themselves. If the API prints immediately, the PDF may contain empty chart areas.

A fixed delay can help, but it makes you guess how long the page needs. Waiting for a CSS selector is more predictable when you control the HTML. For example, your application could add #report-ready after all charts finish rendering. Network idle waits are useful too, although a quiet network does not guarantee that every script has finished.

PDFGate supports waitForSelector, waitForNetworkIdle and a delay of up to 20 seconds. Its loadImages option scrolls to trigger lazy-loaded images and waits for image elements to load. It can also click an element with clickSelector or follow several clicks with clickSelectorChainSetup. Those actions are helpful when a cookie banner or dialog covers the content.

Browserless offers more readiness controls through its /pdf endpoint, including JavaScript functions, custom events and font loading. Its browser sessions provide further control when a page requires complex interaction. PDFShift and Api2Pdf can wait for JavaScript conditions, while PDFShift also scrolls to load images.

ConvertAPI can wait for elements, hide unwanted content and adjust page breaks around selected elements. PDFCrowd supports wait_for_element and JavaScript hooks. DocRaptor, which uses Prince rather than Chrome, can poll docraptorJavaScriptFinished() after JavaScript is enabled. APITemplate.io documents a fixed delay, PDF.co offers full or minimal page loading, and PDFMonkey does not document equivalent waits for its templates.

For websites you do not control, consent banners are another problem. ConvertAPI, Browserless and CloudConvert provide options to block or dismiss common banners. Those features are convenient, but they may not work with every site's implementation.

Headers, footers and page numbers

Page numbers become difficult when a report can contain ten pages one day and a hundred the next. Most Chrome-based APIs address this through separate HTML templates for headers and footers. Classes such as pageNumber and totalPages let Chrome insert the correct values.

PDFGate, Browserless, Api2Pdf, CloudConvert, PDF.co, APITemplate.io and ConvertAPI support this approach. Because Chrome renders those templates separately, styles from the document body do not automatically apply. You usually need inline styles and enough page margin for the footer.

PDFShift offers page number placeholders and can start headers on a later page. PDFCrowd supports different rules for selected pages, while cloudlayer.io can use an element from the document HTML as a header.

DocRaptor takes another approach. Prince supports CSS paged media, including @page margin boxes, distinct first pages and different headers for different sections. That makes it especially useful for books and long reports, although you need to test the layout in Prince rather than assume Chrome will render it identically. PDFMonkey offers paged media features through Paged.js on paid plans.

Chrome has added CSS margin box support, but provider behavior can differ. In an open benchmark of 12 HTML to PDF APIs, two outputs omitted a footer built with @page rules. If page numbering matters, test the actual template instead of relying on a feature label.

Converting pages behind a login

An internal dashboard is different from a public webpage. The rendering API needs permission to access it, usually through cookies, HTTP headers or basic authentication.

Browserless supports those options and saved browser profiles that retain cookies and local storage. ConvertAPI, PDFShift and PDFCrowd document cookies, custom headers and basic authentication. PDFGate supports HTTP authentication, custom request headers and a custom user agent.

The choices are narrower elsewhere. cloudlayer.io documents cookies and basic authentication, while Api2Pdf and CloudConvert accept custom headers for relevant URL requests. DocRaptor documents basic authentication. APITemplate.io does not document login controls for URL capture, and PDFMonkey generates documents from templates rather than loading external URLs.

If you own the application, consider generating the HTML on your server and sending it directly to the PDF API. That avoids giving a separate renderer access to a user's live session. Some sites still need a full browser login flow, which request headers alone cannot reproduce.

Fonts and multilingual documents

A missing font can change line breaks, shift a table onto another page or turn characters into empty squares. This is worth testing with Greek, Arabic, Japanese and emoji, especially when users supply some of the text.

PDFGate documents web fonts, self-hosted fonts, base64-embedded fonts and fonts added through its css option. Api2Pdf includes Noto fonts for CJK, Arabic and emoji. DocRaptor supports color emoji in newer rendering pipelines.

Other providers have practical limitations. PDFMonkey reserves external fonts for paid plans and requires emoji to be enabled per template. PDFShift recommends embedded or local fonts when external loading is inconsistent. PDFCrowd requires suitable cross-origin headers from font hosts, and ConvertAPI recommends static font files to avoid some Google Fonts issues.

Check whether the text can be selected and copied from the finished PDF, not only whether it looks right. A visually acceptable result may still be unsuitable for search or extraction.

Fillable forms, accessibility and PDF processing

A document that looks like a form is not necessarily fillable. To let someone type into the downloaded PDF, the renderer must create actual PDF form fields. PDFGate and PDFCrowd can convert HTML inputs into fillable fields. DocRaptor uses Prince-specific CSS, while PDFMonkey uses its own field markers. PDFGate also supports signature fields and an electronic signature workflow.

Archival and accessibility requirements need separate attention. DocRaptor can produce PDF/A and PDF/UA profiles directly. PDFCrowd supports PDF/A and tagged output. Api2Pdf generates tagged PDFs by default, while Browserless offers tagged output without claiming certified PDF/UA compliance. ConvertAPI, CloudConvert and PDF.co handle PDF/A through an additional conversion step. Tagged output alone does not prove accessibility compliance, so validate the completed file when a standard is required.

Document protection also varies. DocRaptor, PDFShift, PDFCrowd and PDFMonkey can encrypt files during rendering. PDFGate, ConvertAPI, PDF.co and CloudConvert offer password protection as another operation. PDF permission flags may discourage printing or copying, but they are not a guarantee that someone who can open a document cannot extract its content.

PDFShift and PDFCrowd can apply watermarks during rendering. PDFGate, ConvertAPI, CloudConvert and Api2Pdf support watermarking separately, and PDFGate, ConvertAPI, CloudConvert and PDF.co offer compression operations. If your workflow requires several of these steps, include them in your cost and latency estimates.

Reliability in production

Published API limits help you design an integration, but they do not prove uptime. For production use, consider what happens when a document takes longer than expected, your account reaches its allowance or many customers request PDFs together.

Timeouts and long documents

PDFGate permits up to 15 minutes for page loading, with the PDF returned in the same request. Selector waits and delays have their own shorter limits.

ConvertAPI starts at 120 seconds and allows settings up to 1,200. PDFShift starts at 100 seconds and allows up to 900. DocRaptor supports one minute synchronously or ten minutes asynchronously. PDFCrowd has a 60-second conversion limit, while PDF.co's synchronous limit is 30 seconds.

CloudConvert works asynchronously, with a default task timeout of five hours. PDFMonkey and cloudlayer.io also offer asynchronous workflows. Their job limits cannot be compared directly with synchronous request timeouts. cloudlayer.io's documentation reviewed for this article describes webhook delivery without retries, which matters if your system depends on receiving that callback.

Allowances and failed requests

When a service blocks requests at your monthly limit, customers may stop receiving invoices even though your application is otherwise healthy. PDFGate continues processing above the included allowance on eligible paid plans and charges $0.02 for each additional operation. DocRaptor, ConvertAPI and paid Browserless plans also support overage billing.

PDFShift requires overage to be enabled. PDFMonkey needs pay as you go enabled, Api2Pdf requires prepaid funds, PDF.co pauses when credits run out and APITemplate.io requires a plan upgrade. cloudlayer.io's published materials give conflicting answers about whether the limit blocks requests.

Failed requests are not necessarily free. PDFGate, CloudConvert and APITemplate.io state that unsuccessful conversions are not billed. ConvertAPI counts attempted conversions, while Browserless bills for the browser time consumed. Other providers did not publish a clear general rule in the material reviewed. Your application should log errors and avoid creating duplicate jobs when retrying an uncertain result.

Concurrency and file retention

Monthly invoice runs may send hundreds of jobs at once. PDFShift allows 50 parallel conversions on every plan, DocRaptor 30 and APITemplate.io 100 concurrent synchronous requests per account. PDFGate's limits range from 3 to 25 by plan, with separate allowances for different endpoints. ConvertAPI lists 1 to 4 concurrent jobs on self-service plans, while cloudlayer.io limits requests per minute rather than publishing an equivalent simultaneous-job figure.

Some services return a file without keeping it. PDFGate does not store generated API files by default, but optional storage supports retention of up to two years. PDFShift, ConvertAPI and Browserless likewise return files without default storage. Api2Pdf and CloudConvert retain outputs for 24 hours, PDF.co's generated links expire after 60 minutes, and APITemplate.io allows links without a specified expiry unless one is set. Store important documents yourself or confirm the provider's retention settings.

Understanding the price

The billing unit changes the calculation. PDFGate, DocRaptor, APITemplate.io, PDFMonkey and cloudlayer.io charge by document or operation. PDFShift and PDFCrowd use output-size-based units, PDF.co charges by page, and Api2Pdf, Browserless and CloudConvert use rendering time as an important factor.

PDFGate's documented plans include 3,000 operations for $20 a month, 10,000 for $50 and 100,000 for $300. These allowances can also cover processing tasks such as compression or encryption, not just HTML conversion. PDFMonkey offers per-document plans and paid overage, so its total cost at higher volumes depends on the allowance and extra documents.

Time-based billing can work well for quick pages but becomes harder to estimate when documents wait for images, external scripts or other services. Use a representative set of PDFs to calculate cost, including failed attempts and any extra processing operations.

Which API should you choose?

For an application that creates contracts or invoices from HTML and may later need fillable fields, processing or electronic signatures, PDFGate's HTML to PDF API is worth evaluating. Its waits, click actions and document processing features cover several steps within one service, though you should test them with your own templates.

DocRaptor is a strong candidate for sophisticated print layouts and PDF/A or PDF/UA requirements. Browserless suits workflows that need detailed browser control, while ConvertAPI provides useful tools for cleaning up existing webpages. PDFCrowd supports several PDF finishing options during rendering.

PDFShift's published concurrency limit is relevant for large bursts. Api2Pdf offers metered usage and multilingual fonts. CloudConvert and PDF.co are useful when PDF generation is part of a broader file conversion process. PDFMonkey and APITemplate.io make more sense when non-developers maintain templates, while cloudlayer.io is another Chrome-based choice to compare on rate limits and asynchronous behavior.

Before committing, test a document that represents your most difficult real case. Include the fonts, long tables, late-loading content and page numbers you actually need. Then test a failed request and a burst of jobs. Those results will tell you more than a feature checklist alone.