Convert HTML to PDF Online for Free

HTML to PDF: Render a Web Page's Markup Into a Real PDF File

Turning HTML into a PDF properly means rendering it the way a browser actually would — running the same layout and CSS engine that decides how flexbox containers wrap, how a table's borders draw, and how a background color fills a box — rather than crudely stripping tags and dumping the leftover text into a generic template. This tool does exactly that: the HTML you submit is rendered on the server by headless Chrome, the same browser engine behind everyday Chrome tabs, and the resulting page is exported straight to a PDF via Chrome's own print-to-PDF machinery.

Running an actual browser engine safely against HTML submitted by anyone on the internet takes real precautions, and this tool is built around two of them specifically: JavaScript execution is switched off, and every network request the rendered page tries to make — loading a remote image, an external stylesheet, a web font, anything that isn't already embedded directly in the HTML — is blocked outright. Practically, that means only content that's inlined into the HTML itself (a data: URI for an image, a <style> block instead of a <link> to an external CSS file) will actually appear in the output; a remote image URL will not load. The technical section below explains exactly why that trade-off exists.

How to Convert HTML to a PDF with This Tool

1. Paste your HTML into the text area, or upload an .html file — either becomes the content that gets rendered.
2. Pick a page size (A4 or Letter), toggle landscape orientation if needed, and start the conversion.
3. The HTML is sent to the server, where headless Chrome loads it with JavaScript disabled and every non-embedded network request blocked, then lays it out exactly as a real browser tab would for anything that is embedded.
4. Chrome's built-in PDF export renders the laid-out page to a PDF at your chosen size and orientation, with backgrounds and styling included.
5. The finished PDF comes back as a download; a metered API endpoint offers the identical conversion for anyone automating this from a script instead of the page.

Because the rendering engine is a genuine browser, ordinary CSS, flexbox and grid layouts, custom fonts declared with an inline @font-face pointing at embedded data, tables, and print-specific styles all behave the way they would in a browser tab — the fidelity comes from using the real thing, not a simplified re-implementation of CSS.

Why People Need to Convert HTML to PDF

• Generating invoices, receipts, or reports from a template. Many billing and reporting systems build a document as an HTML template with data filled in, then need a static PDF as the actual deliverable to email or archive.
• Turning a styled email or web component into a shareable file. A nicely formatted HTML snippet — a newsletter, a styled summary — often needs to exist as a standalone PDF someone can download and keep, rather than only living inside an inbox or a page.
• Producing a printable version of dynamically generated content. Content assembled by an application (a quote, a certificate, a formatted export) can be built as HTML and turned into a PDF without hand-building a separate PDF-authoring pipeline.
• Archiving a document's exact visual appearance. A PDF locks in fonts, colors, and layout at a point in time, useful for records that shouldn't change even if the HTML source they came from is edited later.
• Batch-producing similar documents from a script. Feeding the same HTML template with different data through the metered API is a straightforward way to generate many near-identical PDFs — certificates, badges, statements — without manual repetition.

Why JavaScript Is Off and External Requests Are Blocked

Rendering someone else's HTML on your own server is inherently different from rendering it in a visitor's own browser tab, because the server is a shared, trusted environment rather than an isolated, disposable one. If the rendered page were allowed to run arbitrary JavaScript or fetch arbitrary URLs, submitted HTML could be crafted to make the server itself issue requests — to an internal service that shouldn't be reachable from the outside, to a cloud provider's internal metadata address, or simply to slow the server down by requesting enormous remote resources. Disabling JavaScript execution removes the ability to run any submitted script at all, and blocking every request other than a data: URI removes the network-request avenue entirely, regardless of whether it would have come from a script, an <img> tag, a stylesheet <link>, or an <iframe>.

The practical upshot for anyone using this tool is straightforward: embed what you need directly in the HTML rather than linking out to it. An image becomes a base64-encoded data:image/png;base64,... source instead of a URL pointing somewhere else; CSS goes in an inline <style> block rather than a <link rel="stylesheet"> pointing at an external file; a custom font is embedded the same way as a data: URI inside an @font-face rule. Anything embedded this way renders completely normally — the blocking only affects requests that would leave the page and go fetch something from elsewhere.

Full Browser Rendering vs. Other HTML-to-PDF Approaches

