Crawler / Page / Render

Render JavaScript pages into clean Markdown.

Use the render path when the page is built by JavaScript. AnyCrawler opens the URL through a browser, waits for client-loaded content, extracts the rendered DOM, and returns Markdown, metadata, links, and usage fields through the same crawl/page endpoint.

Browser path

Crawl content that only appears after JavaScript runs

Render is for pages where a plain HTTP response is not enough: single-page apps, pricing tables loaded after hydration, client-side routes, and documentation portals that build the useful body in the browser. You keep one API shape while switching the extraction path to a browser.

JavaScript execution Client-rendered DOM Browser wait controls Markdown normalized

curl

Render a page

curl -X POST "https://api.anycrawler.com/v1/crawl/page" \
  -H "Authorization: Bearer $ANYCRAWLER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/app/pricing",
    "method": "render",
    "browser_wait_until": "networkidle2",
    "accept_cache": true,
    "include_metadata": true,
    "include_links": true,
    "markdown_variant": "readability"
  }'

Set method to render when JavaScript or browser behavior is required before extraction.

How it works

Open, wait, extract rendered content

The gateway handles request validation, account checks, cache lookup, browser routing, response filtering, and credit settlement.

1

Submit the target URL

Send a POST request with url and method=render. Optional flags control browser wait, metadata, links, media, Markdown variant, and cache reads.

2

AnyCrawler opens a browser path

The gateway validates your API key, checks credits and browser concurrency, applies cache policy, and routes the page through the render worker.

3

JavaScript output becomes Markdown

Client-loaded content is extracted from the rendered DOM and normalized into Markdown, token counts, metadata, and links when requested.

4

You get usage evidence

The response includes status, final URL, credits_used, cache_timestamp, and request headers for production debugging.

Use cases

Where render beats a plain HTML fetch

Use the render page API when the answer is not in the initial response and the browser state changes what your agent can trust.

Use

JavaScript pricing pages

Capture pricing tables, plan cards, and comparison blocks that appear only after a framework hydrates the page.

Use

Client-side documentation portals

Render docs sites that depend on client routing, search indexes, or JavaScript-generated navigation before extracting Markdown.

Use

Agent verification before action

Let agents read the rendered page state before quoting terms, comparing product claims, or routing a workflow to a human.

Response

Rendered crawl output

{
  "ok": true,
  "requested_url": "https://example.com/app/pricing",
  "canonical_url": "https://example.com/pricing",
  "final_url": "https://example.com/app/pricing",
  "status_code": 200,
  "cache_timestamp": 0,
  "credits_used": 12,
  "results": {
    "title": "Example Pricing",
    "description": "Plans loaded by a JavaScript app",
    "markdown": "# Example Pricing\n\nFree plan\nBuilder plan\nGrowth plan...",
    "markdown_tokens": 736,
    "metadata": {
      "description": "Plans loaded by a JavaScript app"
    },
    "links": [
      {
        "text": "Compare plans",
        "href": "https://example.com/pricing/compare"
      }
    ]
  }
}

metadata, links, and media appear only when requested; each included group adds its published modifier credits.

What you get

Rendered DOM in a smaller agent-ready shape

The render response is built for JavaScript-heavy sites. Use Markdown for model context, URLs for provenance, status fields for debugging, and optional extraction fields when the rendered page should seed deeper crawl workflows.

  • JavaScript-loaded page content converted to Markdown
  • Final URL and status code for traceability
  • Optional metadata, links, and media from the rendered page
  • Credit, cache, and request fields for cost control

Request fields

Use browser controls only when the page needs them

The stable public contract focuses on the fields below. Undocumented passthrough fields are not part of new integrations.

Field Type Required Notes
url string Yes The public page URL to open in the browser render path.
method "render" Recommended Selects the browser path for JavaScript-loaded and client-rendered pages.
browser_wait_until "domcontentloaded", "load", "networkidle0", "networkidle2", or null No Controls when the browser considers the page ready before extraction.
accept_cache boolean No Allows a valid cached response to return at the cache-hit rate.
include_metadata boolean No Adds page metadata to results.metadata when available after rendering.
include_links boolean No Adds rendered-page links to results.links for follow-up crawl planning.
include_media boolean No Adds extracted images and media references to results.media.
markdown_variant "markdown" or "readability" No Controls the extraction path. Both variants return results.markdown.
user_agent string or null No Optional paid-plan override for the outbound user agent.

Response fields

Fields your integration can rely on

AnyCrawler strips internal timing and debug fields before returning the public response.

