HTML to PDF
Convert an HTML file to a PDF document.
Click to upload or drag & drop
Select a HTML file (.html or .htm)
How to use the HTML to PDF
- 1Pick the markup file
Select a saved .html, .htm or .xhtml file from your device.
- 2Run the conversion
Choose Convert to PDF. The markup is parsed into a document structure and flowed onto pages.
- 3Collect the PDF
Your download begins as soon as the export completes, with the text still selectable.
Examples
| Input | Output |
|---|---|
CSS inside a style block | Applied to the document |
Linked external stylesheet | Not loaded, plain text |
Image in a sibling folder | Missing from the PDF |
Image as a data: URI | Rendered in place |
Content built by JavaScript | Empty or shell only |
Flexbox or grid layout | Reflowed into one column |
Long HTML table | Split across pages |
What this converter is, precisely
Turning markup into a PDF is a question of who does the interpreting. A browser reads HTML as a live, resizable surface: it fetches stylesheets and fonts from the network, runs scripts that may write half the content, and paints the result to whatever width the window happens to be. LibreOffice, which is what runs here, reads the same markup as a document: structure first, then styling, then a flow of text and images down a sequence of fixed pages. The output is genuinely document-shaped — searchable text, sane page breaks, tables that continue onto the next sheet — and it is not a photograph of a web page.
Knowing which of those two things you are asking for saves a lot of disappointment, so the rest of this page is about matching the input to the engine.
The kind of file that converts well
Self-contained documents. If the markup carries its own styling in a style block, holds any artwork as embedded data URIs, and expresses its structure with headings, paragraphs, lists and tables, the PDF will look much like the intention behind the file. That covers a large share of the real reasons people convert HTML: an invoice generated by an accounting system, a receipt saved from a confirmation email, a report exported from an analytics tool, a template being proofed before it is sent, a documentation page kept for the record.
And the kind that does not
Two failure modes account for nearly every disappointing result, and both are worth understanding before you upload:
- The page is assembled by JavaScript. No scripts run during conversion, so whatever the browser was going to build never gets built. An application shell converts to a near-empty PDF, which looks like a bug and is really an accurate rendering of an empty container.
- The page depends on files that were not uploaded.Only the document you choose is sent. Its companions — external stylesheets, web fonts, a folder of images beside it — stay on your machine, and references to them come to nothing. A page that looked designed in your browser can arrive as unstyled text for no reason other than this.
There is also a quieter limitation: the layout is a document flow, not a canvas. Anything that positions boxes relative to a viewport is reflowed into a single column running down the page, so a three-column marketing layout becomes three stacked sections.
When your own browser is the better tool
For a page whose visual design is the point, or a live page on the internet rather than a file on your disk, open it and print it — Ctrl+P on Windows and Linux, Cmd+P on a Mac, then choose Save as PDF. The browser already has the page loaded with every stylesheet, font and script applied, and it will honour the print rules the site author wrote. That route wins on fidelity. This tool wins when you have a file rather than a URL, when the content matters more than the styling, or when you want the result to behave like a document you can pull text out of afterwards.
Related conversions
- Writing in Markdown → run it through Markdown to HTML first, then convert the result here.
- Going the other way, from a document to a web page → Word to HTML.
- Plain text with no markup at all → Text to PDF is a shorter path.
- Several converted pages that belong together → Merge PDF; an oversized result from heavy embedded imagery → Compress PDF.
File handling
The conversion needs an office engine with HTML import filters and a PDF writer installed alongside it, which is software that lives on a machine and not inside a web page, so your markup is sent to ours to be processed. It crosses an encrypted connection, is opened in an isolated working directory belonging to that one request, and is deleted together with the PDF once the file has reached you.
Frequently Asked Questions
Is this a screenshot of the page in a browser?
No, and the distinction matters. There is no browser involved: the markup is read by LibreOffice, which interprets it as a document — headings, paragraphs, lists, tables, images — and then exports that document as PDF. The upside is that the output behaves like a proper document, with real text you can select, search and copy, and long tables that break sensibly across pages. The downside is that it will not reproduce a design-led web page pixel for pixel.
My PDF came out blank or nearly empty. Why?
Almost always because the page builds itself with JavaScript. Scripts are never executed during conversion, so a single-page application, a dashboard that fetches its data on load, or anything rendered client-side offers nothing but an empty container and a script tag to work from. What you see in a browser was assembled after the file loaded, and that assembly never happens here. Save the finished page as static markup first, or export the content some other way.
Where did my styling go?
One file is uploaded, and one file is all the converter has. A stylesheet pulled in with a link tag, a web font hosted elsewhere, or artwork sitting in an images folder next to the page are all references to things that are not present, so they resolve to nothing and the text falls back to plain formatting. Put the rules in a style block inside the same file and the situation changes completely.
Which parts of CSS actually take effect?
Think document-level styling rather than layout engineering. Fonts, sizes, weights, colours, alignment, margins, list markers, borders and table styling generally register. Layout systems designed for a viewport — flexbox, CSS grid, absolute positioning, floats holding up a multi-column design — do not, because there is no viewport; content is reflowed into a single top-to-bottom column on fixed-size pages. Print stylesheets are not a workaround either, so do not count on a media print block changing the result.
How should I prepare a file so it converts well?
Aim for one self-contained document. Inline the CSS, embed images as data URIs rather than linking them, use ordinary semantic markup for structure, and let the content flow instead of positioning it. Invoices, receipts, exported reports, email templates and documentation pages built this way come out close to what you intended, because they were always paragraphs and tables underneath.
Is there a charge, a limit or a watermark?
None, none beyond 100 MB per file, and nothing stamped on the output. Markup rarely comes near that ceiling anyway; if a file does, the weight is almost certainly embedded base64 images rather than the HTML.