How to convert HTML to PDF that actually looks right (2026 guide)

The short answer

If you just need one page: Chrome → Ctrl/Cmd+P → Save as PDF is the fastest path and it renders the page's CSS reasonably well. For repeatable, styled output (invoices, tickets, reports) — where borders, page breaks, and headers must land in predictable places — use a dedicated HTML to PDF tool that respects @page CSS and prints without browser chrome getting in the way.

That is essentially the summary of every long r/webdev thread on this topic: browser print is fine for humans reading one page; anything programmatic or repeatable needs a proper HTML-to-PDF renderer.

What breaks and why

Threads on Reddit's r/webdev and r/HTML repeatedly surface the same four failure modes. All of them come down to the fact that the browser's print engine and its screen renderer aren't the same thing:

1. Backgrounds vanish. Chrome print strips background colors and images by default. Fix: enable "Background graphics" in the print dialog, or set -webkit-print-color-adjust: exact and print-color-adjust: exact in CSS.
2. Page breaks split rows in half. Tables and cards get cut across pages. Fix: page-break-inside: avoid (older) or break-inside: avoid (modern) on the elements that must stay whole.
3. Fonts substitute silently. Web fonts loaded from Google Fonts sometimes don't finish loading before print fires. Fix: preload the font and wait for document.fonts.ready before printing.
4. Margins and headers are inconsistent. The browser adds its own header/footer (URL, date, page number). Fix: use @page { margin: 0; } in your CSS and disable "Headers and footers" in the print dialog.

The @page CSS rules that matter

Most tutorials skip this and it's the difference between a professional-looking PDF and something that screams "I hit Ctrl+P":

@page {
  size: A4;
  margin: 15mm;
}
@media print {
  body { -webkit-print-color-adjust: exact; print-color-adjust: exact; }
  .card, tr { break-inside: avoid; }
  h2, h3 { break-after: avoid; }
  .page-break { break-before: page; }
}

Four rules solve about 80% of layout complaints:

• size: A4 (or Letter) makes the page dimensions explicit.
• break-inside: avoid keeps cards and rows on one page.
• break-after: avoid stops orphan headings hanging alone at page bottom.
• .page-break { break-before: page; } gives you a manual page break element.

When to use a tool instead of the browser

Use HTML to PDF when:

• You need consistent output across machines (the browser dialog varies by OS and version).
• You want the PDF to have no browser chrome (URL headers, "1/3" page counters).
• You're converting HTML that isn't hosted anywhere — a local file, a snippet, an email export.
• You want to convert without opening a print dialog every time.

Users on r/selfhosted often recommend headless Chrome or Puppeteer for server-side conversion. That's the right call at scale. For one-off conversions from a laptop, a browser-based tool avoids the setup.

The Markdown alternative

If your source is documentation, notes, or a README, converting HTML → PDF has too many steps. Go straight from source to PDF with Markdown to PDF. Fewer moving parts, more predictable output, and heading structure translates cleanly to a table of contents.

Follow-up steps

Once the PDF is generated:

• If you produced one PDF per page and need them combined, Merge PDF.
• If the PDF is huge because of embedded images (common with logos in email templates), Compress PDF usually cuts it in half without visible loss.

The privacy angle

Invoices, tickets, and reports often contain customer names, order details, and internal pricing. Every "free HTML to PDF API" you find online uploads the rendered content to their servers. HTML to PDF on DashConvert runs the render entirely in your browser — the HTML is parsed, laid out, and painted to PDF on your device.