Web scraping vs page capture: two different jobs
Scrapers extract data and throw the page away. Capture keeps the page and ignores the data. Picking the wrong one wastes weeks.
People arrive at both from the same search — "get this website" — and the tools are not interchangeable. One optimises for fields, the other for pixels.
Scraping: keep the data, discard the page
A scraper visits URLs and pulls structured values out: price, title, rating, stock, address. The output is a CSV, a database table or JSON. Everything about the page's appearance is noise to be stripped, and the hard problems are pagination, rate limits, anti-bot systems, selector drift when the site redesigns, and normalising messy values.
Use it for price monitoring, lead lists, research datasets, feed building, SEO audits at scale.
Capture: keep the page, discard the data
A capture records the page as rendered — DOM, computed styles, fonts, images, canvas pixels — and produces a document that looks and behaves like the original when opened later, offline. The values inside are just text; nobody is going to aggregate them. The hard problems are completely different: webfont loading order, pseudo-elements, hidden SVG sprites, srcset selection, CSS masks, quirks mode, and assets behind hotlink protection.
Use it for migrations, design references, offline reading, evidence and compliance records, QA regression baselines, and handing a real page to a coding agent.
Side by side
| Scraping | Capture | |
|---|---|---|
| Output | CSV / JSON / DB rows | HTML file, ZIP, CMS blocks |
| Success test | Are the fields correct and complete? | Does it render identically offline? |
| Scale | Thousands of pages | One page, or a bounded crawl |
| Fails because of | Selectors, blocks, pagination | Fonts, CSS, embedding, lazy content |
| Legal centre of gravity | Terms of service, database rights, access controls | Copyright in the page's content and assets |
| Typical user | Data/growth engineer | Designer, agency, marketer, archivist |
The overlap, and how to handle it
Sometimes you genuinely want both: an archive of a page and the numbers on it. The clean way is to capture first and extract from the capture. A capture is a frozen, self-contained artefact — parse it locally as many times as you like, with no further requests, no rate limits and no risk that the site changed between passes. It also means your dataset has a provenance record attached: this is the page it came from, on this date, exactly as it looked.
The reverse — scraping and then trying to reconstruct the page from fields — never works, because the page was never in the data.
Where CopyAnySite sits
Firmly on the capture side. It reads the page you already have open, embeds the assets, and exports it as a standalone file, a ZIP, editable WordPress blocks, or a kit an AI agent can build from. It is not a scraping platform: no proxy rotation, no CAPTCHA solving, no distributed queues, and no crawling behind other people's logins.
If you need fields at scale, use a scraping framework. If you need the page to look right a year from now, you need capture. Our own measurements — eight sites, three runs, every copy rendered with the original server unreachable — put us at 98.87% average pixel fidelity, best on all eight rows, against SingleFile's 87.93%, wget's 87.40% and monolith's 83.44%; re-runnable with npm run bench:rivals.
FAQ
Is copying a webpage the same as scraping it?
No. Scraping extracts structured data and discards the presentation; capture preserves the rendered presentation and treats the data as incidental text.
Can I use a scraper to make an offline copy of a site?
Poorly. Scrapers fetch HTML without reproducing the rendered visual state, and the output is usually missing the CSS, fonts and assets that make the page look like itself.
Which is more likely to get me blocked?
Scraping, by a wide margin — it is high-volume and repetitive. A single browser capture of a page you were already viewing looks like ordinary browsing, though a large crawl should still be paced.
Should I capture pages before extracting data from them?
If provenance or repeatability matters, yes. Parsing a stored capture is deterministic, costs the site nothing, and gives you a dated record of exactly what you parsed.
Do I need a headless browser for either?
For scraping client-rendered sites, yes. For capture, a real browser is the point — the whole approach depends on reading the page the browser already rendered.
Try it on the page you are looking at
CopyAnySite is a Chrome extension: open any page you can reach, press capture, and take away a standalone HTML file, an editable WordPress page, or a kit a coding agent can build from. The free key needs no card.
Download CopyAnySite