The Save That Never Looks Like the Page
You find a recipe, an article, a receipt, or a booking confirmation you want to keep. You reach for the obvious move — File → Print → "Save as PDF" — and the result is a small disaster. The header is fine, then a cookie banner is frozen across the middle of page one, a "Subscribe now!" popup is baked into page two, the sidebar ads got their own page, and the last paragraph is sliced clean in half where the page broke. Half the article is there. It just doesn't look like the thing you were reading.
You are not doing it wrong. The browser's print dialog is doing exactly what it was built to do — and that job is subtly different from "save this page the way I see it." Once you understand the gap, saving a clean PDF of any web page takes about ten seconds and stops looking like a fax from 2004.
Let's sort out why it breaks and what actually works.
Why "Print to PDF" Mangles the Page
A web page isn't a fixed document. It's a set of instructions your browser assembles live, on the fly, sized to whatever window you happen to have open. There is no "page" until something forces one. When you hit print, the browser has to take that fluid, infinitely-scrolling layout and chop it into rigid, letter-sized rectangles — and that chop is where everything goes wrong.
Sticky and fixed elements get stamped onto every page. That cookie bar, the floating share buttons, the "back to top" arrow — many sites pin them with `position: fixed` so they stay put as you scroll. The print engine doesn't know they're supposed to be temporary. It renders them at their pinned spot on *every* printed page, so your PDF ends up with a navbar tattooed across the top of all six pages.
Page breaks land wherever they land. The browser slices the content at fixed intervals with no idea what's a heading, a paragraph, or a photo. So a sentence gets cut mid-line, a table splits across two pages with the header stranded on the first, and an image breaks in half.
Lazy-loaded content never shows up. Modern sites only load images and sections as you scroll to them. If you print without scrolling all the way down first, half the images are still blank placeholders — so your PDF has empty gray boxes where the photos should be.
Popups and overlays get captured mid-interruption. Whatever was on screen when you triggered print — the newsletter modal, the "accept all" dimmer — becomes a permanent, un-closeable part of the document.
None of this is a bug. Print-to-PDF was designed for simple, print-friendly documents, not for a modern page that's really a small application pretending to be an article.
Fix #1: Convert the Page's URL Directly
The cleanest option skips the browser's print engine entirely. Instead of screenshotting what's on your screen, you hand over the page's address and let a proper HTML-to-PDF renderer rebuild it as a document — one designed to paginate cleanly, load all the images, and drop the floating junk.
Paste the link into an HTML to PDF converter and it fetches the page, renders it in a clean environment (no cookie banner, no popup that was covering your screen), and lays it out with sensible page breaks. You get the article, the images, and the text — as a real multi-page PDF instead of a screenshot of your chaos.
This is the right move for anything you'd think of as a *document*: a blog post, a news article, documentation, a public receipt page, terms you want to archive. If you've saved the raw page source as an `.html` file, the general-purpose PDF Converter handles that upload too.
Fix #2: Use Reader Mode Before You Print
If you'd rather stay in the browser, there's a trick that fixes 90% of the mess: strip the page down *before* you print it.
Most browsers have a built-in Reader View (Safari calls it Reader, Firefox has the little page icon in the address bar, Edge has "Immersive Reader"). One click removes the ads, sidebars, sticky headers, popups, and comment sections, leaving just the headline, the body text, and the images. *Then* print to PDF.
Because Reader View has already thrown away everything that causes bad page breaks and floating clutter, what's left prints beautifully — clean margins, no navbar tattoo, no half-loaded images. It's the difference between photographing a messy desk and photographing a single sheet of paper. Same content, radically cleaner output.
The catch: Reader View only works on article-shaped pages. It won't help with a web app, a dashboard, an interactive map, or a checkout page — for those, keep reading.
Fix #3: When You Need Exactly What's on Screen
Sometimes the *look* is the point. A dashboard, a design mockup, a confirmation screen with a specific layout, a page where the visual arrangement matters more than the text. Here you don't want a re-rendered document — you want a faithful picture of the screen.
For that, take a screenshot (full-page capture, if your browser or an extension supports it) and turn the images into a document with a Screenshot to PDF tool. Each capture becomes a page, at full resolution, exactly as you saw it. It's the right call whenever the pixels matter more than the selectable text.
A Note for Writers and Developers
If you're generating the content yourself — release notes, a README, meeting notes, a formatted document — don't hand-build it as a web page just to print it. Write it in Markdown (plain text with `#` headings and `*` bullets) and run it through Markdown to PDF. You get clean typography and reliable page breaks with none of the print-engine roulette, because the converter was built to paginate documents rather than screenshots.
And if you already have a PDF but need to pull the text or structure back out — to edit or repurpose it — PDF to HTML runs the round-trip the other direction.
The Mistake Almost Everyone Makes
The single most common error is treating "Print to PDF" as if it means "save this page." It doesn't. It means "pretend this page is a paper document and jam it through a printer that happens to write to a file." Those are different jobs, and the mismatch is the entire reason your saved articles look broken.
The fix isn't a better click in the same dialog — it's picking the right tool for what you actually want. Want the *content* as a tidy document? Convert the URL or use Reader View. Want the *exact look* of the screen? Screenshot it. Building the document yourself? Write Markdown and convert. Match the method to the goal and the "why does my PDF look terrible" problem simply stops happening.
One More Thing: File Size
Web-page PDFs can balloon fast, especially image-heavy articles and full-page screenshots, which occasionally makes them too big to email or upload. If your saved PDF comes out surprisingly large, run it through a PDF Compressor — it re-compresses the embedded images while keeping the text crisp, usually shrinking the file well past half its size without any visible difference.
Bottom Line
Your browser's print button isn't broken — it's just answering a different question than the one you're asking. It turns a live, fluid web page into rigid paper rectangles, and all the floating banners, lazy images, and blind page breaks are what that translation costs.
So stop fighting the print dialog. For an article you want to keep, convert the link with HTML to PDF or clean it up with Reader View first. For a screen whose layout matters, screenshot it into a PDF. For something you're writing, start in Markdown. Pick the method that matches the goal, and your saved pages will finally look like the pages you were actually reading.