Skip to main content

When to use render_js

Set "render_js": true when the content you need is injected by JavaScript after the initial HTML loads. Common cases:
  • Single-page applications (React, Vue, Angular)
  • Infinite-scroll feeds where items appear after JS executes
  • Pages behind login redirects that trigger on load
  • Dynamic price or inventory widgets
If the page’s HTML already contains the content (SSR pages, Wikipedia, static sites), skip render_js — it saves credits and latency.

How it works

When render_js is true, the API navigates to the URL in a headless Chromium browser, waits for the network to settle, and captures the fully-rendered DOM. Each request gets a fresh, isolated browser context (cookies, storage, and cache are not shared with other requests) — the underlying browser process itself is kept warm and reused across requests for performance, not relaunched from scratch each time. Rendering typically adds 2–5 seconds of latency.

Setting a timeout

Use timeout_ms to cap how long the browser waits. The default is 10,000 ms (10 s) for inline requests. Async requests allow up to 300,000 ms (5 min).
If the timeout is exceeded, the API returns a timeout error code.

Device emulation

Emulate mobile or tablet viewports to reach responsive content:
Supported values: "desktop" (default), "mobile", "tablet".

Sessions

Reuse a browser session across multiple fetches — cookies, local storage, and auth state are preserved:
See Identity & Sessions for the full session lifecycle.

Cost

JS-rendered fetches cost 5 credits vs 1 for static fetches.