Save a Webpage as PDF Without Cutting Off Content: The Fix

TL;DR

Chrome's Save as PDF cuts pages off for one specific reason: the print engine snapshots the DOM as it exists at the moment you open the print dialog, and most modern pages have not loaded their full content by then. Images below the fold are lazy, comments are async, infinite-scroll feeds have only rendered the first screen, and hidden accordions have never been opened. Scroll the entire page to the bottom, wait a beat, then print — or use a tool that does that for you. The one-click version lives in Convert Web to PDF, which force-loads everything before rendering.

Why Chrome's Print to PDF cuts pages off

Three separate things go wrong, and they compound.

1. Lazy-loaded images. Since Chrome 76, every <img loading="lazy"> tag waits until the image is near the viewport before requesting the file. WordPress adds this attribute automatically. So does Medium, Substack, most news CMSes, and every modern e-commerce theme. If you open the print dialog without scrolling, Chrome asks the page to render — and the page hands back gray blanks or nothing at all for every image below the initial screen.

2. A fixed viewport for print. Chrome's print pipeline uses whatever the CSS @media print rules say the page width should be, then paginates by slicing that layout at page boundaries. But it does not scroll the live page while it does this. It calls the DOM's current state, layout, and rasterize. Anything an image or script needed a scroll event to trigger simply never fires.

3. Async and virtualized content. Comments on Disqus. Reactions on Reddit. Product reviews on Amazon. Recommended posts at the bottom of a Substack. Threads on Twitter/X. Search results on Google. All of these render only when the user scrolls to them, and many use "virtualization" (React Window, TanStack Virtual) — they actively remove elements from the DOM once you scroll past. Print sees the last-scrolled slice, not the whole feed.

The result is the pattern you keep seeing: page 1 looks correct, page 3 has a broken image, page 5 is a blank white rectangle, and page 8 says "Comments (247)" with zero comments visible. It is not a Chrome bug. It is Chrome doing exactly what the page told it to.

There is a related second failure mode: pages that cut off horizontally. That is a CSS problem, not a loading problem — the page has a fixed pixel width wider than the print sheet. Fix 3 below handles that.

Fix 1: force-load everything by scrolling first

The zero-tool solution. Before you press Cmd+P (or Ctrl+P), do this:

1. Press End to jump to the bottom of the page.
2. Wait 2-3 seconds. Watch for spinners, "Loading more..." text, or the scrollbar getting shorter as new content injects.
3. If it is an infinite-scroll page (Twitter, Reddit, TikTok, Pinterest, Google Images), keep pressing End until it stops growing. This can take a minute on a long thread.
4. Now press Home to jump back to the top.
5. Now press Cmd+P / Ctrl+P.

The End + Home trick works because every lazy image between top and bottom gets its IntersectionObserver triggered during the scroll. Chrome caches the loaded image bitmaps in memory even after you scroll away from them, so by the time the print dialog opens, all of them are ready.

Edge case: expandable sections. "Show more," "Read the full article," accordions, tabs — you have to manually click these before printing. Chrome's print engine does not simulate clicks. If the page hides half its content behind a "Show more" button, that half is not going to appear in your PDF unless you press the button first.

Edge case: virtualization. On sites that unmount off-screen content (most React feeds), scrolling loads it but scrolling away unloads it. Fix 1 will not work for these. Skip to Fix 2 or Fix 4.

Fix 2: use an auto-scrolling extension

The problem with Fix 1 is that manual scrolling on a 300-comment Reddit thread takes real time, and virtualized feeds defeat it entirely. Extensions solve both by scrolling programmatically at the right pace and disabling virtualization tricks before rendering.

Convert Web to PDF does this in one click. Before rendering, it:

• Scrolls to the bottom in small increments, waiting for each lazy-load event to fire.
• Detects "Load more" style buttons and clicks them until they stop appearing.
• Waits for network idle (no more image or XHR requests in flight) before capturing.
• Renders the full-height DOM as a single continuous PDF, so pagination happens after all content exists.

That last part matters — Chrome's built-in print paginates first, so if content loads mid-print, later pages can render at a different width or with different fonts. A capture-then-paginate tool avoids that entire class of bug.

Other extensions do similar things with different trade-offs. Some render server-side (your page gets sent to their cloud), some render locally. If you care about the page containing personal information — a bank statement, a healthcare portal, an internal Confluence doc — local rendering is the only safe choice. We wrote about the general privacy issue with online converters in Are Online PDF Converters Safe? — the same math applies here.

Fix 3: landscape + 80% scale

This one fixes the horizontal cutoff, not the vertical one. Symptoms: the right edge of every page is chopped, tables lose their last column, code blocks trail into nothing, dashboards have half their charts missing.

Root cause: the page's print CSS defines a layout wider than the paper. A wide dashboard, a wide code block with no line-wrap, a fixed-width sidebar that print CSS forgot to hide. Chrome will not squish it to fit — it slices it.

In the print dialog:

1. Change orientation to Landscape. This gives you 11 inches of horizontal room instead of 8.5.
2. Under "More settings," set Scale to Custom and enter 80 (or lower).
3. Toggle Background graphics on if you want the page's colors and images (Chrome hides them by default to save ink).
4. Preview the right edge. If content is still cut, drop scale to 70, then 60.

Below about 55% the text gets uncomfortably small for reading. If you are still losing content at 55% scale in landscape, the page is designed for a resolution wider than any reasonable PDF and you should use Fix 4.

