The same API and endpoints as image rendering, with one extra parameter. We render your HTML, CSS or URL in real Chrome and return a real vector PDF, not a screenshot in a wrapper.
curl -X POST https://app.html2img.com/api/html \
-H 'X-API-Key: your-key-here' \
-H 'Content-Type: application/json' \
-d '{
"html": "<h1>Invoice #1042</h1><p>Due within 30 days.</p>",
"css": "h1 { color: #4f46e5; }",
"format": "pdf"
}' Add format: "pdf" to a request you already make. The HTML endpoint turns your markup into a document. The Screenshot endpoint turns any public URL into one.
POST /api/html
{
"html": "<h1>Invoice #1042</h1>",
"format": "pdf"
} POST /api/screenshot
{
"url": "https://example.com",
"format": "pdf"
} The MCP server exposes the same option, so an AI agent can produce a PDF from a single tool call.
Plenty of tools rasterise your page and glue the image into a PDF shell. That gives you a file nobody can search. This is not that.
Open the file and highlight a sentence. Search it, copy it, paste it. The text layer is real, not a picture of letters.
Google Fonts, Adobe Fonts and self-hosted @font-face all load server-side and are embedded in the document, so the PDF looks the same on every machine.
Text, borders, shapes and gradients stay sharp at any zoom level. Only genuine raster content, your img tags and canvases, is embedded as pixels.
Long content flows across as many A4 pages as it needs. A 15 section report becomes a clean multi-page document without any extra parameters.
Background colours, gradients and images print by default. No pale, half-styled output to work around.
The response url points to a .pdf file on i.html2img.com, delivered as application/pdf from a global edge network.
Render the invoice your customer sees in the browser as the PDF you attach to the email. Same markup, same styles, one extra parameter on the request.
Fire a render from your payment webhook and store the returned URL against the order. The receipt is searchable later because the text layer is real.
A monthly report built as one long HTML page paginates on its own. Charts render as crisp vectors if you draw them with CSS or SVG.
Generate a certificate per attendee from a loop in your code. Names stay selectable, so the file works with screen readers and copy-paste.
Send the ticket as a PDF attachment people can print or keep offline. The same HTML can also render as a PNG for the confirmation screen.
Anything you already generate as an image can ship as a document instead. Change format, keep everything else.
Archive release notes, snapshot a pricing page before a change, or keep a record of a page you do not control. The Screenshot endpoint loads the URL in Chrome and returns the rendered page as a document. The dedicated URL to PDF API page covers this workflow in full.
curl -X POST https://app.html2img.com/api/screenshot \
-H 'X-API-Key: your-key-here' \
-H 'Content-Type: application/json' \
-d '{
"url": "https://example.com/release-notes",
"format": "pdf",
"webhook_url": "https://your-app.com/hooks/pdf-ready"
}' Third-party pages load at their own pace. Pass a webhook_url for slow renders and we deliver the finished file to you instead of holding the request open.
PDF output is built for parity with the image renderer: the PDF looks exactly like the PNG of the same input would. That design has three consequences worth knowing before you integrate.
Pages are A4 portrait for now. Long content paginates automatically, but you cannot pick US Letter, landscape or custom sizes.
Rendering uses your normal screen CSS. @media print rules are not applied, so everything the document needs belongs in your standard styles.
The sizing parameters (width and height, dpi, fullpage and selector) do not apply in PDF mode. Content reflows to the page width, and vector output is already sharp at any zoom level.
If your project needs precise page geometry, headers and footers or print stylesheets, a dedicated PDF service will serve you better; our honest comparisons against PDFShift, DocRaptor, Api2Pdf and PDFCrowd say exactly where. If you want the document to match what you already render as an image, this does exactly that.
wkhtmltopdf renders with a WebKit build that predates most of the CSS you write today, and the project is no longer maintained. Grid and flexbox layouts degrade or fail, and you carry the binary in every environment that renders.
Headless Puppeteer gives you current Chrome, but now you host it: a browser binary in your deploy, memory tuning, crash recovery and security patches on your schedule. That is a reasonable trade for some teams and a distraction for most.
HTML to Image runs current Chrome for you. There is nothing to install, nothing to patch and no browser in your build artefacts. You make an HTTP request and get a URL back.
A PDF render costs the same single credit as an image render, from the same monthly pool. No separate PDF tier, no multiplier. See pricing.
The usual JSON envelope, with the url pointing at a .pdf file served as application/pdf. The getting started guide covers the full request and response shape.
{
"success": true,
"id": "9d5f9b52-6b32-4a1c-a9c5-1f0b2a9e4c11",
"credits_remaining": 499,
"url": "https://i.html2img.com/image-1784019129398-416501.pdf"
} Is the text in the PDF selectable?
Yes. The output is a vector PDF with a real text layer and embedded fonts, so text can be selected, searched and copied in any PDF viewer. Only genuine raster content, such as img elements and canvases, is embedded as pixels.
What page size do PDFs use?
A4 portrait, and long content paginates across pages automatically. Fixed-width designs wider than the page can pass scale_to_fit to scale onto the page instead of cropping. Other page sizes and orientations are not available yet, so if your project needs US Letter or landscape output today, a dedicated PDF service will fit better.
Do my @media print styles apply?
No. The PDF is rendered with your normal screen CSS so it looks like the image output would. Put everything the document needs in your standard styles rather than in a print stylesheet.
What does a PDF render cost?
One credit, exactly the same as an image render. The free tier gives you 50 renders across images and PDFs, with no credit card. See pricing for the paid tiers.
Can templates return PDFs?
Yes. Every named template accepts the format parameter alongside its inputs. Add "format": "pdf" to the JSON body and the response URL points to a PDF instead of a PNG. Document-shaped templates such as invoices, receipts and certificates are the natural fit. The templates API reference has the details.
Can I convert a live URL to a PDF?
Yes. Send the URL to the Screenshot endpoint with format set to pdf and we load the page in Chrome and return the document. For slow third-party pages, pass a webhook_url and we deliver the finished file asynchronously. To try it without writing code, use the free URL to PDF converter.
Can I try it before signing up?
Yes. The free HTML to PDF converter and URL to PDF converter run the same renderer in the browser, no account needed. When you want to automate the conversion, the API picks up where the converters leave off.
How is this different from wkhtmltopdf?
wkhtmltopdf renders with an old WebKit build and is no longer maintained, so modern CSS such as grid and flexbox degrades or fails. HTML to Image renders in current Chrome, there is nothing to install or patch, and no browser binary ships in your deploy.
50 free renders, images and PDFs alike. No credit card.