Render a JavaScript page
Get the HTML of a page as a visitor's browser finishes it, after its scripts have run and the content has loaded, instead of the near-empty shell a plain download returns. Useful for search audits, content extraction and release checks. You pay per use, with no subscription.
Run it online
Run this on our servers with your account. Free tools run in your browser; this one bills your KIT balance per the price above.
Most scrapers fetch a URL and get a shell — a near-empty document waiting for a bundle to finish loading.
Why the page source is often almost empty
Open the source of many modern sites and you find little more than script tags. The interface is built inside the visitor's browser, so the text a person reads only exists after those scripts have run. Anyone who scrapes, indexes, tests or archives the raw download is working with a page that was never finished. This tool opens the address in a real browser without a window, runs the scripts, applies the styles and waits until the page has settled or until a condition you set is met. Then it hands back the HTML exactly as the page stands at that moment, including everything the scripts added.
What people do with the finished page
Search specialists compare what a crawler sees after the scripts run with the markup they intended, to catch content that only appears late. Others render a page first and then pass the result to an article extractor or a Markdown converter, because that content never shows up in the raw download. Quality teams check before a release that a redirect made by the page itself, a cookie banner or a test variant came out as planned. Keeping one render and comparing it with the next is also a simple way to notice a layout change.
The gap between source and DOM
View-source and the rendered page have grown apart. Frameworks that build the interface client-side ship a document that's mostly script tags; the content a person actually reads only exists after that script runs. Anyone trying to scrape, index, test or archive such a page against the raw HTML response is working with a page that was never finished.
What actually happens on a request
A headless browser instance opens the URL, executes scripts, applies stylesheets, and waits through network idle or a condition you specify, then serializes the live document object model back into HTML. What you get is not the server's response — it's the page as it exists after the browser has done its job, including content injected by client-side frameworks, hydration, and deferred fetches.
What you can do with it
SEO and rendering audits
Compare what search engines actually see against your intended markup by capturing the post-JavaScript DOM.
Feeding downstream extraction
Render a page first, then hand the result to the article extractor or the Markdown converter for content that never loads in raw HTML.
QA against production behavior
Verify a client-side redirect, a cookie banner, or an A/B test variant rendered the way it should before a release ships.
FAQ
Does it run JavaScript?
Yes — a real browser engine executes scripts, applies styles and waits for the page to settle before the DOM is captured.
Can I wait for a specific element before capturing?
Yes, you can target a selector or a load condition so slow-hydrating content is included rather than captured half-built.
Is there a free trial?
There's no free tier — free tiers get abused and slow everyone down. No subscription, no tokens, no invented credits, and a failed task is never charged.
What if the page fails to render?
The task retries up to three times automatically; a run that still fails returns a clear error and is never charged.
Can I render pages that require login?
You can pass cookies or headers needed to reach the authenticated view, as long as you're authorized to access that page.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/web/render \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"url":"https://example.com"}'const res = await fetch("https://api.kit.forhosting.com/web/render", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"url": "https://example.com"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/web/render",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"url": "https://example.com"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/web/render", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"url":"https://example.com"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"url":"https://example.com"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/web/render", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"url": "https://example.com"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "web.render",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Limits
timeout_sec | 30 |
max_crawl_pages | 25 |
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
422 | task_failed | The task failed after 3 retries. You are never charged for it. |
Technical notes
This rendered HTML API runs that bundle first: a real browser executes the page's JavaScript, waits for it to settle, and hands back the DOM exactly as a visitor's browser would build it.
Why this differs from a plain HTTP fetch
A basic HTTP request never runs a script; it just returns bytes. That's fine for a static blog and useless for a single-page application, a dashboard behind client-side routing, or any page that decides what to show based on cookies, viewport or an API call made after load. Rendering closes that gap without you standing up and maintaining a browser farm.
Where headless rendering came from
Headless browsers started as testing tools, built to drive real engines without a visible window so continuous integration could click through a UI unattended. Using that same machinery to capture a finished DOM for scraping and archiving is a natural extension — the browser was already doing the rendering work, it just needed an endpoint that asked for the result instead of a test outcome.
Fitting rendering into a pipeline
Rendered HTML becomes the input to whatever comes next: parse it, feed it into the article extractor, or diff it against yesterday's render to spot a layout change. Because the response is async with a task_id and a webhook, a rendering step slots into a queue-based pipeline the same way any other task does — no synchronous browser session to keep open on your end.
Integration use cases
Scraping single-page applications
Pull structured data out of a React or Vue dashboard that only populates its tables after an API call fires client-side.
Technical questions
How is this different from a screenshot?
A screenshot returns an image; this endpoint returns the rendered document as HTML text, so you can parse, diff or feed it to another tool.
How is it billed?
$0.040 per request plus $0.001 per URL, published on this page with no hidden per-second browser fees.
How do I get the result?
By signed webhook once rendering finishes, or a signed link valid for 24 hours if you'd rather fetch it yourself.