Adobe PDF Services API HTML to PDF: how the Create operation actually works

Adobe PDF Services API converts HTML to PDF through its Create operation, which accepts a local zip archive containing an index.html, a public HTTPS URL, or dynamic HTML paired with a JSON data file. You upload the input as an asset, submit a CreatePDF job against the asset ID, poll for the result, then download the finished PDF. One job of up to 50 pages costs one Document Transaction, and every account gets 500 of those a month for free.

That is the mechanism. The rest of this piece is about the parts that are not on the marketing page: the zip requirement, the URL rules that quietly rule out staging environments, and the specific script tag Adobe needs baked into your markup before it will inject data. All of it was read from Adobe developer documentation on 14 August 2026.

What input formats does the Create operation accept?

More than most people expect. Adobe lists static and dynamic HTML, HTML with inline CSS, Microsoft Word, PowerPoint and Excel, plus text, RTF, Markdown, zip archives, a URL, and the image formats BMP, JPEG, GIF, TIFF and PNG. One operation covers the whole set, which is a genuine convenience if your inbound documents arrive in a mixture of formats and you would otherwise be running two or three converters.

For HTML specifically there are three distinct paths, and they behave differently enough that picking the wrong one costs you a day.

How do I convert a local HTML file to PDF with Adobe PDF Services API?

You zip it. Adobe is direct about the reason: because web pages typically contain external assets, the input file must be a zip archive containing an index.html at the top level, along with any dependencies such as images and CSS files. The file also has to be local, meaning the archive is uploaded as an asset rather than fetched from anywhere.

This trips up people who expect to post an HTML string and have it render. If your markup references /assets/logo.png or a stylesheet, those files have to travel inside the archive, and the paths inside your HTML have to resolve relative to the archive root. In return you get something valuable: the render is fully self-contained and reproducible. There is no network fetch in the middle that can fail at 3am because a CDN had a bad minute.

If your HTML is genuinely standalone, with styles in a <style> block and no external references, Adobe supports a simpler inline-CSS path that takes the file without the packaging step.

Can Adobe PDF Services API convert a URL to PDF?

Yes, with two restrictions that matter more than they look. Verbatim from Adobe documentation, HTML to PDF conversion is not supported for requests containing URLs where the URL scheme is not HTTPS, or where the hostname resolves to a non-routable IP address. Adobe adds that this covers scenarios where redirects lead to non-routable addresses too.

Read practically, that means public HTTPS pages only. Plain HTTP is refused. So is localhost, so is 10.x or 192.168.x, and so is any internal hostname that resolves to a private range. A staging environment on a VPN is out. A preview server inside your own VPC is out. And because the redirect chain is checked as well, a public URL that bounces to an internal address is out too.

Plenty of document pipelines render an internal preview URL as the last step before delivery, and for those teams this is a design constraint rather than a detail. The workaround is to serve the page publicly behind an unguessable token, or to package the rendered markup as a zip and use the local path instead. Both are more work than posting an internal URL to a renderer that will accept one, which is the approach we take on our URL to PDF API.

How does dynamic HTML to PDF work in Adobe PDF Services API?

Adobe supports passing JSON data into an HTML template before conversion, which is how you would produce a per-customer invoice from one layout. The requirement is specific: the source HTML must include the script tag <script src='./json.js' type='text/javascript'></script>. You submit a zip containing the HTML file and its resources, along with the input data. That data is then used by JavaScript inside your page to manipulate the DOM, which effectively updates the source HTML before it is turned into a PDF.

It works, and the DOM-manipulation model is more flexible than a mustache-style placeholder system, because you can compute totals, hide sections and build tables in ordinary JavaScript. The cost is coupling. That script tag is an Adobe convention living inside your template, so the same file will not render anywhere else without editing. If you expect to change vendors at some point, keep the data-binding logic in your own code and hand the renderer finished HTML instead.

What options can I set on the PDF output?

