By the fastCRW team · Credit costs and API surface verified 2026-05-18 against the canonical fact sheet · fastCRW launch pricing expires 2026-06-01 · Verify independently before relying on any figure.
Disclosure: We build fastCRW, so weight the product specifics accordingly. The decision framework below is vendor-neutral — JSON schema vs prompt extraction is the same trade-off whatever tool you use — and we have stated fastCRW's real constraints plainly so you plan around what exists, not what we wish existed.
Structured data extraction: JSON schema vs prompts
When you pull fields off a web page with an LLM, you choose between two extraction strategies. Structured data extraction with a JSON schema hands the model a typed contract — field names, types, required-vs-optional — and asks it to fill in that shape. Prompt-based extraction hands the model a natural-language instruction ("pull the product name, price, and reviews") and lets it decide the output shape. Both run on the same page text; they differ in how tightly you constrain the result and, downstream, in how much cleanup and validation you have to do yourself.
The practical question is not "which is better" in the abstract — it is which one matches the page you are scraping and the contract your downstream code expects. This guide walks the trade-offs in reliability, accuracy, and cost, then maps them onto a concrete API so you can ship something instead of theorizing.
Two ways to extract structured data
JSON schema-constrained output
A schema-guided extraction supplies a JSON Schema (or an equivalent type definition) alongside the page content. The model is steered toward emitting exactly those keys, in those types. A schema like { "title": "string", "price": "number", "in_stock": "boolean" } tells the model both what to look for and how to encode it. The output is predictable enough to deserialize straight into a typed struct or a database row without a brittle post-parsing layer.
Freeform prompt extraction
Prompt-based extraction asks in plain language and accepts whatever the model returns — often prose, sometimes loose JSON, occasionally a markdown table. It is faster to write (one sentence, no schema authoring) and more forgiving when you do not yet know what the page contains. The cost is on the consuming side: you parse, normalize, and validate the output yourself, and you handle the cases where the model renamed a field, nested it differently, or wrapped the answer in an explanation.
Why a JSON schema improves reliability
Type and field validation
A schema is a machine-checkable contract. When the model returns price: "19.99" as a string where you declared a number, you can reject or coerce at the boundary instead of discovering the mismatch three services downstream. Required fields make missing data an explicit, catchable failure rather than a silent undefined. This is the same discipline that static typing gives source code, applied to model output — which is otherwise the least trustworthy data in your pipeline.
Fewer malformed outputs to clean up
The looser the instruction, the more variance in the output, and variance is what breaks batch jobs at 3 a.m. A schema collapses that variance: across a thousand product pages with different layouts, schema-guided extraction returns the same key set every time, so your loader code has one shape to handle, not a thousand. You trade a few minutes of schema authoring for the elimination of an entire class of parsing bugs. For any extraction you run repeatedly and feed into structured storage, the schema almost always pays for itself.
When a prompt is the better tool
Exploratory or fuzzy extraction
Before you know what a page reliably contains, a schema is premature commitment. A prompt lets you probe — "what specs does this listing actually expose?" — and read the answer before formalizing it. Exploratory passes, one-off pulls, and questions whose answer is genuinely prose ("summarize the return policy") are all better served by an open instruction than by a rigid contract you would only have to rewrite.
Unknown or variable page shapes
Some sources are heterogeneous by nature — a feed where each item carries different attributes, or a corpus of pages from many sites with no shared template. Forcing every page into one schema there either drops real data (fields the schema did not anticipate) or fills the output with nulls. A prompt that says "extract whatever structured attributes are present" tolerates that variability, and you impose structure later, once you have seen the spread. The honest rule: schema when the shape is known and stable, prompt when it is not.
How extraction maps to the API
formats:['json'] plus a jsonSchema
In fastCRW, structured extraction is a scrape with the JSON format turned on. You call /v1/scrape with formats: ["json"] and pass a jsonSchema describing the fields you want; the engine scrapes the page and returns data shaped to that schema. Omit the schema and provide a natural-language prompt instead, and you get the prompt-based path. Because fastCRW is Firecrawl-compatible REST, this is the same request shape Firecrawl users already write — a base-URL swap, not a rewrite. See structured extraction with a JSON schema in fastCRW for the full request-and-response walkthrough, and the extract endpoint deep dive for the managed convenience wrapper.
Single-URL extraction and how to scale it
Here is a constraint to design around, stated plainly: fastCRW extraction is single-URL. The managed /v1/extract is a convenience wrapper over /v1/scrape with formats: ["json"], and it handles one URL per call. There is no multi-URL batched /v1/extract and no /v1/batch/scrape endpoint — both are Firecrawl Cloud features fastCRW does not implement. To extract from many pages you either iterate /v1/scrape concurrently with your own fan-out, or run a /v1/crawl and apply extraction per page. Self-hosters skip the managed wrapper entirely and call /v1/scrape with jsonSchema directly. If your mental model assumed a batch extract call, adjust it now — the iterate-or-crawl pattern is the supported path, and it is well-trodden, just not a single endpoint.
Cost and provider trade-offs
What JSON extraction costs
Extraction is the most expensive operation on the meter. Any request carrying formats: ["json"] — equivalently, a call to the managed /v1/extract — is the 1-credit scrape plus the LLM token cost, billed as usage-metered LLM credits, versus a flat 1 credit for a plain scrape on any renderer (http, lightpanda, or chrome — there is no JS-rendering surcharge). How much more than a plain scrape depends on page size and token usage, not a fixed multiple. The design consequence is direct: do not run JSON extraction on pages where a cheap markdown scrape plus a regex would do. Reserve the extraction path for genuinely structured pulls, and remember that single-URL pricing means a 10,000-page extraction job is 10,000 scrape credits plus the per-page LLM token cost — forecast against /pricing before you start, not after the bill arrives.
Extraction is a managed, paid-plan feature
One thing to plan around: fastCRW's LLM-based JSON extraction is a managed feature available on paid plans. The FREE plan has no LLM features, so structured extraction is something you budget into a paid plan rather than turn on for free. The model is fully managed — you do not supply or operate any model yourself, you call /v1/scrape with formats: ["json"] and fastCRW runs the extraction. Naming the boundary up front is the point of this section — you should not discover it mid-integration.
Decision guide: schema vs prompt
Map your situation to a row and the choice usually falls out:
| Your situation | Use | Why |
|---|---|---|
| Known, stable fields fed into a DB or typed code | JSON schema | Validation and one predictable output shape |
| Repeated batch job across similar pages | JSON schema | Collapses output variance; fewer parsing bugs |
| Exploring what a page exposes | Prompt | No premature commitment to a shape |
| Heterogeneous pages, no shared template | Prompt | Tolerates variable attributes; structure later |
| Answer is genuinely prose (summaries, policies) | Prompt | The output isn't a record in the first place |
| One page, structured fields, ship today | JSON schema | Deserializes straight into your model |
A common and effective hybrid: prompt-extract a handful of representative pages to learn the real field spread, freeze that into a JSON schema, then run the schema-guided path at scale. You get exploratory flexibility up front and batch reliability in production — and you only pay the extraction's LLM token cost on the pages that truly need it. For pulling repeated records off list and catalog pages specifically, the list crawling for structured data guide pairs well with a schema; for getting clean input text in the first place, see LLM-ready markdown extraction.
Sources
- fastCRW repo and docs: github.com/us/crw · fastcrw.com
- JSON Schema specification: json-schema.org
Related: Structured extraction with a JSON schema · Extract endpoint deep dive · List crawling for structured data · LLM-ready markdown extraction