Bonus: landscape is also the right choice for wide screenshots (spreadsheets, timelines, Gantt charts, org charts). We covered the trade-offs in Full-Page Screenshot Chrome: PDF Alternative — a PNG at native resolution avoids the scale problem entirely, though you lose text search.

Fix 4: headless render (Puppeteer)

For the truly stubborn pages — infinite scroll with heavy virtualization, dashboards behind SSO, pages that detect the print dialog and hide content — the answer is a headless browser you fully control. Puppeteer is the standard tool.

The minimum working script:

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.setViewport({ width: 1400, height: 900 });
  await page.goto('https://example.com/long-article', {
    waitUntil: 'networkidle0',
  });

  // Force-scroll to trigger lazy loads
  await page.evaluate(async () => {
    await new Promise((resolve) => {
      let total = 0;
      const step = 300;
      const timer = setInterval(() => {
        window.scrollBy(0, step);
        total += step;
        if (total >= document.body.scrollHeight) {
          clearInterval(timer);
          resolve();
        }
      }, 200);
    });
  });

  await new Promise((r) => setTimeout(r, 2000));
  await page.pdf({
    path: 'out.pdf',
    format: 'A4',
    printBackground: true,
  });
  await browser.close();
})();

That handles Fix 1 and Fix 2 in code, and gives you full control over the viewport width (Fix 3). The networkidle0 wait plus the manual scroll plus the two-second buffer covers 95% of pages. For SSO-protected pages, add page.setCookie() with your session cookie or use page.type() to log in first.

The trade-off: you are running a real Chrome instance for every PDF. On a laptop that is fine for a handful of pages a day. At any scale you want to batch — see Batch Convert Files to PDF for how to think about that pipeline.

Comparison table of methods

Pick Fix 1 for a one-off. Pick Fix 2 for daily use. Pick Fix 3 for wide-layout cutoffs. Pick Fix 4 when you are automating.

The one combination that always fails: expecting Chrome's raw Cmd+P to handle a modern page with no preparation. It will not. The print engine was designed in an era when pages were mostly static HTML, and it has not caught up to lazy loading, virtualization, or async rendering.

For a deeper walkthrough of the plain Chrome workflow — before you start hitting these limits — see How to Save a Webpage as PDF in Chrome. And if headers and footers are your problem instead of missing content, Save a Webpage as PDF Without Headers and Footers covers that specifically.

Frequently asked questions

Why does Chrome cut off my webpage when I save it as PDF?

Chrome's print engine snapshots the page's current DOM state and paginates from there. If images are lazy-loaded, if infinite-scroll content has not been reached, or if the page uses virtualization to remove off-screen elements, those pieces do not exist at the moment Chrome captures. You see the blanks — gray rectangles, missing images, empty comment sections — because that is literally what the page was serving to Chrome. The page never got a scroll event to trigger the missing content, and Chrome does not simulate one on your behalf.

How do I save a full-length webpage as PDF?

Scroll from the top of the page all the way to the bottom before opening the print dialog. Wait a few seconds at the bottom for anything still loading, then scroll back to the top. Now open Cmd+P (Ctrl+P on Windows). For infinite-scroll pages you have to keep scrolling until the page stops growing — this can take a minute on a long Twitter thread or Reddit comment section. If the page still cuts content, use an extension that auto-scrolls before rendering, or run a Puppeteer script that does the same thing programmatically.

Why are images missing from my saved PDF?

Since Chrome 76, images with the loading="lazy" attribute do not download until they are near the visible viewport. WordPress, Medium, Substack, and most modern CMSes add this attribute to every image. If you print without scrolling, Chrome captures a page where those images are still gray blanks. The fix is to scroll the full length of the page first — every image between top and bottom will fire its intersection observer and download. Then scroll back to the top and print. Chrome keeps the loaded bitmaps in memory even after they leave the viewport.

How do I make Chrome load all images before printing?

Two options. Manual: press End to jump to the bottom, wait 2-3 seconds for lazy loads to finish, press Home to return to the top, then Cmd+P. This works for finite pages. Automated: install an extension like Convert Web to PDF that scrolls the page programmatically, waits for network idle, and only then captures. For infinite-scroll pages the automated option is the only realistic one — manually scrolling a 500-comment thread and waiting for each batch to load is technically possible but not something you want to do twice.

Does landscape mode fix cut-off PDFs?

Landscape fixes one specific problem: pages that are cut off on the right edge because the page's layout is wider than portrait paper. It does not fix pages that are cut off at the bottom (that is a lazy-loading problem — see Fix 1). Landscape gives you 11 inches of horizontal width instead of 8.5, which is usually enough for wide code blocks, dashboards, and tables. Pair it with a scale of 70-80% for pages that are wider still. If you have both problems — wide layout and lazy images — you need both fixes: scroll first, then print in landscape.

Bottom line

Chrome's Save as PDF is not broken, but it is honest. It captures the page as the page is, not as the page would be after a human interacts with it. Every "cut off" PDF is really an unloaded PDF — the content was never on the screen when Chrome asked for it.

Fix it in the order that matches your effort budget: scroll before printing for a one-off, install an extension for daily use, script it with Puppeteer if you are automating. If you want the one-click version, Convert Web to PDF auto-scrolls, waits for network idle, and renders the full page locally — no upload, no cutoff.