The Create operation exposes a small, practical set. pageLayout takes a page width and height in inches, so US Letter is 8.5 by 11 and a landscape variant is 11 by 8.5. includeHeaderFooter switches on Adobe default header and footer. waitTimeToLoad gives the page a fixed number of milliseconds to settle before capture, which is the lever for content that arrives after the initial paint.

That last one is worth a note, because a fixed wait is a blunt instrument. If you set it low, a slow chart is missing from the PDF. If you set it high, every single render pays that cost, including the 95 percent that were ready immediately. Renderers that let you wait for a CSS selector instead will finish as soon as the element exists, which is both faster on average and more reliable on the tail. If you are fighting blank charts, the underlying problem is almost always this, and the fix is a condition rather than a longer timer.

How much does HTML to PDF cost on Adobe PDF Services API?

The free part is clear and the paid part is not. Every account gets 500 Document Transactions a month with no credit card required, and a Create job counts as one transaction for a document of up to 50 pages. So 500 rendered PDFs a month, free, which is a more generous evaluation allowance than almost anything else in the category. That generosity is specific to Create, though, and it does not carry across the other endpoints: the same 500 transactions buy 2,500 pages of Extract and only 50 pages of Accessibility Auto-Tag, which we break down endpoint by endpoint in Adobe PDF Services API pricing.

Above that, Adobe publishes no rate card at all. The pricing page offers a Contact sales button and no figures, and Adobe licensing documentation states that paid credentials require entering into a separate written agreement. We went through what that means for planning, and how the transaction maths changes for extraction and accessibility work, on our Adobe PDF Services API pricing page. The short version is that the numbers circulating on forums are second-hand reports of individual quotes and none of them appear on any Adobe page.

One quirk worth planning around: the 50 page rule applies to Create, but Extract bills one transaction per 5 pages and Accessibility Auto-Tag bills ten transactions per page. A team piloting all three on the same documents will exhaust the free tier far sooner than a pure rendering pilot would.

Is Adobe PDF Services API the right tool for HTML to PDF?

It depends entirely on how much else you need. Adobe sells fifteen or more document operations under one credential: extraction, OCR, accessibility tagging, electronic seals, Office conversion, page manipulation and a free embedded viewer. If your roadmap has three or more of those on it, buying the platform and using Create as one part of it is a sound decision, and consolidating vendors has value that does not show up in a feature table.

If HTML to PDF is the entire requirement, the calculus flips. You are adopting an upload-submit-poll-download flow, a zip packaging step, an HTTPS-only URL rule and a sales conversation, in order to use one operation. A single-purpose renderer takes a URL or a chunk of HTML on one request and hands back a PDF, and the ones worth considering publish what they charge. Our HTML to PDF converter works that way, and the PDF API pricing comparison normalizes twelve vendors onto the same workload so you can see the spread.

There is also a category of adjacent need that gets confused with this one. Adobe Electronic Seal applies an organizational seal to a PDF using a digital certificate, at ten Document Transactions per document, and it proves the file came from your company and has not been altered since. That is not the same as collecting a signature from a named person, which is a consent and identity workflow rather than a document operation. Teams regularly evaluate seals when what the business actually asked for was signatures, and the two are priced and built completely differently.

A practical checklist before you build

• Confirm every URL you intend to render is public and HTTPS, including anywhere a redirect might land.
• Decide whether your HTML travels as a zip or as a URL, and keep asset paths consistent with that choice from the start.
• Model your monthly transactions per operation, not in total, because Extract and Auto-Tag consume the allowance at completely different rates.
• Keep template data-binding in your own code rather than in an Adobe-specific script tag if portability matters to you.
• Test the slowest page you have against waitTimeToLoad before you commit, and note what that fixed delay does to your average render time at volume.
• Get a written quote before the pilot ends, since there is no self-serve upgrade at transaction 501.

None of this is a criticism of Adobe engineering. The Create operation is well documented and the free tier is real. It is simply a platform sold on platform terms, and the single most common way teams get this wrong is discovering that at renewal rather than at evaluation.