HTML to PDF,
in whatever you write in.
One endpoint, the same JSON body everywhere. Pick your language for a working example, the response shape, and an honest look at the libraries you would otherwise reach for.
- Node.jsNode.js: POST JSON to the API with global fetch, decode the base64 pdf field, write the file. No Chrome dependency, works in serverless.
- PythonPython: POST with requests, base64-decode the pdf field, or ask for responseFormat binary and return res.content from Django or FastAPI directly.
- PHPPHP: POST JSON with cURL or Laravel's Http client, base64-decode the pdf field or take the raw body with responseFormat binary. Works without exec or Chrome on the server.
- RubyRuby and Rails: post JSON with Net::HTTP, decode the base64 pdf field, or render_to_string a view and send_data the binary response.
- GoGo: net/http POST, decode the base64 pdf field, or stream the binary response straight to a ResponseWriter. No cgo, no Chrome in the image.
- JavaJava: java.net.http.HttpClient POST with responseFormat binary, written straight to a Path or returned as a Spring ResponseEntity. No extra dependency, no licence question.
- C# and .NETC# and .NET: HttpClient PostAsJsonAsync with responseFormat binary, then File(...) the bytes. No native dependency, no commercial licence, runs in containers and Azure Functions.
- ReactReact: never call the PDF API from the browser. Render markup with renderToStaticMarkup, post it to your own route, and have the server call the renderer. Avoid html2canvas, which produces an image rather than text.
- Next.jsNext.js: post HTML from a route handler or server action with responseFormat binary and return res.body as application/pdf. Avoids Chromium in the function and keeps the key server side.
Or just use curl
There is no SDK to install in any language, because there is nothing an SDK would add. One POST, one JSON body, one PDF back. If your language can make an HTTPS request, it can make a PDF.
The body takes html, a url, or a template with structured data, plus page options for format, margins and orientation.
curl -X POST https://api.html4pdf.com/generate-pdf \
-H "Authorization: Bearer $HTML4PDF_KEY" \
-H "Content-Type: application/json" \
-d '{"html": "<h1>Invoice INV-1042</h1>"}' \
| jq -r .pdf | base64 -d > invoice.pdfHTML to PDF: common questions
What is the most reliable way to convert HTML to PDF?
Render it in a real browser. Every library that implements its own CSS engine eventually disagrees with what you saw on screen, usually over flexbox, grid or a web font. The question is only whether you run the browser yourself or call something that already does.
Should I run headless Chrome myself?
If you render a large volume and can look after a service, yes: the marginal cost per document is close to zero. If PDFs are a feature rather than your product, a browser in your deployment is a lot of memory, patching and cold start for something that runs occasionally.
Why does my PDF not match the page in my browser?
Three usual causes. The renderer is not Chrome, so modern CSS is ignored. Your stylesheet never arrived, because relative URLs mean nothing to a fresh page. Or print styles are being applied, and your screen styles are not.
How do I get my CSS into the PDF?
Inline it in a style tag, or link it with an absolute URL that is publicly reachable. A renderer loads your markup as a brand new page with no bundler and no session, so anything relative or behind auth will not load.
Can I convert a URL instead of HTML?
Yes. Send a url field instead of html. URL conversions run asynchronously and are delivered to your webhook, because the page has to be loaded and given time to settle.
How fast is it?
Three to five seconds for a typical document, including the network round trip.
Is my HTML stored?
No. It is rendered in memory and released when the response is sent. Nothing about the document is written to disk or kept.