HTML to PDF Converter Turn a saved web page or a block of markup into a paged document on your own machine

How to Convert HTML to PDF Online for Free

Two minutes, nothing to install, and no account for your first run. This HTML to PDF converter executes inside the page you are reading, which is why none of your markup crosses the network.

1. 1

   Load your HTML file or paste the code

   Click the drop zone above, drag your file onto this page, or paste markup into the text field in the options rail. A complete document with a doctype works, and so does a bare fragment, which the engine wraps for you. Anything pasted wins over a dropped file, so you can test one snippet after another without clearing the queue.

2. 2

   Drop the local images alongside it

   A saved web page is an HTML file plus a folder of pictures, so select both at once. A relative image source is matched against the files you dropped, on the bare file name, which means a src of assets/img/logo.png finds your logo.png wherever it sits. Images written as data URIs need nothing extra. Pictures on remote servers are blocked rather than fetched, and that is deliberate.

3. 3

   Set the paper size, margins and text size

   Pick a page size such as A4 or US Letter, an orientation, one of the three margin presets, and a body text size between 9 and 12 point. These settings are what force a fluid screen layout into a fixed column. Leave Print background colors switched off unless you really want a solid block of ink on every sheet.

4. 4

   Convert and read the result screen

   Click Convert to PDF and your own processor runs the layout engine. The result screen reports the page count and counts what failed: remote images the engine refused to fetch, and CSS selectors outside what it implements. Read that report before you send the file to anyone.

Drop several HTML files at once and the engine joins the batch into one PDF, in card order, which is what you want when a set of exported articles has to read as a single document. It is the wrong thing entirely when each file is a separate invoice. Switch off Merge all pages into one PDF for that, and you get one file per input, listed separately on the result screen.

A batch holds 20 files and 100 MB on a free account, and a visitor who is not signed in gets 1 conversion every 12 hours against 2 for a free account. CartHacker Premium takes each batch to 100 files and 500 MB and removes the conversion counter, which is the difference between exporting one invoice template and exporting the month.

The Engineering Behind HTML to PDF Conversion

HTML and PDF disagree about the most basic property a document can have: its size. HTML reflows into whatever width it is handed and scrolls forever downward. A PDF is a stack of rectangles with fixed, unmoving edges. Going from one to the other means measuring and re-laying out every line, not photographing the result, and the tools that take the photograph are the ones that hand you a single absurdly tall page or a document that stops two thirds of the way down.

This converter parses your markup into a document model: blocks, styled text runs, lists, tables, images. That model goes to a paginating layout engine which measures each line against a real page box and breaks when the sheet runs out. It is the same engine that paginates Word files on our Word to PDF tool. Orphan control, slicing a table across a page boundary and embedding font subsets are hard problems that were solved once, for the Office suite, and reused here rather than rebuilt worse.

The processing pipeline, in order

1. Parse the DOM. Your markup goes through the browser's own HTML parser, so malformed markup recovers exactly the way the web recovers it. An unclosed tag is repaired instead of throwing the fatal error a strict XML parser would.
2. Collect the cascade. Rules inside style elements are read and sorted by specificity, then combined with inline style attributes. Presentational attributes that old CMS templates and email builders still emit, align and bgcolor among them, are kept at the lowest priority.
3. Walk the node tree. Block elements become paragraphs, headings and table rows. Inline elements pass weight, slant, size and color down by value, which is what makes an unclosed bold tag stop bolding at the right character rather than at the end of the page.
4. Resolve the images. Data URIs are decoded in memory. Relative sources are matched against the picture files you dropped in alongside the markup. Anything on an external scheme is blocked and counted.
5. Run the layout math. Every line is measured against the column width in points, wrapped, and placed. When the vertical cursor reaches the bottom margin a new page starts. Tables split across the break and redraw their header row on the next sheet.
6. Write the file. Fonts are subset and embedded, anchors become real PDF link annotations, and the document is serialized as a Blob your browser downloads from itself.

Typography and embedded fonts

A PDF can show any typeface on earth, but only if the font file travels inside the document. To keep that weight down, this converter ships three families under the SIL Open Font License: Liberation Sans, Liberation Serif and Liberation Mono. Your CSS font stack is read left to right and mapped to whichever of the three it asks for first. Ask for Georgia and you get the serif. Ask for Consolas and you get the monospace. Everything else lands on the sans.

