Why your table export only has the rows you can see

The table says 2,431 rows. You export it and get 50. Nothing errored.

This is almost always virtualisation, and it is worth ten minutes of your time
to understand, because it is the one failure mode where a tool that says
nothing is worse than a tool that refuses.

What is happening

Rendering thousands of rows is slow, so grids render a window: the rows you can
see plus a few above and below. As you scroll, rows outside that window are
removed from the page and new ones are created. react-window, react-virtualized,
TanStack Virtual and AG Grid's own row virtualisation all work this way, and so
does every infinite-scroll list.

So at any moment the page contains fifty rows. Not fifty visible out of 2,431
present, fifty present. Copy, select-all, an extension, a console script: they
all read the same page, and they all get fifty, because that is what is there.

Confirming it

Paste this into the DevTools console:

const g = document.querySelector('[role="grid"],[role="treegrid"],table');
console.log({
  claims: g.getAttribute('aria-rowcount'),
  inPage: g.querySelectorAll('[role="row"],tr').length
});

The aria-rowcount attribute is the grid telling assistive technology how many
rows exist in total. When that number is much larger than the number of rows in
the page, you have your answer. Not every grid sets it, but the well-behaved
ones do.

What to do, in order of how well it works

1. Find the page's own export. A Download CSV or Export to Excel button
asks the server and returns every row. This is the only route that is both
complete and reliable, and it is worth looking for properly before trying
anything else.

2. Turn up the page size. Many grids have a rows-per-page control at the
bottom offering 25, 50, 100 or All. Switching to the largest value often turns
off virtualisation entirely, and then a normal copy or extract gets everything.

3. Check for a print view or a URL parameter. Plenty of internal tools
accept a limit or per-page value in the query string, or have a printable
version that renders the whole set as a plain table. Look at what the
pagination links put in the URL.

4. Scroll the whole grid, then extract. This works only on grids that keep
rows once they have been rendered, which is a minority. On a true virtualiser
the rows behind you are already gone, so scrolling gains you nothing. Try it,
then re-check the count with the snippet above before you trust the result.

5. Go to the API. Open the Network tab, filter to Fetch/XHR, page the grid
so it refetches, and read the JSON. Usually you can request a larger page size
directly. Right-click the request, Copy as cURL, and it carries your session
with it.

Why an extension cannot fix this for you

A browser extension sees the same DOM you do. There is no privileged path to
rows that were never rendered. An extension could scroll the grid for you, but
on a real virtualiser that discards what it scrolls past, and on an
infinite-scroll list it can take minutes and still miss rows that load late.

What a tool can do is tell you. GridPick compares the number of rows
actually in the page against what the grid claims, and says so before you
export, instead of handing you 50 rows out of 2,431 and letting you find out
later. Most tools say nothing, which is how a partial export ends up in a
report.

The version of this that is not virtualisation

Two other things produce the same symptom and have different fixes:

• Pagination. The grid genuinely shows 50 rows and there are 49 more pages. Look for the page control, or set rows-per-page to All.
• Lazy loading on scroll. Rows are appended as you reach the bottom, and nothing is removed. Here scrolling to the end really does work: scroll until the count stops growing, then extract.

The console snippet above tells the three apart in one line, so run it first.