Paste an HTML document and get back an A4 PDF with selectable text and embedded fonts.
The HTML to PDF Converter takes an HTML document, with its CSS in a style tag, and returns a finished PDF. The output is a real vector document rather than a picture of one: text can be selected, searched, and copied in any PDF viewer, webfonts are embedded in the file, and the content is laid out on A4 portrait pages that paginate automatically when the document runs long. Backgrounds, gradients, and borders all survive the conversion, so the PDF looks the way the same markup would look in a browser.
Most HTML to PDF options sit at one of two extremes: a browser print dialog that produces different output on every machine, or a document library that wants a server, a queue, and a maintenance plan. This converter runs server-side in a real browser engine and hands back a hosted URL, so the preview you check is exactly the file every recipient gets. When converting one document at a time stops being enough, the same renderer is available through the HTML to Image API: send your markup to the HTML endpoint with format set to pdf and wire the returned URL into an invoice email, a payment webhook, or a nightly reporting job.
Drop a complete document into the editor, with your CSS inside a style tag in the head. The sample invoice that loads with the converter is a reasonable skeleton: replace the content, keep the structure.
The renderer loads your markup in a server-side browser engine, applies your styles, and lays the result out on A4 portrait pages. Long content flows across as many pages as it needs; nothing is scaled down to force a fit.
The preview pane shows the finished PDF, not an approximation of it. Look at where the page breaks fall and confirm the fonts and colours came through, then adjust the markup and convert again if something sits wrong.
The file lives at a stable URL on the CDN and is served as application/pdf, so you can download it, attach it, or link to it directly. Converting again after an edit produces a new file at a new URL.
The invoice a customer sees in their browser and the PDF attached to their email should be the same document. Reuse one set of markup and styles for both, and the two outputs stay in step because nobody maintains a second layout in a design tool.
Fire a conversion from the payment-succeeded webhook, store the returned URL against the order, and the receipt exists before the confirmation email goes out. Because the text layer is real, the amount and order number stay searchable in whatever document system the file lands in.
A monthly report written as one long HTML page paginates on its own, so a fifteen-section document becomes a clean set of A4 pages with no per-page fiddling. Tables, CSS charts, and SVG stay vector, which keeps them sharp on screen and in print.
Render one certificate per learner by looping over the enrolment list and swapping the recipient name into the markup. Names stay selectable text rather than pixels, which matters for screen readers and for anyone copying the credential into a records system.
Documents that get signed or filed need to read the same way for every party, years later. A server-rendered PDF freezes the content and layout at generation time, and the embedded fonts mean it displays identically on machines that have never installed your brand typeface.
A branded header, a line-item table with totals, and payment terms at the foot. The sample document that loads with the converter is a trimmed version of this layout.
A long report with section headings, tables, and CSS bar charts flowing across several A4 pages. The markup declares nothing about pagination; the renderer breaks the pages itself.
A centred certificate with a border and a script typeface for the recipient name, converted from the same markup a browser would display.
PDF pages are A4 portrait and content reflows to the page width, so the width, height, and dpi options from image rendering are ignored. Drop fixed pixel widths and viewport units in favour of flowing blocks with sensible margins, the way you would style a long article.
The renderer does not wait for remote images, so an img tag pointing at a hosted file can come through blank. Encode images as base64 data URIs directly in the src attribute and the document becomes self-contained, which also means it converts the same way every time.
Print stylesheets are not applied: the PDF is rendered with your normal screen CSS so it matches what a browser shows. If the document needs particular spacing, hidden elements, or page margins, express that in the standard styles rather than in an @media print block.
Rasterising a heading into an image costs selectability, searchability, and file size all at once. Real text stays vector, embeds its webfont, and survives any zoom level, so reserve images for genuinely graphical content like logos and photographs.
Automatic pagination is right most of the time, but a table row or a card can land across a page boundary. The preview shows exactly where each page ends; when a block splits awkwardly, adjusting its margins or its position in the source usually settles it.
Is the text in the PDF selectable?
Yes. The output is a vector PDF with a real text layer, so anything written in the markup can be selected, copied, and searched in any viewer. Only genuine raster content, such as img elements and canvases, is embedded as pixels.
What page size does the PDF use?
A4 portrait, with content paginating across as many pages as it needs automatically. Other page sizes and orientations are not available yet, so a project that must produce US Letter or landscape output today is better served by a dedicated PDF layout tool.
Why are width, height, and dpi ignored?
Those parameters size PNG output, and a PDF has no bitmap to size: pages are A4 and the content is vector, sharp at every zoom level. Design the markup to flow to the page width rather than to fixed pixel dimensions.
Do my @media print styles apply?
No. The document is rendered with your normal screen CSS, so the PDF looks like the same markup would in a browser window. Put everything the document needs into your standard styles, including anything you would usually reserve for print.
Can I use webfonts?
Yes. Google Fonts and self-hosted @font-face fonts load during the render and are embedded in the PDF, so the document shows the intended typeface on machines that do not have the font installed.
How do I convert HTML to PDF from code?
Send your markup to the HTML endpoint of the HTML to Image API with format set to pdf. The response contains a hosted URL for the finished file, and a webhook_url parameter switches the call to async for long documents. Each conversion costs one credit, the same as an image render.
How much does it cost?
The converter on this page is free: three renders an hour and ten a day per visitor, with no account needed. A free account raises that to 25 renders a month and adds API access, and paid plans carry on from there for invoice-volume workloads.
How is this different from printing to PDF in my browser?
A browser print dialog applies print stylesheets, inserts its own headers and margins, and produces different results across machines and browsers. This converter renders server-side, so the same markup produces the same document for everyone, and the conversion can be automated through the API.
Render full invoices as PNG images or A4 PDFs for emails, dashboards, and exports
Compact order receipts as PNGs for confirmation emails or PDFs for expense filing
Print-ready certificates for course completion, training, and recognition
Turn syntax-highlighted code into a shareable PNG with a custom theme and window chrome.
Render an invoice as a PNG to embed in email bodies without forcing a PDF attachment.
Build a 1200 by 630 share card from a page title, subtitle, and brand colours.
The HTML to PDF Converter runs on the HTML to Image API. Call the same renderer from your own code with a free account. 25 renders a month on the free tier. See the pricing page for higher-volume plans.