You have done it a hundred times. You find a great article, hit Ctrl+P, choose "Save as PDF," and open the result expecting a clean document. Instead you get a bloated, ugly file stuffed with ads, navigation bars, and a URL stamped across every page. It is not your fault. Browser PDF was never designed to produce good-looking documents.
Free — 3 PDFs per month. No credit card required.
When you tell your browser to save a page as PDF, it does exactly what you asked — it prints the entire page. Every pixel. That means the banner ad at the top of the article, the sticky navigation bar, the sidebar full of "recommended reading" links, the cookie consent popup you already dismissed, the newsletter signup modal, the comment section with 200 replies, and the social sharing widgets floating in the corner. All of it ends up in your PDF.
The browser has no concept of "content" versus "chrome." It cannot distinguish the three paragraphs you actually wanted from the 47 other elements the website loaded around them. To your browser's print engine, an ad is just another div. A navigation bar is just another block of rendered HTML. It prints everything because it has no way to know what you care about and what you do not.
This is the single biggest reason browser PDFs look terrible. A well-written 1,200-word article that should produce a tidy 3-page PDF turns into a 9-page disaster because six of those pages are navigation menus, ad placements, related article grids, and footer links. You end up with a document that is mostly noise, and the content you wanted is buried somewhere in the middle.
Open any browser PDF and look at the top of each page. There it is: the full URL of the webpage, often so long it wraps or gets truncated into meaninglessness. Now look at the bottom: the date, the page title (sometimes a garbled version of it), and a page number. Chrome, Firefox, Edge — they all do this by default. These browser-injected headers and footers are the universal hallmark of a "printed from browser" document, and they make every PDF look like an unfinished draft.
You can technically disable this. In Chrome, open the print dialog, expand "More settings," and uncheck "Headers and footers." In Firefox, you need to go into Page Setup and manually clear each header and footer field. Most people never discover these settings, and those who do have to toggle them every single time they print because the preference does not always stick between sessions.
But even if you remove the browser metadata, you still have the website's own header and footer — the navigation bar, the site logo, the footer with 40 links to legal pages and social media profiles. The browser cannot distinguish between its own injected text and the site's structural elements. Both end up in the PDF, and together they make the document look unmistakably like something you printed from a web browser rather than a real document someone created intentionally.
Modern websites are built for screens. Responsive CSS makes them look good on a phone, a tablet, and a desktop monitor. But paper is not a screen, and print is not a viewport size that most web developers test against. When the browser's print engine renders a responsive layout onto a fixed paper size, things go wrong in ways that are hard to predict and impossible to fix from the print dialog.
Three-column layouts sometimes collapse into a single column, stacking sidebar content below the main article and adding pages of irrelevant material to your PDF. Other times the columns do not collapse at all, and content overflows the right margin, getting cut off mid-sentence. Hero images sized at 100vw stretch beyond the page boundaries. Flexbox and grid layouts that look polished on screen produce overlapping elements on paper. Sticky headers that follow you as you scroll get rendered at their initial position, sometimes covering the first paragraph of the article.
The core issue is that CSS media queries for print (@media print) are an afterthought for most websites. According to HTTP Archive data, fewer than 15% of the top million websites include meaningful print stylesheets. The rest rely entirely on their screen layout, which the browser's print engine attempts to interpret with mixed results. Some browsers handle this better than others, but none handle it well enough to produce a document that looks designed rather than accidentally generated.
Browser PDF gives you exactly one visual style: whatever the website happens to look like when printed. You cannot choose a font. You cannot set margins. You cannot apply a template. Every PDF from every website has the same aesthetic — or rather, the same lack of aesthetic. A New York Times article, a GitHub README, a Stack Overflow answer, and your company's Confluence wiki all look equally generic and equally unprofessional when pushed through the browser's print engine.
This matters more than it might seem. Context determines how a document should look. A research paper should feel dense and formal with serif typography. A business report needs clear section dividers and restrained styling. Developer documentation benefits from monospace code blocks and generous spacing. A personal reading archive just needs to be comfortable to read. Browser PDF gives you none of these options. It gives you whatever the website's CSS produces on paper, which is usually a compromise that works for nobody.
There is no margin control beyond choosing between "Default," "None," and "Minimum." There is no font selection. There is no heading style. There is no way to make the output look intentional. If you send a browser-generated PDF to a client, a professor, or a colleague, it immediately signals that you printed a webpage — because that is unmistakably what it looks like. The lack of any design control is what separates browser PDF from tools built specifically for the task.
Open a browser PDF of any modern webpage and check the images. There is a decent chance that at least one of them is a gray placeholder or a broken icon. This happens because most websites now use lazy loading — images are only fetched when they scroll into the viewport. When the browser's print engine renders the page, images that were never scrolled to were never loaded. They exist in the HTML as empty placeholders, and that is exactly what shows up in your PDF: blank rectangles where photographs and diagrams should be.
Code blocks suffer a different problem. On screen, code is displayed in a scrollable container with horizontal overflow. On paper, there is no scrolling. Long lines of code extend past the right margin and get cut off. Syntax highlighting may or may not survive the print process depending on how it was implemented. If the website uses a JavaScript-based syntax highlighter that applies styles dynamically, the print engine might capture the styled version or might not — the result is inconsistent. Tables run into the same overflow issue: wide tables simply extend beyond the page boundary, and the rightmost columns disappear.
Then there is the background color problem. Chrome's print dialog has a checkbox labeled "Background graphics" that is off by default. When it is off, all background colors are stripped from the output. This means code blocks lose their gray or dark background, making them visually indistinguishable from body text. Tables lose their alternating row colors. Callout boxes and highlighted sections become invisible. You can enable the setting manually, but like the header/footer toggle, most people do not know it exists and it does not persist reliably between print sessions.
Each of the five problems above exists because browser PDF was designed as a generic screen-to-paper conversion. It was not built to produce good documents — it was built to print web pages, which is a fundamentally different goal. A purpose-built tool like Pretty PDF Printer approaches the problem from the opposite direction: start with what the document should look like, then work backward to extract and format the right content.
For Reason 1 (junk content), Pretty PDF uses server-side content extraction. When you click the extension, the page HTML is sent to our server where an extraction engine — similar to the algorithms behind browser reader mode but tuned for PDF output — identifies the main article content and discards everything else. Ads, navigation, sidebars, cookie banners, comment sections, and social widgets are stripped before the PDF is ever rendered. A 1,200-word article produces a 3-page PDF, not a 9-page mess.
For Reason 2 (unwanted headers and footers), the solution is straightforward: Pretty PDF never injects them. No URL across the top of every page. No date in the footer. No browser metadata of any kind. The website's own navigation headers and footers are removed during content extraction, so the document starts with your title and ends with your content.
For Reason 3 (broken layouts), Pretty PDF renders PDFs using WeasyPrint, a dedicated PDF engine that implements CSS paged media properly. Instead of trying to force a responsive screen layout onto paper, WeasyPrint applies purpose-built print stylesheets with correct page breaks, orphan and widow control, proper margin handling, and single-column content flow. The result is a layout that was designed for paper, not retrofitted from a screen.
For Reason 4 (no style control), Pretty PDF offers five professional templates — Clean, Minimal, Corporate, Academic, and Dark Mode — each designed for a different context. Every template includes embedded fonts (Fraunces for headings, Instrument Sans for body text), careful typographic hierarchy, and appropriate spacing. You choose how the document looks, not the website.
For Reason 5 (broken images and code), Pretty PDF resolves all image URLs before rendering, including lazy-loaded images that the browser might not have fetched. Code blocks are formatted with monospace fonts, proper line wrapping, and preserved syntax styling. Tables are handled with correct column widths and overflow management. Background colors are always preserved because the rendering engine does not have a "Background graphics" checkbox — it simply renders what the stylesheet specifies.
How browser PDF and Pretty PDF handle each of the five problems.
| Problem | Browser "Save as PDF" | Pretty PDF Printer |
|---|---|---|
| Ads, nav, and clutter | Everything included | Stripped by content extraction |
| URL/date headers & footers | Added by browser automatically | Never added |
| Responsive layout on paper | Columns break, content overflows | CSS paged media via WeasyPrint |
| Style and template choice | None — one generic output | 5 professional templates |
| Images, code & tables | Lazy images missing, code cut off | Resolved images, wrapped code |
Clean content extraction, professional templates, no URL headers. Just the content you want, styled the way you choose.
Install Free Extension