TL;DR
You convert a long page to PDF and get a fraction of it back. Grey placeholder boxes where photos were. A product grid that stops after 12 items. A comment thread that ends at comment 20.
This is not one bug. It's three different loading patterns, and telling them apart takes about five seconds and determines the fix:
| What you see in the PDF | Pattern | Fix |
|---|---|---|
| Right structure, blank image boxes | Lazy-loaded images | Load All Images |
| Content stops at a fixed count, page was long on screen | Infinite scroll | Scroll to the bottom first, then convert |
| Content stops at a fixed count even after scrolling | Virtualized list | Convert in sections, or capture the element |
The third one is the one nobody warns you about, and it's the reason "just scroll first" sometimes doesn't work. Convert: Web to PDF handles the first two directly. The third has a hard limit that no browser extension can engineer around, and this post explains why.
The five-second diagnosis
Before you change any settings, do this:
- Open the page. Don't scroll.
- Press
EndorCmd/Ctrl + ↓to jump to the bottom. - Watch what happens, then scroll back up a few screens and look at what's there.
If new content loaded as you went down and everything you passed is still there when you scroll back up — infinite scroll. Easy case.
If new content loaded as you went down but content near the top is now gone or replaced with blank space — virtualized list. Hard case.
If the page length never changed but images filled in as you passed them — lazy-loaded images. Easiest case.
Many real pages are two of these at once. A social feed is usually virtualized and lazy-loading images. An e-commerce category page is usually infinite scroll and lazy-loading images.
Pattern 1: Lazy-loaded images
What's happening
Essentially every site built after 2019 defers image loading. The HTML ships with a placeholder — often a 1×1 pixel, a blurred thumbnail, or nothing at all — and the real src is only set when the image approaches the viewport. Native loading="lazy" is now the default behaviour on most platforms, and every major CMS does it.
This is good for page speed and terrible for conversion, because a converter that reads the current DOM sees placeholders for every image you haven't scrolled past.
Why it looks like a converter bug
It isn't. The image genuinely isn't in the page yet. There is no "high quality version" the tool is failing to fetch — the browser has never requested that file.
Chrome's built-in Print to PDF fails this on most sites, which is the single most common reason people go looking for an extension in the first place.
The fix
Convert: Web to PDF has a Load All Images step that walks the page and triggers every deferred image before capture. On a gallery or a photo essay this is the difference between a document and a stack of grey rectangles.
Two things worth knowing:
- It takes time on heavy pages. A 300-image gallery is 300 network requests. Give it a few seconds.
- It can't recover images the site never serves. If an image 404s, or is behind a CDN that's blocking you, no amount of pre-loading conjures it.
The extended FAQ covers loading every image on a long gallery before converting.
Pattern 2: Infinite scroll
What's happening
The page ships with the first N items. When you approach the bottom, JavaScript fetches the next batch and appends it to the DOM. Nothing is removed. The page genuinely gets longer.
Search results, e-commerce category pages, blog archives, Reddit comment threads, most news site feeds.
Why the PDF stops short
Because at the moment of conversion, the DOM contained exactly what had been loaded. If you clicked convert after seeing 12 products, the page contained 12 products. The other 400 were never fetched.
The fix
Scroll to the bottom first, wait for loading to finish, then convert. That's it. Since everything stays in the DOM, the converter now sees all of it.
Practical notes:
- Wait for the spinner to stop. Converting mid-fetch gives you a partial batch plus a loading indicator baked into the PDF.
- Some feeds are effectively endless. A social feed will keep appending until you give up. Decide what "enough" means before you start, and be aware that a genuinely endless feed produces an enormous document.
- Expect a big file. A category page scrolled to 800 products is a real 800-product document.
We're honest about the boundary here: the extension captures what is loaded. It does not drive the page for you, and it will not click "load more" 40 times on your behalf. Scroll first.
The single-item rule
For anything you actually care about archiving — a specific listing, a specific post, a specific order — open the item's own page and convert that. A single item page is stable, complete, and permanent-ish. A feed position is none of those things. This is the most useful habit in this entire post.
Pattern 3: Virtualized lists — the hard one
What's happening
Virtualization (also called windowing) renders only the rows currently near the viewport and destroys the ones that scroll out of view, replacing them with an empty spacer of the right height. The scrollbar looks like a 10,000-row list. The DOM contains about 30 rows.
Libraries like react-window, react-virtualized, TanStack Virtual, and AG Grid's row virtualization do this by default. So do most modern data tables, admin dashboards, and — increasingly — social feeds and chat clients.
How to be sure
Scroll down 20 screens, then scroll back to the top. If the content near the top has been replaced by blank space that then re-populates after a beat, it's virtualized. Confirm it definitively by pressing Cmd/Ctrl + F and searching for text you saw near the top — the browser's own find won't locate it, because it isn't in the document.
Why no extension can fully solve this
This is worth stating plainly rather than hedging. A browser extension converts the DOM. If the DOM only ever contains 30 of 10,000 rows, there is no moment at which all 10,000 rows exist to be captured. Pre-scrolling doesn't help — scrolling is what destroys the earlier rows.
Any tool that claims to convert an arbitrary virtualized list in one pass is either not doing what you think, or is capturing screenshots during a scroll and stitching them into an image. That gets you pixels, not a document: nothing selectable, nothing searchable, no working links.
What actually works
Look for a non-virtualized view first. This is nearly always the fastest path, and people skip it:
- Many data tables have a print view, an export button, or a
?view=printstyle URL - Many apps have a "show all" or per-page setting — set it to 100 or 500 and the list often stops virtualizing
- Many dashboards will export CSV, which you can then convert with Convert: Anything to PDF into a formatted table
Convert in sections. Scroll to a position, convert, scroll further, convert again. You get several PDFs covering the whole range. Inelegant, but it's honest work and it produces real text.
Capture Element. If what you need is one region — a specific card, a chart, a summary panel — use Capture Element to grab just that, with the text still selectable. Far better than converting the whole viewport and cropping.
Reduce the window. Zooming the browser out (Cmd/Ctrl + −) puts more rows in the viewport, which means more rows exist in the DOM at once. At 50% zoom you might hold 80 rows instead of 30. It's a partial mitigation, not a fix, but it can turn six passes into two.
The combinations you'll actually meet
Real pages layer these. Here's what to do for the common ones.
| Page type | Patterns present | Approach |
|---|---|---|
| Photo essay / long-form article | Lazy images | Load All Images, convert |
| E-commerce category page | Infinite scroll + lazy images | Scroll to bottom, Load All Images, convert |
| Single product page | Lazy images | Load All Images, convert |
| Reddit thread | Infinite scroll (comments) + collapsed replies | Expand replies, scroll, convert |
| Admin data table | Virtualized | Look for print/export view first |
| Chat / Slack / Discord history | Virtualized + lazy | Convert in sections |
| Documentation site | Usually neither | Just convert — but stay out of Article Mode if there's code |
| Analytics dashboard | Lazy charts, sometimes virtualized tables | Capture Element per widget |
That last row deserves a note: charts often render asynchronously and animate in. Converting the instant the page loads catches them mid-animation or empty. Let the page settle for a few seconds — the FAQ covers waiting for animations to finish before capturing.
Why single-page apps make all of this worse
A React, Vue, or Next.js app builds the page after the JavaScript runs. View the source and you'll see almost nothing — a root div and a script tag.
This is exactly why a browser extension beats a URL-based converter here, and it's not a marketing point, it's a mechanical one:
URL-based converters (PDFCrowd, Webtopdf-style services, anything where you paste a link) fetch the URL from their own servers. They get whatever that fetch returns — often the empty shell, often a login wall, never your session. Some run a headless browser to render JavaScript, which helps, but they still aren't logged in as you and don't have your page state.
Browser extensions convert the DOM that's already rendered in your tab. JavaScript has run. You're logged in. The page is in whatever state you put it in — filters applied, sections expanded, feed scrolled. That's the whole advantage.
Screenshot tools (GoFullPage and similar) capture pixels during a scripted scroll. They handle lazy images well as a side effect and produce an image, so you lose selectable text, working links, and any accessibility at all.
Convert: Web to PDF renders through Chrome's own print engine, so the output is a real PDF with selectable text and clickable links, and nothing is uploaded anywhere — which is the only reason converting a logged-in dashboard is a reasonable thing to do at all.
A short checklist
Before you convert anything long:
- Jump to the bottom and watch what happens
- Scroll back up and check whether earlier content survived
- If images are blank → Load All Images
- If content stops but survives scrolling → scroll fully, wait, convert
- If content doesn't survive scrolling → find a print/export view, or convert in sections
- If it's one item you care about → open its own page instead
- Let charts and animations settle before you click
Frequently asked questions
Why are images missing or blank in my PDF?
The site defers image loading until each image nears the viewport, so images you never scrolled past were never downloaded. Use Load All Images before converting, which walks the page and triggers every deferred image. If an image is still blank afterwards, the site isn't serving that file.
Why does my PDF stop partway down a long page?
Either the page uses infinite scroll and the rest was never loaded (scroll to the bottom first, then convert), or it uses a virtualized list that only keeps a few dozen rows in the document at a time (scrolling won't help — look for a print or export view, or convert in sections).
What's the difference between infinite scroll and a virtualized list?
Infinite scroll adds content as you scroll and keeps everything. Virtualization swaps content in and out, keeping only what's near the viewport. Test by scrolling far down and then back up: if the top content is still there, it's infinite scroll; if it briefly blanks out and re-renders, it's virtualized.
Can any tool capture a full virtualized list in one pass?
Not as a real text PDF, no — the rows don't exist in the document at the same time. Tools that appear to do it are stitching screenshots into an image, which gives you pixels rather than selectable text. The reliable routes are a print/export view provided by the app, a CSV export, or converting in sections.
Does scrolling to the bottom of an infinite feed work for something like a social timeline?
Mechanically yes, practically no. Endless feeds keep appending until you stop, and social feeds are usually virtualized as well. For anything you actually want to keep, open the individual post's own page and convert that — it's stable, complete, and it won't change under you.
Will Article Mode fix a half-empty page?
Sometimes, for articles — Readability rebuilds the page as a clean single column and often pulls in the full body text. But it's tuned for article-shaped pages: on a feed, dashboard, or app UI it usually grabs the wrong region, and on code-heavy documentation it can drop <pre> blocks. For code, stay in default mode and use Remove Elements instead.
Does the extension need to send the page anywhere to do this?
No. Loading images and converting both happen inside your browser. Nothing is uploaded, which is why this works on pages you're signed into.
Bottom line
A half-empty PDF almost never means the converter failed. It means the page hadn't loaded the content yet — and why it hadn't determines what you do about it.
Lazy images: pre-load them. Infinite scroll: scroll first. Virtualized lists: find another view, or accept sections.
And when it's one thing you care about — one listing, one post, one order — open its own page. A stable item page beats a feed position every time, and it takes less effort than any of the workarounds above.
Convert: Web to PDF is free, local, and watermark-free. The full FAQ has more on long and dynamic pages.
Related tool: CineMan AI — for the other infinite scroll problem, the one where you browse Netflix for 40 minutes and watch nothing.