Paste any page URLs, one per line, then say what you want out of them - either as a sentence in the Prompt box or as a schema you build field by field. Claude reads each page and returns what you asked for. The fields you name are the columns; there is no per-site parser and no fixed set to work around.
Two required inputs, and the second one you can give in whichever form suits you.
You need one of the two, not both: the form will stop you only if the Prompt is empty and no schema field has been defined. If you write both, you are giving the model the instruction and the shape.
Add a field called price and the file has a column called price. There is no mapping step and no supported-site list, because nothing here is written per site. That is what makes it worth reaching for on the pages no dedicated scraper covers - a supplier's catalogue, a regulator's notices, a competitor's changelog.
The Prompt box takes plain description and is the fastest way to try something. The Schema builder is the one to use when the output has to be predictable: each field carries a type - String, Number, Boolean, Array or Object - and can be marked required. A JSON tab shows the same schema as JSON Schema, so you can paste one you already have.
When the export carries a query column it is placed first, so every row says which URL produced it and a file covering fifty pages stays groupable. One quiet detail worth knowing: an internal position key is deliberately excluded from the assembled columns, so it appears in neither the table nor the downloads.
Every other product page here names a fixed set of columns. This one cannot, and the reason is structural rather than an omission.
The fields you describe are the file. This service has no declared column array anywhere in it. The column list is assembled after the run, from the keys that actually came back: query first when it is present, then every other key in the order it was first seen. Ask for sku, price and in_stock and those are your columns, in that order. Ask for something the page does not carry and you should expect an empty cell rather than an invention - but check that on your own first run rather than taking it from a marketing page.
Prompt or schema is a real choice, not two words for the same thing. A prompt is faster and more forgiving, and it is the right tool when you are still working out what a page even contains. A schema is what you want the moment the output feeds anything downstream: naming the fields and their types is how you stop the shape drifting between one run and the next, and marking a field required is how you say it matters. The builder and the JSON view are the same schema, so you can start by clicking and finish by pasting.
Two practical differences from the rest of the platform. The limit here counts rows per URL rather than pages, and it is empty by default, which means all - the opposite of a tool that stops after one page unless you tell it otherwise. And each page is fetched through the proxy pool rather than from your own address: if a paid PROXY_URL or PROXY_LIST is configured it uses that, otherwise the free pool, and in neither case your real IP.
What this page will not tell you is how well any particular extraction turns out. We have no populated export from this service to describe, and quality here depends on the page you point at and the words you choose - so there is no accuracy figure, no sample file and no promise about a given cell. Spend a few free rows on one page, read the columns, then widen the list.
All of them are pages that no dedicated scraper covers.
Most scraping work is not Amazon or LinkedIn - it is a trade distributor, an industry association's member list, a council's licence register. Point this at those pages, name the four fields you actually need, and you get a table without anyone writing a parser for a site you will use twice.
Start in the Prompt box on a handful of pages, see what comes back, then move the fields that proved useful into the Schema builder and give them types. That path - describe loosely, then pin it down - is why both inputs exist.
A pricing page, a terms page, a status page: the wording moves, the markup moves, and a selector-based scraper breaks on both. Describing the field instead of its position is what survives a redesign, which makes this a reasonable choice for something you intend to re-run.
No subscription, no minimum, no per-seat licence. Your first 500 rows are on us - after that it is pay-as-you-go.
For every new account, one time. No credit card. All scrapers unlocked. On this service in particular the free tier is where you belong first: it costs nothing to find out whether your prompt or your schema returns what you meant.
Roughly $2 per 1,000 rows, the same flat rate as every other scraper on the platform - an AI-driven extraction is not billed differently from a fixed-schema one. The limit counts rows per URL and defaults to all, so it is worth setting a number while you are still testing wording.
Volume pricing, SLAs, dedicated workers and tailored onboarding for teams running this across a long list of sources rather than a handful of pages. Tell us your numbers and we will quote.
LIVESCRAPER10 at checkout.Describing fields is the right tool for pages nobody has parsed. Where a dedicated scraper exists, use it - the columns are already known.
The same idea with a simpler input: instead of a prompt or a typed schema you pick attributes from a list, and its limit counts pages per query rather than rows per URL. Reach for it when a short list of attributes is all you need.
The same page as an image rather than as fields. Useful next to an extraction when you need evidence of what a page said on the day you read it, not just the values you pulled out of it.
Before describing fields by hand, check whether the site already has a dedicated scraper here. Those return a documented column set, which is a better starting point than any description you or we could write.
Short answer: the rules are the ones that already applied to scraping - using a model to read the page does not change what you are allowed to collect.
Collecting publicly visible information for research and analysis is long-settled practice, and that is what happens here: the page is fetched as an ordinary visitor would see it, and a model reads it. As long as the data is publicly available and the process does not disrupt the service, there are no federal laws against it. What the model does not do is get you past anything - nothing behind a login, a paywall or a consent wall is in scope.
This service is more open-ended than the rest of the platform, and that puts the responsibility for scope on the person writing the prompt. A schema that asks for names, emails or anything else identifying a person means you are handling personal data, and the GDPR and similar regimes apply to you regardless of where you got it. Ask for what your purpose actually needs; a field you cannot justify is a liability rather than a bonus.
Every site's own terms still apply, and they vary - check them for the pages you intend to run. We touch nothing behind a login, read only what an ordinary visitor sees, run no third-party trackers on the data layer, and your exports self-delete after 30 days.
The questions we hear most. Something else? Talk to us - humans write the answers, not bots.
Paste one URL, describe what you want in a sentence or as a schema, and see what comes back. Your first 500 rows are free.
Most scraping tools begin with a site and hand you its schema. This one begins with a schema and lets you point it at a site. Paste any page URLs, one per line, describe what you want - as a sentence in the Prompt box, or as a set of fields in the Schema builder - and each page is fetched and read by Claude, which returns the fields you named. There is no per-site parser here, so there is no supported-site list to check yourself against.
The two ways of asking are genuinely different tools. A prompt is loose and fast, and it is what you want while you are still finding out what a page carries. A schema pins the output down: each field has a name and a type - String, Number, Boolean, Array or Object - and can be marked required, which is how you keep the shape stable across repeated runs. The builder and the JSON view are the same schema in two forms, so a schema you already have can be pasted in, and one you click together can be copied out. You need one of the two; giving both simply tells the model the instruction and the shape.
Because you define the fields, the file has no fixed column list, and this page therefore has no data dictionary. The columns are assembled after the run from the keys that actually came back - query first when it is present, so every row records which URL produced it, then everything else in the order it first appeared. An internal position key is excluded from that list, so it shows up in neither the table nor the downloads. Two smaller differences from the rest of the platform are worth knowing: the limit counts rows per URL rather than pages and is empty by default, meaning all; and pages are fetched through the proxy pool - a paid PROXY_URL or PROXY_LIST if one is configured, otherwise the free pool, and never your own address.
One thing this page deliberately does not do is tell you how good the extraction is. Quality depends on the page and on your wording, which makes any single accuracy figure misleading in both directions, and we would rather say that than publish a number we cannot stand behind. The honest advice is the cheap one: run a single page on the free tier, read the columns you got back, adjust the field names or the sentence, and only then point it at a list. Your first 500 rows cost nothing and need no credit card. See pricing for current rates.