Approach	CSS/layout fidelity	Trade-off
This tool (headless Chrome)	High — real browser engine, full CSS support	External resources must be inlined; JavaScript doesn't run
Simple tag-stripping / text-extraction converters	Low — layout, styling, and images are typically lost	Fast and simple, but the output barely resembles the source
Browser's own "Print to PDF"	High — same engine, and external resources do load	Manual, one page at a time, not automatable from a script
A dedicated PDF-authoring library	Depends on the library — usually requires rebuilding the layout in its own API	More control, but no reuse of existing HTML/CSS at all

What sets this tool apart from a simple print dialog is that it's callable from code — the same metered API endpoint that powers the page can generate a PDF from a template with data substituted in, on demand, which a manual browser print action can't do.

Choosing Page Size, Orientation, and Margin

Three layout options sit alongside the HTML input, and each maps directly to how Chrome's own print-to-PDF feature handles a page. A4 and Letter cover the two page-size conventions most documents are built around — A4 for most of the world, Letter for the United States and a few other countries — and picking the wrong one for your intended audience is a common, easy-to-miss mistake that makes a document look subtly off when printed. Landscape flips the page's width and height, useful for wide tables, diagrams, or any layout that's naturally wider than it is tall. Margin controls the blank space reserved around the page's edges, specified in pixels; a margin of zero lets your own HTML/CSS control spacing entirely (useful if your template already has its own padding baked in), while a positive margin adds a uniform border of empty space Chrome reserves outside your content on every page.

None of these three settings affects how the HTML itself is parsed or rendered — they only change the physical page Chrome renders that HTML onto, the same separation that exists between a document's content and the printer settings you'd choose when printing it from an ordinary browser tab.

Two Paths to the Same Renderer

This page and this tool's metered API endpoint both funnel into the identical headless Chrome renderer, just through different front doors built for different situations. Submitting HTML through the page itself goes to an internal, unmetered route meant specifically for this site's own interface — there's no API key involved and no credit spent, only a modest per-visitor rate limit to keep that free door from being scraped as unlimited compute. The metered API is the door built for automation: a billing system generating invoice PDFs on a schedule, or an application producing a certificate per user, calls that endpoint with an API key and pays a small credit cost per render, which is the appropriate model for repeated, programmatic use rather than a single person converting a document by hand.

Where Does My HTML Content Go?

The HTML you submit is sent to the server so headless Chrome can render it — that engine only exists there, not inside your own browser tab reading this page. It's held only for the duration of the render, and once the PDF has been generated and returned to you, the submitted HTML is not kept, logged for content, or reused for anything else. This is a genuinely different arrangement from the browser-only tools elsewhere on this site: here, the content you're converting does make a trip off your device, because that's what it takes to run a full rendering engine against it.

Keep that in mind for anything genuinely sensitive — a document containing information you'd rather not transmit at all is better handled with a tool that stays entirely on your device. For the common cases this tool is built for — templated invoices, reports, styled snippets meant to become a shareable file — a short-lived, discard-after-use server render in exchange for real CSS and layout fidelity is a reasonable trade.

Why don't the images in my HTML show up in the PDF?

If an image is referenced with a regular URL (an http:// or https:// address), the request to fetch it is blocked by design, as part of the same protection that blocks every non-embedded network request. Convert the image to a base64 data: URI and place it directly in the src attribute instead, and it will render normally.

Can I use JavaScript to build the page dynamically before it's converted?

No — JavaScript execution is disabled for every render, regardless of what the script would have done. The HTML needs to already represent the final content and layout you want in the PDF; nothing runs client-side to modify it afterward.

Will external stylesheets or Google Fonts links work?

No. A <link> tag pointing at an external stylesheet or font URL is a network request like any other and gets blocked. Inline the CSS directly in a <style> block, and embed any custom font as a base64 data: URI, to have it apply in the rendered output.

What page sizes and orientations are supported?

A4 and Letter page sizes are both available, along with a landscape toggle and an adjustable page margin, covering the common cases for both onscreen documents and print-oriented layouts.

Is there a limit on how much HTML I can submit?

Yes — the HTML input is capped at roughly two million characters, which is far more than a typical template, invoice, or report needs; content built almost entirely from very large embedded base64 images is what's most likely to approach that ceiling.

Related Tools

If your source content is Markdown rather than HTML, the Markdown to PDF tool applies a readable built-in stylesheet automatically and shares this same rendering engine underneath. Once you have a PDF, the PDF merge tool can combine several generated documents into one file, and the PDF compress tool can shrink one down if it came out image-heavy. For a simpler plain-text document with no HTML or CSS involved at all, the text to PDF tool runs entirely in your browser.