We would rather state that reduction than hide it. The alternative is fetching font files from somebody else's server at conversion time, which raises a redistribution question and breaks the promise that nothing leaves your machine. The three faces are metrically compatible with Arial, Times New Roman and Courier New, so the letter widths match the fonts most pages are designed around and your line breaks land where you expect.

Which CSS This Converter Applies, and Which It Ignores

Almost no HTML to PDF converter publishes this list, because the honest version of it is a catalog of modern web features that do not work on paper. A browser runs a fluid layout algorithm that took two decades and thousands of engineers to build. A local converter runs the part of it that puts static words on a sheet. Knowing where that boundary sits turns an afternoon of guesswork into a five minute export.

Selectors that resolve correctly

• Type selectors. p, h2, td and the rest of the structural elements.
• Class selectors. .invoice-total, including compound forms such as td.numeric.
• Id selectors. #summary-table.
• The style attribute. It overrides everything in a stylesheet, exactly as it does in a browser.
• Comma-separated lists of any combination of the above.

Specificity is honored in the normal order, id over class over type, with source order settling ties. What the engine does not implement is anything that needs a live walk of the tree per node: descendant and sibling combinators, attribute selectors, pseudo-classes and pseudo-elements. Rules using those are counted and reported on the result screen instead of failing quietly, so a broken layout comes with a reason attached.

Declarations that change the output

What is not implemented

Flexbox, CSS Grid, floats, absolute and fixed positioning, transforms, multi-column layouts, box shadows, gradients, border radii and generated pseudo-element content have no equivalent in a paged model. Elements using them still appear with their text and typography intact, but they fall back to document order. A three column flex row comes out as three stacked blocks.

Media queries are skipped whole, @media print included, and counted in the report. If the page you are converting keeps its real layout in a print stylesheet, copy those declarations into a plain style block and convert that - it is a two minute edit that usually fixes the entire output.

Images, Privacy, and Why We Refuse to Fetch Remote URLs

An image tag holds a pointer rather than a picture. The markup says where the file lives and the browser is expected to go and get it. That model is fine on the web and a serious problem for a converter built on local processing. Honoring a remote image source would mean making a network request on your behalf, to a server we do not control, handing it your IP address and telling it exactly which document you are converting.

So images resolve from two local sources, and the third is refused:

• Data URIs are decoded in memory. A src beginning data:image/png;base64, carries the picture inside the markup itself, so there is nothing to fetch. This is why a self-contained HTML file exports perfectly every time.
• Relative paths are matched against the files you dropped. Select the HTML file and its image folder together and a src of assets/img/logo.png finds your logo.png. Matching is on the bare file name, so the directory structure in the src does not have to survive the download.
• Absolute URLs are skipped and counted. Any src on http://, https:// or another external scheme is dropped, and the result screen reports how many. That is a privacy feature and not an oversight.

When an image cannot be resolved the engine prints its alt text in grey italics rather than leaving a hole, so a proofreader can see what is missing and where. Markup with no alt attribute draws nothing at all, which is its own small argument for writing them.

Supported formats and re-encoding

A PDF natively carries two raster encodings: JPEG, and the deflate stream that PNG uses. Everything else has to be decoded first. JPEG and PNG files are passed straight through with their original bytes, so there is no second round of compression and no generation loss. GIF, BMP and WebP are decoded by the browser and rewritten as PNG, which changes the byte count and not the pixels. SVG is not supported: rasterizing vectors in a browser script produces soft, blurry output, so export your SVGs to high resolution PNG first.

Scaling follows your CSS and HTML attributes. A width or height becomes a measurement in points. An image with no stated size prints at its natural resolution, shrunk to fit the column if it is too wide, and never enlarged. Blowing a small image up to fill a column looks far worse on paper than on screen, so the engine declines to do it.

How to Convert a Live Website to PDF, and When to Stop Trying

Most people arrive here looking for a box to paste a URL into. This tool does not have one, on purpose. Fetching a live page needs a headless browser running on a server, and the moment that exists, the promise that your data stays on your machine is gone. What the tool converts instead is markup you already have, and for the job people actually want done, that works better.

Getting the markup onto your machine

