How to Convert a Web Page to PDF: URL and HTML Conversion

You want to archive a web page, save an article to read offline, keep an order as a document, or produce a report from your own HTML. HTML to PDF conversion answers those needs, but the nature of web pages brings a few surprises.

Two different uses

URL conversion: you give a web address and the tool loads that page and produces a PDF. Used for archiving and saving.

HTML code conversion: you give HTML you prepared yourself. Used to produce documents like invoices, reports and certificates programmatically.

Both use the same engine but you run into different problems.

Step 1: Check that the page is convertible

If you're converting a URL, some pages cause trouble:

Pages requiring a login. The tool visits that address on its own and doesn't carry your session information. The result is a PDF of the login screen or an error page. For such pages you need to use "Print to PDF" in your browser while you're logged in.

Content behind a paywall. The same problem.

Content loaded with JavaScript. Some sites load content through separate requests after the page opens. If the tool takes the PDF before the content has loaded, you get a blank or incomplete page. Good tools wait for the page to load, but on pages using infinite scroll the full content can never be obtained.

Sites that block bots. Some sites block automated access.

Cookie notices and pop-ups. These get included in the PDF and can cover part of the content.

Step 2: Understand print styles

This is the most surprising topic.

Most websites define two different style sets in CSS:

/* For screen */
nav { display: block; }

/* For print */
@media print {
  nav, .sidebar, .ads { display: none; }
  body { font-size: 12pt; color: #000; }
}

PDF generation uses the print styles. That's usually a good thing:

• Menus, sidebars and ads get hidden.
• The colors simplify and the text becomes more readable.
• A layout suited to page width is applied.

But it sometimes produces unwanted results too:

• An important information box can get hidden.
• The site's visual identity is lost.
• Some sites never defined print styles and the layout comes out broken.

Responsive design also comes into play: if the page changes its layout with screen width, the PDF page width (about 794 pixels for A4) can trigger the mobile layout. The result is a different arrangement from what you see on desktop.

Step 3: Set the page settings

Things to configure before converting:

Page size. A4 is the European standard; Letter is used in the Americas. If the document will be printed, choose the one suited to the target region.

Orientation. Portrait is standard. For pages containing wide tables or landscape charts, landscape can give a better result.

Margins. The default is usually 1-2 cm. Setting them to zero pushes content to the edge, but printers can't print in a band about 5 mm from the edge — leave a margin if the document will be printed.

Scaling. If the page is very wide, shrinking can be applied. But excessive shrinking makes the text unreadable; values below 70% are usually a problem.

Background graphics. They're off by default — built-in behavior aimed at saving ink. On dark-background designs, if that setting is off the text can become unreadable (white text on a black background becomes white on white once the background isn't printed). You may need to turn it on.

Headers/footers. Browser printing automatically adds the page title, URL and date. Useful for archiving, possibly unwanted for a clean document.

Step 4: Convert

Open the HTML to PDF converter, enter the URL or paste your HTML code, set the options and convert.

During the operation the tool loads the page, applies the styles, computes the layout and splits it into pages.

Step 5: Check the output

Is the content complete? Did the sections loaded with JavaScript in particular come through?

Are the page breaks sensible? Did a table get split in two? Is a heading stranded at the bottom of a page? Is an image cut in half?

Do the links work? Good converters turn hyperlinks into PDF links. Test a few.

Is the text selectable? Did the text come through as real text, or was the page turned into an image? Selectable text is far more valuable because it's searchable and copyable.

Are the accented characters right? Check any language-specific letters.

Colors and backgrounds. Did they come out as you expected?

Is the page count reasonable? If it's unexpectedly long, there may be hidden or repeated content on the page.

If you're converting your own HTML

If you're producing documents like invoices, reports or certificates from HTML, you have full control over the layout. CSS rules you can use:

Page size and margins:

@page {
  size: A4;
  margin: 2cm;
}

Page break control:

/* Don't split this element */
table, figure { page-break-inside: avoid; }

/* Start a new page before this element */
h1 { page-break-before: always; }

/* Don't break right after a heading */
h2 { page-break-after: avoid; }

Orphan and widow control:

p {
  orphans: 3;  /* leave at least 3 lines at the bottom of a page */
  widows: 3;   /* have at least 3 lines at the top of a page */
}

Showing link addresses:

@media print {
  a[href]::after { content: " (" attr(href) ")"; }
}

That makes it visible where links go in a printed document.

Font choice. Web fonts (like Google Fonts) load from external sources. If the conversion environment has no access to those sources, the font doesn't load and the layout shifts. For critical documents, embedding the font or using system fonts is safer.

Common problems

| Problem | Cause | Fix | |---|---|---| | The page comes out blank | JavaScript content didn't load | A wait time setting or printing from the browser | | No backgrounds | The default setting | Turn on the background graphics option | | Menus and ads are there | No print styles defined | Print from the browser using reader mode | | The layout is in mobile view | Responsive design was triggered | Increase the page width or use landscape | | A table is split in two | No page break control | If it's your own HTML, add a CSS rule | | The font is different | The web font didn't load | Use a system font | | Links aren't clickable | A converter limitation | Try a different method | | A login page came out | The session isn't carried | Print from the browser |

The alternative: printing from the browser

In some situations your browser's own "Print to PDF" feature gives a better result:

Pages requiring a session. You're already logged in.

JavaScript-heavy pages. The content is already loaded.

Personalized content. Your cart, your account, your settings.

The cost is that the browser applies its own page settings and usually adds headers/footers. You can correct those in the print dialog.

Some browsers' "reader mode" feature is useful too: it strips the page of menus and ads and shows only the article text. Taking a PDF in that mode gives a much cleaner result.

In summary

HTML to PDF conversion produces a document split into fixed pages using the web page's print styles. It's normal for it to look different from what you see on screen — menus get hidden, colors simplify, and responsive design can drop into a different layout. Background graphics aren't printed by default and on dark-background designs you may need to turn that setting on. For pages requiring a login and pages loaded with JavaScript, your browser's own printing feature is more reliable. If you're converting your own HTML, you can control the page breaks with CSS rules like @page, page-break-inside and orphans/widows and get a professional result.