Field Meaning
ok Whether the gateway completed the crawl successfully.
requested_url The URL submitted in the request.
canonical_url Canonical URL discovered from the rendered page when present.
final_url The final URL after redirects and browser navigation.
status_code HTTP status code returned by the target page.
cache_timestamp Cache marker for reused responses. Zero means a fresh upstream result.
credits_used Credits settled for the request.
results.markdown Clean Markdown body extracted after browser rendering.
results.markdown_tokens Estimated token count for the Markdown payload.
results.metadata Optional rendered page metadata when include_metadata is true.
results.links Optional links visible after render when include_links is true.
results.media Optional extracted media when include_media is true.

TypeScript

Use the SDK shape

import { AnyCrawlerClient } from "@anycrawler/sdk";

const client = new AnyCrawlerClient({
  apiKey: process.env.ANYCRAWLER_API_KEY!,
});

const { data, meta } = await client.crawlPage({
  url: "https://example.com/app/pricing",
  method: "render",
  browser_wait_until: "networkidle2",
  accept_cache: true,
  include_metadata: true,
});

console.log(data.results?.markdown);
console.log(meta.requestId);

The SDK request type includes the stable public crawl fields.

Render vs fetch

Use render for JavaScript. Use fetch for cheap speed.

Render is the browser path for pages that need JavaScript, client-side routing, or dynamic UI content before extraction. If the target page already exposes useful HTML, switch the same endpoint to method=fetch for a faster 2-credit request.

Mode Best for Base cost
render JavaScript apps, client-side routing, browser-dependent pages 10 credits
fetch Docs, articles, reference pages, static HTML, cached content checks 2 credits
cache hit Repeated reads when accept_cache=true and a valid cached result exists 1 credit

Errors

Status codes are explicit enough for production handling

Use response status plus error_code and request headers to route retries, credit issues, authentication problems, and browser concurrency limits.

200 Page rendered and normalized.
400 Invalid JSON or unsupported request field value.
401 Missing, invalid, or revoked API key.
402 Account does not have enough credits.
403 Account inactive or paid-plan-only field requested.
429 Rate limit or browser concurrency limit reached.
502 Upstream browser connection failed.
504 Target page or browser worker timed out.

Headers

Track every render request

Successful and error responses include gateway metadata headers such as x-request-id, x-credits-reserved, and x-credits-used. Store them when you need support or cost audits.

Pricing

Start free, scale with explicit browser limits

Render requests use 10 credits before cache hits and share the same plan browser concurrency limits shown on the main AnyCrawler pricing model.

Free

$0/mo

For early validation with one-time credits, 30 fetch requests per minute, and 1 browser concurrency slot.

  • 10,000 one-time credits
  • $0 / cr
  • Fetch 30 req / min
  • Browser 1 concurrent

Agent Lite

$5/mo

For low-frequency AI agents and occasional automations that need 15,000 monthly credits.

  • 15,000 credits / mo
  • $0.000333 / cr
  • Fetch 60 req / min
  • Browser 2 concurrent
  • Low-frequency AI agent usage
  • Persistent top-ups available separately

Builder

$20/mo

For builders shipping serious crawler workflows with higher limits and better unit economics.

  • 80,000 credits / mo
  • $0.000250 / cr
  • Fetch 180 req / min
  • Browser 3 concurrent
  • Best upgrade after repeated Agent Lite usage

Growth

$80/mo

For teams scaling production scraping with better unit economics.

  • 960,000 credits / mo
  • $0.0000833 / cr
  • Fetch 480 req / min
  • Browser 8 concurrent

Scale

$200/mo

For high-volume pipelines with pricing aligned to large ongoing usage.

  • 3,000,000 credits / mo
  • $0.0000667 / cr
  • Fetch 1,200 req / min
  • Browser 20 concurrent

FAQ

Common render API questions

Short answers for teams deciding when JavaScript rendering is worth the browser path.

When should I use render instead of fetch?

Use render when the useful content is created after JavaScript runs, hidden behind client-side routing, or dependent on browser behavior. Use fetch when the content is already present in the initial HTML and speed or cost matters most.

Does render wait for JavaScript-loaded content?

Yes. Render opens the page through the browser path and supports browser_wait_until values such as load, networkidle0, and networkidle2 before extracting Markdown.

Does render still return Markdown?

Yes. The render path returns results.markdown and results.markdown_tokens after the browser has loaded the page, so AI agents can consume clean text instead of raw DOM output.

Why does render cost more than fetch?

Render uses browser execution and plan-specific browser concurrency, which is heavier than a lightweight HTTP fetch. Use it for JavaScript pages, and use fetch for cheaper, faster HTML-first pages.