DEV Community: Jessy Shen

Why your table export only has the rows you can see

Jessy Shen — Thu, 10 Sep 2026 04:37:24 +0000

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.

Exporting a table that is not a table: React, AG Grid and other div grids

Jessy Shen — Mon, 07 Sep 2026 08:02:55 +0000

Exporting a table that is not a `<table>`

The symptom is always the same. You are looking at something that is
unmistakably a table, with headers and rows and sortable columns, and the tool
you reached for says there is no table on this page.

Why it happens

Modern data grids do not use <table> markup. AG Grid, MUI DataGrid, TanStack
Table, Handsontable, Ant Design Table and most in-house React grids render
nested div elements instead, and describe the structure to screen readers with
ARIA roles:

<div role="grid" aria-rowcount="2431">
  <div role="row">
    <div role="columnheader">Ticker</div>
    <div role="columnheader">Last</div>
  </div>
  <div role="row">
    <div role="gridcell">AAPL</div>
    <div role="gridcell">228.14</div>
  </div>
</div>

They do it because table layout is hard to virtualise, hard to pin columns in,
and hard to resize smoothly. The trade is that anything looking for
document.querySelectorAll('table') comes back empty.

How to tell in five seconds

Open DevTools, go to the Console, and run:

document.querySelectorAll('table').length
document.querySelectorAll('[role="grid"], [role="treegrid"], [role="table"]').length

If the first is 0 and the second is not, you have a div grid, and you now know
why the extension found nothing.

What actually works

Look for the grid's own export first. Many admin panels have a Download CSV
or Export button hiding in a toolbar or a row of icons. It is worth ten seconds
of looking, because that route asks the server and gets every row, not just the
ones on screen.

Use an extractor that reads ARIA roles. Anything that walks role="row"
and role="gridcell" handles div grids. GridPick was built around this
case: it reads real table markup and ARIA grids, and it walks open shadow
roots, which matters because querySelectorAll does not cross a shadow
boundary and several component libraries put their grid inside one.

Or paste this into the console. For a one-off, this copies the visible grid
to your clipboard as tab-separated text, ready to paste straight into Excel:

copy([...document.querySelectorAll('[role="row"]')]
  .map(r => [...r.querySelectorAll('[role="gridcell"],[role="columnheader"]')]
    .map(c => c.innerText.trim().replace(/\s+/g, ' '))
    .join('\t'))
  .join('\n'))

copy() is a DevTools helper, not a page function, so this only works from the
console. If the grid is inside an iframe, switch the console context dropdown
to that frame first.

Two things that will still bite you

Only the visible rows are in the page. Virtualised grids create and destroy
rows as you scroll, so the DOM holds fifty of them no matter how many the grid
claims. Nothing running in the browser can see the rest. See
why your table export only has the rows you can see.

Merged headers move your columns. A header cell spanning two columns, or a
section row written as colspan="99", quietly shifts everything under it. A
naive extractor produces a 99-column export from that section row. The fix is
to measure the real column count from the widest rows and clamp every span to
it, which is what GridPick does before it hands you anything.

If the grid is server-driven

When the page fetches its rows from an API, the cleanest route is not the DOM
at all. Open the Network tab, filter to Fetch/XHR, sort the grid or turn a page
so it refetches, and look at the JSON response. Most of the time you can call
that endpoint yourself with a larger page size and get everything in one
request. Copy the request as cURL from the context menu and it carries your
session cookies with it.