Screenshot a website
Turn any web address into a PNG image of what a visitor sees on screen, captured by a real browser once the page and its scripts have finished loading. Keep proof of how a page looked, or watch it on a schedule. 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.
A live webpage is a moving target — it changes with every deploy, every A/B test, every ad rotation — so proving what it looked like at a given moment means capturing it, not describing it.
Why a page has to be captured, not described
A live web page is a moving target. It changes with every release, every layout test and every ad rotation, so proving what it looked like at a given moment means taking a picture of it. Automated checks can confirm that an element exists, but they cannot tell you it renders three pixels off, that a font failed to load or that an ad slot is showing a competitor's banner. This tool opens the address in a real browser, waits for the page to render, including content added by its scripts, and saves the visible area as an image.
Where routine screenshots help
Product teams capture a competitor's pricing page every week to follow changes without anyone visiting it by hand. Quality teams take screenshots of key pages after every test release, so a reviewer can compare them with the previous version before launch. Content sites capture any link a user shares to show a visual preview next to it, and brand monitoring services photograph client websites at regular intervals to confirm they display correctly rather than an error page. Each finished image waits behind a secure link for 24 hours.
How it plugs into monitoring and QA
Design teams capture a competitor's pricing page weekly to track changes without visiting it by hand. QA pipelines screenshot every staging deploy to catch visual regressions before they reach production. Uptime and brand-safety tools capture a page periodically to confirm it's rendering correctly and not showing an error page to real visitors.
What you can do with it
Competitor pricing monitoring
A product team captures a competitor's pricing page on a weekly schedule to track changes without anyone visiting the site manually.
Visual regression testing
A QA pipeline screenshots key pages after every staging deploy so a reviewer can compare against the previous version before release.
Link preview generation
A content platform captures a screenshot of any URL a user shares to generate a visual preview alongside the link.
Brand and uptime monitoring
A brand safety tool periodically screenshots a set of client websites to confirm pages render correctly and aren't showing errors to visitors.
FAQ
Does it capture JavaScript-heavy pages correctly?
Yes, a real browser renders the page before the image is captured, so dynamic content and JavaScript-driven layouts appear as they would to a visitor.
Are the captured pages or images stored afterward?
No, captured images are deleted after the retention window and are never used to train any model.
What can a screenshot catch that automated tests miss?
A test can confirm that an element exists, but not that it sits three pixels off, that a font failed to load or that an ad slot shows a competitor's banner. A screenshot shows the page exactly as a browser drew it.
Can I capture the same page on a regular schedule?
Yes. You can capture a page on demand or on a schedule, for instance a competitor's pricing page every week, so changes are recorded without anyone opening the site by hand.
Does it capture the whole page or only what fits on the screen?
It captures the visible area, the part a visitor sees on screen when the page opens, and saves it as a PNG image. The finished image waits behind a secure link that stays valid for 24 hours.
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/screenshot \
-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/screenshot", {
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/screenshot",
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/screenshot", 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/screenshot", 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.screenshot",
"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 endpoint renders any URL and returns an image, on demand or on a schedule, without a browser open on a desk somewhere.
Why a screenshot is still the ground truth
Automated tests can assert that an element exists; they can't tell you it renders three pixels off, that a font failed to load, or that an ad slot is showing a competitor's banner. A screenshot settles that kind of question the way nothing else does, because it captures the page exactly as a browser rendered it, not as the code claims it should look. web.screenshot exists to make that capture a routine API call instead of a manual chore someone does when something looks wrong.
What happens between the request and the image
POST /web/screenshot with the target URL, receive a task_id immediately, and get the rendered image back by webhook or a signed link valid for 24 hours once it's captured. Behind the call, a real browser loads the page, waits for it to render, and takes the shot — so the result reflects JavaScript-heavy pages and dynamic content, not just the raw HTML a simple fetch would return.
From server-side rendering to headless browsers
Capturing what a page looks like used to require a person with a browser open, and later, brittle scripts driving a real browser window on a desktop that someone had to keep running. Headless browser automation changed that by letting a full rendering engine run without a visible window, which is what makes it possible to screenshot thousands of pages from a server with no monitor attached — the same capability this endpoint exposes over a simple API call.
What to expect across different kinds of pages
Static content and standard layouts capture cleanly and predictably. Pages with animations, cookie banners, or content that loads progressively as the user scrolls can render differently depending on timing, which is the same challenge any automated browser tool faces; check the endpoint reference for options that affect wait behavior and viewport size if a particular page needs tuning.
How it plugs into monitoring and QA
Billed per request plus per URL and run asynchronously, monitoring one page or ten thousand is the same integration at a different scale.
Technical questions
How do I take a screenshot of a webpage with the API?
Send the URL to POST /web/screenshot, store the returned task_id, and get the image by webhook or a signed link valid for 24 hours.
Is the screenshot API free?
No, there's no free tier or trial. It costs $0.040 per request plus $0.001 per URL, and a failed capture is never charged.
Can I capture the full page, not just the visible area?
Check the endpoint reference for capture options such as full-page height and viewport size, since these affect how much of a long page ends up in the image.
Can I schedule recurring screenshots for monitoring?
The endpoint itself is called on demand; recurring monitoring is built by triggering the API on your own schedule, such as a daily or weekly job.
Can I capture many URLs in bulk?
Yes, submit each URL as its own async task and collect the resulting images by webhook as they finish, which is how large batches are typically handled.
What image formats are supported?
Check the endpoint reference for the current list of supported output formats and resolution options.