Convert HTML to PDF — Save Web Page as PDF Online

Saving an article for offline reading, attaching a finished email layout to a report, making a PDF version of your web page or a receipt from HTML code — this is a common task. The "HTML → PDF" tool in pdfredX does it right in the browser and lets you choose how: privately (locally) or with better layout (via a server). Let's look at both paths.

Step 01. Open the tool

Open pdfredx.com and launch "HTML → PDF". A window appears with two tabs: HTML code (paste ready markup) and Page URL (a website address). Pick what you have.

Step 02. Choose the conversion method

Below the input is a method switch:

• 🔒 Local (private). Conversion runs right in your browser, the file goes nowhere. The best choice for pasted HTML code whose styles and images are inside it (inline CSS, data images).
• 🌐 Server (better layout). The markup or the page at a URL is rendered by our server. It holds layout and external resources better, but it is a basic render without JavaScript — good for documents and simple pages, weak on complex dynamic sites. Processed on our server (not 100% local).
• For the URL tab, the "local" method is 🖨 Open + Ctrl+P: we open the page in a new tab, and you press Ctrl+P → "Save as PDF". This gives the best quality (your browser's engine) and stays 100% local.

Step 03. Get the PDF

Press "Convert to PDF" — the finished file downloads straight from the browser. That's how HTML code becomes a neat document, and an address becomes a PDF version of the site or a web page as an offline document. Free, no registration.

How it works under the hood

The local path. The pasted HTML is rendered in a hidden container, then html2canvas captures it into an image, and jsPDF assembles the PDF (an A4 sheet, a long page sliced across several). All in the tab's memory — nothing is sent.

The server path. The code, or a page fetched by URL, is sent to our PHP endpoint, where the Dompdf library renders a real PDF and returns it. The server, unlike the browser, can fetch a page by URL (the browser is blocked from that by the CORS policy).

Known limitations

Local — self-contained HTML only. External images and styles from other domains won't be pulled in this mode (security policy). For pages with external resources, use the server or Ctrl+P.

The server doesn't run JavaScript. Dompdf renders HTML and CSS but doesn't execute scripts — on sites drawn via JS the result will be simplified. For such pages the best result comes from browser print (Ctrl+P).

A live URL can't be converted "locally". The browser can't read another site because of CORS — so for a URL there's either the server or the honest "Open + Ctrl+P" path.

Need to combine several ready PDFs into one? That is the Merge PDF tool.

Try it right now — pdfredx.com, no registration.

Most online HTML-to-PDF generators work the same way: you hand them your code or a page address, everything goes to their server, and a file comes back. For a public page that's fine. But if the HTML holds an internal report, a draft email, a layout with client data, or code with sensitive information, you don't want to send it to someone else's machine. pdfredX solves this honestly: it offers two paths and states plainly which processing is local and which is on the server.

Why it matters

HTML code often contains not just layout but data: amounts in a receipt, personal fields in an email template, internal links, comments in the markup. An ordinary "HTML-to-PDF generator" accepts all of this on its server, where by the service's policy it may be logged and stored. For work documents that's an extra risk for the simple operation of "saving page code as PDF".

Path 1. Local — private, in your browser

Choose the 🔒 Local method. The pasted HTML is rendered and turned into a PDF right in the tab — the file never leaves the device.

• Nothing is sent. Neither the code nor the data goes to a server.
• Works offline once the app is loaded.
• Best for self-contained HTML: styles and images inside the code (inline CSS, data images).

The honest limitation: external resources from other domains won't be pulled in this mode (security policy), and this is a path for HTML code, not for a live URL.

Path 2. Server — better layout, but not 100% local

Choose the 🌐 Server method. The code or the page at an address is rendered by our PHP server using the Dompdf library.

• Holds layout and external resources better than the local path.
• Handles URLs: the server can fetch a page by link (the browser is blocked from that by CORS).
• Honest caveat: it's a basic render without JavaScript, and processing happens on our server — not 100% local. Good for documents, invoices, simple pages; on complex dynamic sites the result will be simplified.

We deliberately don't hide this behind vague "100% private" claims: if you chose the server, the data goes to the server. The choice is a conscious one.

Path 3 (for URLs). Browser print — best quality, local

For the URL tab there's a third, most honest option — 🖨 Open + Ctrl+P. We open the page in a new tab, you press Ctrl+P → "Save as PDF". This is your browser's engine: best quality, full support for modern CSS and JavaScript, and yet 100% local. For live sites this is often the optimal path.

What we cannot guarantee — an honest disclaimer

The local path protects code and data from being sent to external servers, but it is not a shield against every threat. Malware on the device, browser extensions with broad permissions and an unencrypted disk remain outside our control. The server path, by your choice, sends data to the server — a trade-off for layout quality. Pick the path for the task: privacy — local; the best render of a live site — Ctrl+P; complex static layout — the server.

Build a PDF from HTML the way you need — pdfredx.com, free, no registration.

Converting HTML to PDF is a task with three fundamentally different engines, and each has its price. The ideal result comes from a headless browser (real Chrome renders the page with JS and modern CSS) — but that's a heavy server component. In a browser with no backend, the raster path via canvas is available. And on cheap PHP hosting — a pure-PHP render. pdfredX deliberately combines the two realistic paths and honestly separates them by privacy. Let's break down the architecture.

Three engines and the hard CORS limit

headless Chrome — the quality benchmark, but needs Node/Chromium on the server; shared hosting doesn't have it. html2canvas + jsPDF — runs in the browser, private, but rasterizes the DOM and doesn't pull external resources. Dompdf — pure PHP, installs anywhere, but CSS 2.1 and no JavaScript.

The key limit that defines everything: the browser can't read the HTML of another site — the CORS policy blocks cross-site requests. So "enter a live URL → get a PDF" purely on the client is impossible; a URL is handled either by the server (which has no CORS) or by the browser itself through print.

Path 1. Local render: html2canvas → jsPDF

The pasted HTML is drawn in a hidden offscreen container, html2canvas captures it into a <canvas>, and jsPDF assembles the PDF, slicing a long page into A4 sheets:

await ensureHtml2Canvas();                     // lazy-load from cdnjs
const canvas = await html2canvas(holder, { scale: 2, backgroundColor: '#fff' });
const pdf = new jsPDF({ unit: 'pt', format: 'a4' });
const imgH = canvas.height * (pw / canvas.width);
let heightLeft = imgH, position = 0;
pdf.addImage(canvas.toDataURL('image/jpeg', 0.92), 'JPEG', 0, position, pw, imgH);
while ((heightLeft -= ph) > 0) { position -= ph; pdf.addPage(); pdf.addImage(imgData, 'JPEG', 0, position, pw, imgH); }

Plus — 100% private (nothing leaves the tab) and CSP-compatible (html2canvas from cdnjs is allowed in script-src). Minus — the result is raster, and external images/styles from other domains won't load (CSP img-src/CORS). So the local path is for self-contained HTML (styles and data images inside).

Path 2. Server render: Dompdf + SSRF protection

The code, or a fetched page, goes by POST to html2pdf.php, where Dompdf renders the PDF. The server, unlike the browser, can fetch a page by URL — but that opens an SSRF vector (a request to internal addresses). So both our fetch and Dompdf's own downloads pass through one filter:

function isSafeUrl($url) {
  $p = parse_url($url);
  if (!in_array($p['scheme'], ['http','https'])) return false;   // http/https only
  foreach (resolveIps($p['host']) as $ip)
    if (!filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE))
      return false;                                              // private/reserved IPs — rejected
  return true;
}
$options->setAllowedProtocols(['http://'=>['rules'=>[$rule]], 'https://'=>['rules'=>[$rule]]]);

Plus redirects off, timeouts, size limits, DejaVu fonts for Cyrillic. The engine's minus — CSS 2.1 and no JavaScript: on JS sites the layout degrades. Hosting diagnostics confirmed it (PHP 8.1, cURL/exec present, no headless browser) — hence the choice of Dompdf over Chrome.

Path 3 (for URLs). Browser print as the "best local"

For a live address the most honest path is to open the page and Ctrl+P → "Save as PDF". This is the browser's own engine: JS, modern CSS, perfect typography — and all 100% local. Here the server isn't "better", it only automates (one click), at a cost in quality.

Trade-offs and boundaries

What's next. An optional paid headless-Chrome API for those who need a perfect automatic render of a live URL — as a third method alongside local and Dompdf.

Test both paths — pdfredx.com, no registration.