How to Convert HTML to PDF in Your Browser (No Upload, No Server)

HTML to PDF is one of those features that everyone needs occasionally and almost everyone gets slightly wrong. The reason is that there are two very different "HTML to PDF" products, and the one you want depends on what you are actually trying to do. This post covers both, the formatting gotchas that trip people up, and the privacy angle of doing the conversion in your browser rather than uploading the source to a remote renderer.

Two paths, two products

When someone says "convert HTML to PDF", they usually mean one of these:

1. Save the current page as a PDF. You are looking at a web page — a receipt, a long article, a finished design, a printable form — and you want to save exactly what you see as a PDF. The browser's print-to-PDF path is built for this and works perfectly.
2. Convert an HTML string (or template) to a PDF programmatically. You have a piece of HTML in code, or you have a template that you want to fill and render, and you want the result as a PDF. This is what "HTML to PDF libraries" do. In a browser context, the library runs in the page and renders the result without sending the HTML anywhere.

The tools overlap but they solve different problems. The first is built into every browser. The second is what the HTML to PDF tool on this site does — paste HTML, get a PDF, the page never leaves the browser.

Path 1: the browser's print-to-PDF

Every modern browser has a "Save as PDF" or "Print to PDF" option in the print dialog. On macOS Chrome: ⌘P, change the destination to "Save as PDF". On Firefox: ⌘P, then "Save to PDF" or "Microsoft Print to PDF". On Safari: ⌘P, then the PDF dropdown at the bottom. The result is a PDF that looks like the page would look printed, with the same layout, fonts, and images.

This path is the right tool when:

• You are looking at a web page and want to save it.
• The page has a print stylesheet (most well-built sites do) and the result is already formatted for paper.
• You do not need programmatic control over the output.

The gotcha is that the result depends on the page having a print stylesheet. If the page is designed only for screen, the print version will look wrong — usually too wide, with dark backgrounds, with interactive controls that print as buttons. The fix is to either use the site's print stylesheet (if it has one) or to use a tool that lets you control the output.

Path 2: programmatic HTML to PDF in the browser

For programmatic use — converting an HTML string you have in hand, or rendering a template — you need a library that runs in the page. The typical flow is:

1. Take the HTML you want to convert.
2. Render it into a hidden container in the page so the browser can lay it out.
3. Use a library to convert the layout into a PDF stream.
4. Offer the PDF as a download.

The library handles the hard parts: pagination (where pages break), font embedding, image embedding, and producing a valid PDF file. The result is a PDF that looks like the HTML would look printed, but you can control the page size, margins, headers, and footers before the conversion.

The HTML to PDF tool on this site runs this path in the browser. Paste HTML, set page size and margins, click convert, get a PDF. Your HTML is processed in the page; it is not sent to a server-side renderer.

When to use which

• Save a page you are looking at. Use the browser's print-to-PDF. Free, instant, no setup.
• Convert HTML from a code editor or template. Use a browser-based tool. Paste the HTML, get the PDF, no upload.
• Convert many pages at once. Use a tool with batch support, or a script that runs the same library in a loop.
• Generate an invoice, receipt, or report from structured data. Generate the HTML from the data (with the Markdown to HTML tool, or with a template), then convert to PDF. This is the cleanest pipeline because the HTML is the source of truth and the PDF is just a render of it.
• Merge multiple PDFs after conversion. Use the PDF Merge tool to combine the results into one file.
• Compress the result for email. Use the PDF Compressor to shrink the file before attaching it.

Formatting gotchas that catch everyone

HTML to PDF is a faithful render, which means the same CSS rules that look fine on screen can look wrong on paper. The common gotchas:

1. Dark backgrounds. A page with a black background and white text prints as a black rectangle with thin white text, which is unreadable on paper and wasteful in toner. The fix is a print stylesheet that flips dark themes to white-background-forced.
2. Wide content that overflows the page. A flex row that looks great at 1440px is way too wide for an A4 page. The fix is a max-width and overflow rules in the print stylesheet.
3. Interactive elements that do not belong on paper. Buttons, form inputs, navigation bars, and modals should be hidden in print. The CSS is one line: @media print { .no-print { display: none; } } and then add the class to the elements that should not appear.
4. Images that do not load. If the page references an external image that fails to load by the time the PDF is generated, the result has a broken-image icon. The fix is to either inline the image as a data URL or to make sure the image is loaded before the conversion runs.
5. Page breaks in the middle of a paragraph or table row. The browser picks the break point, and it often looks bad. The fix is the CSS break-inside: avoid property on the elements that should not be split.
6. Font fallback. If the page uses a web font that has not loaded by the time the PDF is generated, the result uses the fallback font. The fix is to wait for the web font to be ready before triggering the conversion.

Most of these are solvable with a thoughtful print stylesheet. The Markdown to HTML tool can produce a clean, print-ready HTML starting from Markdown, which sidesteps most of the issues by giving you a known-good starting point.

The privacy case for doing it in the browser

The most common HTML-to-PDF workflow is: paste HTML into a web tool, get a PDF. Most of those tools render the HTML on a server. The server sees the HTML, often logs it, and may use it for analytics or model training. For most use cases (a blog post, a public article) this is fine. For use cases that touch user data (a medical form, a financial statement, a private email) it is not.

Browser-based conversion sidesteps this by doing the rendering on your device. The HTML never leaves the page. The conversion result is downloaded directly. There is no server-side log, no third-party renderer, and no copy of the document sitting in someone else's database.

The trade-off is that browser-based conversion has a smaller feature set than a dedicated server-side renderer. You do not get header/footer templating with page numbers, you do not get the full Chrome rendering engine, and very complex layouts (e.g. CSS Grid with auto-flow) can render slightly differently than they would in a server-side tool. For most use cases, the difference is invisible. For the cases where it matters, the answer is a server-side tool with an explicit data-handling policy.

A practical recipe: invoice or report from data to PDF in your browser

1. Write the report in Markdown.
2. Paste into the Markdown to HTML tool to get a clean HTML version.
3. If the report has tables, lists, or styled sections, refine the HTML in any text editor.
4. Paste the HTML into the HTML to PDF tool, set page size (A4 or Letter) and reasonable margins (15-20 mm).
5. Click convert, save the PDF.
6. If the file is too large for email, run it through the PDF Compressor.

The whole pipeline stays in the browser. The data, the report, and the result are all on your device the whole time.