How to Print an HTML Page Exactly as It Looks

You designed a page, it looks perfect in the browser, you print it, and it comes out wrong. Different margins, a missing background, content pushed onto a second page. This is one of the most common frustrations with HTML, and it comes down to a single fact: printing a web page is not the same as photographing it. The browser rebuilds your page for paper, and it makes choices you did not ask for. Here is how to take back control.

Why the printed page differs from the screen

The browser's print engine was designed for documents and articles, where reflowing text across pages and adding tidy margins is exactly what you want. For a designed page, those same behaviors are the problem. There are five culprits.

• Margins. The browser adds default page margins, so a full-page design gets a white border.
• Dropped backgrounds. Background colors and images are skipped by default to save ink, so colored sections print white.
• Page breaks. The engine decides where pages split, and a one-page design can get cut in two.
• Scaling. Print scaling can shrink or shift the layout so it no longer matches the screen.
• Fonts. If a web font is not available at print time, the browser substitutes another and the spacing changes.

Fixing it with CSS (if you control the HTML)

If you can edit the page, a few CSS rules bring the print output much closer to the screen.

Keep backgrounds: add print-color-adjust: exact (and the webkit-prefixed version) to the elements that carry background colors. This tells the browser not to strip them.

Control margins and page size: the @page at-rule lets you set the page size and margins for print. Setting the margin to zero and the size to match your design removes the white border.

Control breaks: the break-inside and break-after properties let you tell the browser not to split an element across pages.

Lock in fonts: keep your font link in the page and confirm it is loaded before printing.

Fixing it without touching the code

Often you do not control the HTML, or you just want it to work without CSS surgery. In that case the reliable approach is to stop printing the page and start rendering it. Instead of letting the browser rebuild your design for paper, you capture the design as a high-resolution image at the exact page size, then place that image in a PDF. Because it is a faithful photograph of the finished page rather than a re-interpretation, every margin, background, and position is preserved. This is why a design that prints wrong from the browser comes out perfect from a dedicated renderer: the renderer captures rather than rebuilds.

The one tradeoff is that a rendered image is not selectable text. For a design that is exactly the point, but for a document where you want people to copy the text, use the CSS approach above and a vector print instead.

Which approach should you use?

Ask what the page is. If it is a document, a report, or an article where selectable text matters, print it as a vector PDF and use CSS to tidy the margins and keep backgrounds. If it is a design, a flyer, a poster, an invitation, or anything where it simply has to look exactly right, render it to a 300 DPI image and put that in a PDF. The design case is where most of the exactly-as-it-looks frustration lives, and the render-to-image method solves it cleanly.

Step by step for an exact result

1. Decide whether you need selectable text (document) or an exact look (design).
2. For a document: set @page margins, add print-color-adjust: exact, confirm fonts, then Print to PDF.
3. For a design: render the page to an image at the exact page size and 300 DPI, then export it as a PDF.
4. Open the result and compare it side by side with the screen to confirm it matches.

The short version: the browser changes your page when it prints. Either tell it exactly what to do with CSS, or bypass the rebuild entirely by rendering the page to an image. Both get you a printed page that matches the screen.

Test before a big print run

Whatever method you use, print or export a single copy and inspect it before you commit to a stack. Check that backgrounds are present, that nothing is clipped at the edges, that the fonts are the ones you designed with, and that the page did not split unexpectedly. A one-page test costs a sheet of paper and saves you from discovering a problem after a hundred copies.

A note on color: screen versus paper

Even a perfect capture can look slightly different on paper, and it is not a mistake in your file. Screens create color with light, in what is called RGB, while printers create it with ink, in CMYK. Some very bright, saturated colors that glow on a monitor cannot be mixed exactly with ink, so they shift a little when printed. For most designs the difference is minor and no one notices. If exact color is critical, for a brand or a product, ask a print shop for a proof, which is a test print you approve before the full run.

Watch out for dark mode

One modern gotcha: if your page or your AI-generated design uses a dark background, remember that it will print that dark background, using a lot of ink, unless you intended it. Some designs are built to invert for print, but many are not. Before printing a dark design, decide whether you actually want a dark printed page or whether a light version would serve better and save ink. This is easy to miss because the dark version looks great on screen, which is exactly where you are looking when you decide to print.

Use print preview before you commit

Every browser has a print preview, and it is the fastest way to see what the print engine intends to do to your page before any paper or ink is involved. Open it and you will immediately see the margins it wants to add, whether the backgrounds are showing, and where it plans to break pages. Treat it as an early warning system: if the preview looks wrong, the print will be wrong, and you can switch to a render-to-image approach or adjust your CSS before wasting anything. Many people skip straight to printing and are surprised by the result, when a five-second look at the preview would have shown them the problem.

When the page is longer than one sheet

Some HTML pages are taller than a single printed page, and how they break becomes a real question. If you let the browser decide, it may cut through a heading or split an image awkwardly. If the content is genuinely multi-page, like a report, use CSS page-break rules to control where each page ends, so breaks fall between sections rather than through them. If the content is meant to be one page, the fix is the opposite: set the page size to fit the design, or render it as a single image so nothing gets split at all. Either way, deciding on purpose beats letting the print engine guess.

Frequently asked questions