The short version

Browsers render a print version of a page, controlled by the site's print stylesheet. Background colours and images are switched off by default, and layouts built for a wide screen get re-flowed for a narrow sheet.

The reliable route is your browser's own Print, then Save as PDF. It uses the real rendering engine, keeps text selectable, and preserves links.

A receipt page you need for expenses. An article to read offline. A rendered invoice from a web application. Saving a web page as PDF is a daily task, and the result is frequently not what was on screen a moment earlier.

Why the printed page looks different

Web pages are built for screens: continuous scrolling, a width set by the window, colour used freely because it costs nothing. Paper is fixed width, fixed height, and expensive to cover in ink.

The web has handled this since the 1990s by letting sites supply a separate set of rules for print. When you print, the browser applies those rules instead of the screen ones. A well-built site uses them to hide navigation, drop advertising, widen the text column and set sensible page breaks. A site with no print rules at all gets the browser's best guess.

What browsers change when printingDefault behaviour
  • Background coloursOff unless enabled
  • Background imagesOff unless enabled
  • Page widthPaper, not window
  • Fixed headersOften repeat or vanish
  • Navigation and adsUsually hidden by the site
  • Link URLsSometimes printed in full
Turn on background graphics
This single checkbox, in the print dialog's more settings section, explains most of the disappointment. It is off by default to save ink, and it takes with it every coloured panel, badge, table stripe and background image on the page. If your output looks washed out and skeletal, that is why.

Which route to use

Several things produce a PDF from a web page and they are not equivalent.

Browser Print to PDF

The dependable default

  • Uses the real rendering engine, so it matches what the browser sees
  • Text stays selectable and searchable
  • Hyperlinks are preserved as real links
  • Honours the site's print stylesheet
  • Gives you margins, scale and background control
Screenshot or capture extensions

A picture of the page

  • Captures exactly what is on screen, backgrounds included
  • Text becomes pixels, so nothing is selectable
  • No links, no search, no accessibility
  • Large files for long pages
  • Fine for visual records, poor for documents
Extensions that upload the page
Some browser extensions and web services fetch the page server-side and send back a PDF. For a public page that is harmless. For anything behind a login, a bank statement, an invoice, an internal dashboard, the service cannot see your session, so it either fails or you end up handing over credentials. Your own browser is already authenticated, which is why printing from it works and a third-party fetch does not.

Fixing bad page breaks

The most visible flaw in a printed web page is content split in the wrong place: a heading alone at the bottom of a sheet, a table cut through its middle, an image divided across two pages.

ReferenceWhy the edges disappear
the sheetPrintable areaeverything the printercan actually reachUnprintable band3 to 5 mm where thefeed grips the paper
The printable area is smaller than the sheet, which is where content at the margin goes.

Sites control this with break rules in their print stylesheet, telling the browser to keep a heading with the text that follows it, or never to split a table row. Most sites never write them, because most sites are never printed. From the reading side you have limited influence, but not none.

1

Try a smaller scale

Dropping the print scale to 90 or 80 percent re-flows the whole document and often moves a bad break somewhere harmless. It is crude and it frequently works.

2

Switch to a reader view first

Most browsers offer a simplified reading view that strips layout down to text. Printing from there gives a clean single-column document with far fewer break problems.

3

Change the paper orientation

Wide tables and dashboards that break badly in portrait often fit cleanly in landscape, which changes the available width rather than the content.

Pages that do not print what you see

Modern sites build much of their content with JavaScript after the page loads, and some of it never reaches the print output.

Content inside a scrolling panel usually prints only the visible portion, because the panel has a fixed height that the print rules did not override. Images that load lazily as you scroll may not have loaded at all for the parts of the page you never reached. Interactive charts drawn on a canvas sometimes print blank.

Scroll the whole page first
Lazy-loaded images only exist once they have been scrolled into view. Scrolling slowly to the bottom of a long page before opening the print dialog gives every image a chance to load, and turns a PDF full of grey placeholders into a complete document.

Fonts and the final result

Web pages use fonts downloaded from the network. When the browser generates a PDF it embeds the fonts it actually used, so the file carries what it needs and looks the same on any machine.

This is one of the areas where the browser route is clearly better than alternatives. A service that re-renders your page on its own server may not have the same fonts available, and will substitute, producing a document with different letter spacing and different line breaks from the one you were looking at.

Before you file it

Printed web pages have a few characteristic failures that are quick to spot and annoying to discover later.

Four things to look at

The last page. Web pages frequently produce a trailing sheet holding a footer fragment or nothing at all.

Any table. Check it has not been cut vertically, losing the right-hand columns entirely.

Images. Grey boxes mean lazy loading did not finish before you printed.

The header area. Sticky navigation sometimes repeats on every single page, which is obvious once you look and invisible in the preview thumbnail.

Turn HTML into a PDF

Tables, images, lists and page numbers kept, rendered on your own machine.

Open HTML to PDF

Common questions

Why the output differs from the screen.

01Why does my PDF look different from the web page?

Because the browser applies the site's print stylesheet rather than its screen one, and switches off background colours and images by default. Enabling background graphics in the print dialog recovers most of the visual difference.

02How do I keep the background colours?

In the print dialog, open the additional settings and enable background graphics. It is off by default to save ink, and it is responsible for most of the washed-out appearance people notice.

03Why are my page breaks in the wrong places?

The site did not define print break rules, so the browser splits content wherever the page runs out. Reducing the print scale, switching to the browser's reading view, or changing to landscape will usually move a bad break somewhere acceptable.

04Why are some images missing?

Lazy loading. Images further down a long page do not load until they are scrolled into view, and anything that never loaded cannot print. Scroll slowly to the bottom of the page first, then print.

05Do hyperlinks still work in the PDF?

Yes, when you print from the browser. It writes real link annotations that remain clickable. Screenshot-based captures produce an image instead, where nothing is clickable and nothing is selectable.

06Is it safe to use an online HTML to PDF service?

For a public page, yes. For anything behind a login it will not work and should not be attempted, because the service has no access to your session. Your own browser is already signed in, which is why printing from it is both simpler and safer.