Render API — Browser-Rendered HTML for JavaScript-Heavy Sites

When you need a real browser

Most pages on the web render perfectly well with a simple HTTP request. For those, the regular crawl and scrape endpoints handle the work efficiently. The render endpoint is the path for the cases where simple does not work: single-page applications where content is loaded by JavaScript after the initial HTML response, sites that hydrate critical data client-side, dashboards that only become useful once their bundled JavaScript executes.

For those targets, you need a real browser, not a smarter HTTP client. The render endpoint provides one: a fully-featured browser engine, fingerprinted and configured to look like a normal user, executing the page and returning the post-JavaScript DOM in a single API call. You do not run a fleet, you do not manage Chrome instances, you do not write retry logic for crashed processes.

Render a single URL

curl -X POST https://api.crawlcrawl.com/v1/cloud/render \
  -H "Authorization: Bearer crk_..." \
  -d '{"url":"https://spa-app.example","return_format":"raw"}'

# returns
{ "url": "...", "status": 200, "content": "<!doctype html>...post-JS HTML...", "cost_usd": 0.001 }

Output formats

Default is "raw" — the full HTML after JavaScript executes. Pass return_format: "markdown" to get the cleaned-up markdown version directly, which is often what RAG pipelines need. Pass return_format: "html" for the raw post-JavaScript HTML without markdown conversion, useful when you want to do your own DOM parsing.

When to use Render vs Crawl

The regular crawl endpoint renders JavaScript automatically when it detects that a page requires it; you do not need to flag the crawler explicitly. Reach for the render endpoint specifically when you want a single page from a known JavaScript-heavy target and do not need the surrounding crawl graph. Common patterns include capturing a specific app screen, fetching a single dashboard for a screenshot, or running a one-off rendered fetch from inside a larger workflow.

For multi-page workloads of JavaScript-heavy targets, POST /v1/cloud/crawl is the better default — every page runs through the cloud path with JS rendering and anti-bot routing, orchestrated in one call.

What teams use it for

Three patterns explain most render usage.

The first is SPA scraping for RAG corpora that include modern web apps. Documentation sites built with frameworks like Docusaurus, Nextra, or custom React stacks often require rendering to extract content that exists only after JavaScript runs.

The second is screenshot generation. The same browser path can capture a rendered image of a page, which teams use for change-detection alerts, marketing asset generation, and visual regression testing.

The third is one-off fetches inside larger pipelines. When a workflow needs the rendered version of a single URL (and the rest of the workflow does not need browser rendering), the render endpoint is the cleanest entry point.

Pricing for render

Render requests cost more than direct-fetch scrapes because each one runs a full browser. The per-request cost is shown in the response so your accounting can audit exactly what was charged. For workloads where rendering is the rule rather than the exception, Studio or Agency tiers usually deliver the best per-credit economics. See full pricing →

Render.