Why copying a table from a website goes wrong
You land on a page holding exactly the numbers you need, sitting in a tidy grid, and there is no download button anywhere. So you try to copy a table from a website the manual way, and it goes badly in one of three predictable ways.
You select it, and the highlight grabs the navigation menu and half the footer along with the rows you wanted. You paste it, and the columns collapse into one, or every row lands inside a single cell, or the page's styling comes along and Excel starts rendering blue links and grey stripes. You look for an export option, and it does not exist, because whoever built the page never expected anyone to want the data out.
That is the whole problem. It is small, it is boring, and it turns up constantly.
So instead of fighting the table, I use a script that adds the missing export button myself.
What the script adds to every table
Once it is installed, every table on every page you open gets two buttons sitting directly above it.
The Copy button
This copies the table to your clipboard in a spreadsheet-ready shape — tab-separated values, which is the format Excel and Google Sheets expect when you paste. Columns land in columns. Rows land in rows. Nothing needs fixing afterwards.
The script builds this from the table's own structure rather than from what your mouse selected, which is why the navigation menu never comes along for the ride. If you want the mechanics, MDN's documentation on the Clipboard API covers the browser side of it.
The Export CSV button
This downloads the same table as a .csv file you can open in Excel, Google Sheets, Numbers, or load straight into a database. Commas inside cells get quoted, quotes get escaped, so a company name like Smith, Jones & Co. does not silently split into two columns. That behaviour follows RFC 4180, the CSV format specification, which is the reason a properly escaped file opens cleanly in tools that otherwise disagree about everything.
Two buttons. No settings screen, no account, nothing to learn.
Installing the Tampermonkey userscript
A userscript is a small piece of JavaScript that runs automatically on pages you visit. It needs a manager extension to hold it, and the common one is the Tampermonkey extension, which works in Chrome, Edge, Firefox, and Safari.
The sequence is: install Tampermonkey from your browser's extension store, open its dashboard, create a new script, paste the code in, save. From then on the buttons appear on their own. There is no step where you have to remember to turn anything on.
If you have never installed a browser extension before, that is the only genuinely unfamiliar part, and it takes about two minutes.
Where it works and where it breaks
The original version of this article said it works almost everywhere. That is close to true and not quite true, and the gap is worth knowing before you rely on it.
Tables it handles
Anything built as a real HTML table — the underlying markup a browser uses for grid data. In practice that covers most of what you actually want:
- Data tables on reference and statistics sites
- Pricing tables
- Financial and historical data pages
- Report exports rendered in the browser
- Directory and product listings
It also copes with pages that load their rows after you arrive, including tables that fill in as you scroll, because the script reads the table at the moment you click rather than at the moment the page opened.
Tables it does not
Some things that look like tables are not tables. A layout built from stacked div elements renders identically to your eye and is invisible to a script looking for table markup. So do these:
- Virtualised tables, where the page keeps only the visible thirty rows in memory and discards the rest as you scroll. You get the thirty, not the thousand.
- Tables inside an iframe, an embedded page-within-a-page, which the script cannot reach across.
- Canvas-rendered grids, common in financial dashboards, where the table is drawn as pixels and contains no readable text at all.
- Login-gated data that only appears after a session, a click, or a filter selection.
When one of those is the problem, a click-to-copy button is the wrong tool and no amount of tweaking makes it the right one.
The time this actually saves
Take a page of historical statistics. The manual route is: highlight the rows, paste into Excel, discover the columns merged, split them by hand, strip the stray header text, fix the numbers that arrived as text. When I have timed myself doing that, it runs somewhere between five and ten minutes for a table of any real size — my own estimate, not a measured study, and it depends heavily on how badly the paste lands.
The script route is: click Copy, paste, done. Or click Export CSV, open the file, done.
The saving on any single table is small. The saving across forty of them, which is what a week of research actually looks like, is most of a working day.
When a one-size script is not enough
The script does one thing and stops there, which is deliberate. But the requests I get most often are the ones it cannot answer:
- The data spans two hundred paginated pages and you need all of them
- It sits behind a login, a search form, or a set of filters
- You need it refreshed every morning without anyone clicking anything
- You need it landing in PostgreSQL or Airtable rather than in a folder of loose CSV files
- The site is a virtualised or canvas grid, so there is no table to read
Those are jobs for a purpose-built scraper — a Python and Playwright bot that drives a real browser, works through the pagination, handles the login, and writes to wherever you want the data to live, on a schedule. That is the bulk of what I do. You can see the browser automation services I offer , or hire me to build a custom scraper for your specific site. I sell through Fiverr, and I scope every job before quoting it.
If you would rather read further first, I keep more write-ups on scraping and automation.
Terms of service and robots.txt
One thing I will not do is tell you that scraping a particular site is fine. It is not my call to make.
What I can tell you is the technical position. A userscript runs in your own browser on a page you have already opened, which is different in kind from a bot hitting a server a thousand times an hour. Neither one exempts you from the site's terms of service, and both sit alongside whatever the site publishes in its robots.txt file — Google's guide to robots.txt explains what that file is and how it is meant to be read.
Read the terms, check the file, decide for yourself. When I build something to order, I build to whatever boundary the client sets.