1. Save the page properly. In your browser choose Save Page As and pick Web Page, Complete. You get an .html file and a folder of assets. Drop the HTML and the images into the zone above together.
2. Save from Reader View. Firefox and Safari both have a reading mode that removes ads, sidebars and navigation before you save. What you convert is the article, not the furniture around it.
3. Copy the element you actually want. Open developer tools, right-click the article or main node in the inspector, choose Copy outer HTML, and paste it into the options rail. This is the method worth learning, because it exports the content and nothing else.

That third method is what people who do this regularly use. The thing you want is almost never a whole website: it is one invoice, one contract, one page of documentation. Copying a single DOM node sidesteps every layout problem responsive design creates, because the sidebar and the sticky header never reach the engine in the first place.

When your browser print dialog is the better tool

Your browser contains a layout engine of several million lines that implements Grid, Flexbox and print stylesheets properly. If what you need is a faithful picture of a live page as its designers built it, press Ctrl+P and print to PDF. No script-based converter will beat it, and we are not going to pretend otherwise.

Use this tool instead when one of these is true:

• You have markup, not a rendered page. Database exports, email templates and system-generated invoices have no page to print in the first place.
• You need the same output every time. Print dialogs vary by operating system, browser and driver. This engine produces the same pages from the same input, offline, on any machine.
• You need selectable text. Some print paths rasterize text into an image. Everything here is written as real text with real link annotations behind it.
• You are running a batch. A print dialog cannot take twenty files at once. This does.
• The content is confidential. A URL-based online converter is told your private URL and fetches it from its own server. This engine works in your RAM and tells nobody anything.

Scaling Up: Batch Processing and Lifting Constraints

One email template or a handful of documentation pages is a trivial job and the free tier handles it without complaint. Exporting several hundred system records is a different problem, and the wall you hit is not our policy but the memory ceiling of a single browser tab.

CartHacker Premium raises each batch from 20 files and 100 MB to 100 files and 500 MB, and removes the conversion counter that limits a free account to 2 runs every 12 hours. The tab memory limit is still real, so a very large archive is best queued in several runs. Two clean batches always beat one crashed tab.

Zero-Trust Architecture: Your Data Stays Local

The standard build for a free HTML to PDF converter is an upload form feeding a headless Chrome instance on somebody else's server. Your markup crosses the network, lands on a disk, renders in a container you know nothing about, and sits there until a cleanup script gets to it. For a blog post that is fine. For an invoice carrying client addresses, a contract in draft, or an email template with live auth tokens in the links, it is a leak with a progress bar on it.

This tool has no upload endpoint at all. Your file is read through the browser File API, parsed by the DOM engine already in your browser, laid out by JavaScript on your own processor, and returned as a Blob. The markup exists on your hard drive and in your RAM, and nowhere else.

Verify the engineering in 30 seconds

1. Open developer tools, go to the Network panel, and clear the log.
2. Drop an HTML file into the converter and watch what the page requests.
3. You will see the engine scripts load once, a font file download only if your text needs glyphs the standard faces lack, and a small ping that counts the operation. No request carries your markup, and nothing outbound is anywhere near the size of your file.
4. The decisive test: load this page, disconnect the machine from the internet, and convert. It still works, which is structurally impossible for a cloud tool.

That architecture has one consequence worth stating plainly: anything your markup expects to fetch from the network will not arrive. A link rel="stylesheet" pointing at an external CSS file is ignored, exactly like a remote image. Inline the CSS into a style block before you convert, and the problem disappears.

When the Output Looks Wrong, and How to Fix It

Files are parsed the moment they land in the drop zone, so anything unreadable is rejected before it costs you a conversion. Everything in this table is a rendering problem that shows up in the finished PDF instead.

Best practice for system-generated markup

1. Never run the whole batch blind. Convert one representative file first.
2. Read the result screen and note which selectors were skipped and which images failed.
3. Open the PDF and check the page breaks, the tables and the lists. Those three are where paginating engines go wrong.
4. Fix the template once: inline the CSS, hide the furniture with display:none, force the page breaks you need. Then convert the same file again.
5. Run the full batch only when that one file is right. Catching the problem on file one costs a minute. Catching it after five hundred invoices costs your afternoon.

Frequently Asked Questions

The rest of the PDF suite

All of these run the same way: your file is read by JavaScript on your own machine, the work happens on your processor, and the result is handed back to you as a download that never existed anywhere else.