Mobile screenshot
A page that looks flawless on a laptop can hide a broken nav menu at phone width. This endpoint renders a URL at a phone, tablet or desktop screen width — the actual viewport size and pixel density that trigger the mobile layout, not a named device — so the layout you see is genuinely what a mobile visitor sees, not a resized browser window guessing at it.
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.
Desktop-shaped testing on a mobile-first web
Most traffic to most sites is mobile, yet a lot of visual QA still happens by shrinking a desktop browser window, which approximates layout but misses the details that actually break mobile experiences: how a sticky footer behaves at phone width, how a responsive image crops on a narrower mobile viewport, whether a modal covers content in a way that traps a user. Testing at the real screen widths catches what a resized window quietly hides.
How the rendering works
Send POST /web/screenshot-device with a URL and a target screen size — mobile, tablet or desktop, or a custom width — and the task renders the page at that viewport's dimensions and pixel density, so fonts, breakpoints and touch-target sizing all render as they do at that screen width. Like every task in the catalog it runs asynchronously, returning a task_id immediately and delivering the image via signed webhook or a signed link valid for 24 hours.
Why screen-width-accurate matters more each year
Responsive design was meant to solve this with fluid layouts, but breakpoints are still developer guesses about where content should reflow, and those guesses are frequently wrong for the long tail of screen sizes actually in use — a foldable, an older phone with a different aspect ratio, a tablet in split-screen. Rendering at a real target width — one of the three presets or a custom width you name — instead of eyeballing a shrunk desktop window is what turns 'it should work' into 'it does work.'
Common use inside a team
Mobile QA teams verifying a checkout flow at phone width before a release, marketing teams confirming an ad landing page renders cleanly at the screen widths campaign traffic actually uses, design teams reviewing how a redesign holds up at a tablet width in addition to a phone, and support teams reproducing a layout bug a customer reported at a specific screen size.
Automating screen-size checks
At a $0.040 base per request plus $0.001 per URL, running the same page through several screen sizes on every deploy stays affordable to schedule regularly. Failed captures are never billed — the task retries up to three times before returning a clear error — so it's safe to wire into a release pipeline that screenshots a staging URL across a matrix of screen sizes without manual review of every run.
What you can do with it
Pre-release mobile QA
A team screenshots the checkout flow at phone and tablet widths before shipping to catch layout breaks a desktop preview would miss.
Ad landing page checks
A performance marketing team verifies a landing page renders cleanly at the specific screen widths driving the most campaign clicks.
Design review on tablets
A design team reviews how a new layout holds up on a tablet viewport in addition to phone sizes before sign-off.
Bug reproduction
A support team captures a page exactly as it renders at a customer's reported screen width to confirm or rule out a width-specific layout bug.
FAQ
What screen sizes can the screenshot API render?
Three presets — a phone, a tablet and a desktop width, each with the matching viewport dimensions and pixel density — plus any custom width you specify.
How is this different from just resizing a browser window?
It renders at the actual viewport dimensions and pixel density of the target width — with the mobile viewport flag set, so responsive pages serve their mobile layout — rather than approximating it by shrinking a desktop browser.
Is there a free trial?
There's no free tier — free tiers get abused and slow everyone down. Access runs on a prepaid ForHosting KIT balance: top up from $10.00 (it never expires) and each request is charged at its published price, so a call with no balance returns HTTP 402. No subscription, no tokens, no invented credits, and a failed task is never charged.
What's the pricing?
A $0.040 base per request plus $0.001 per URL, published upfront with no hidden per-size surcharge.
Can I capture the same page at multiple screen sizes at once?
Yes, submit one async request per screen size; each is billed and processed independently, which suits a full size matrix per release.
How do I get the screenshot back?
Via signed webhook when the task finishes, or a signed link valid for 24 hours.
Does it handle responsive breakpoints correctly?
Yes — because it renders at the actual target viewport width, content reflows exactly as it does at that width in a real browser rather than at an approximated breakpoint.
What if a capture fails?
It retries automatically up to three times and is never charged on failure; a clear error is returned once retries are exhausted.
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-device \
-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-device", {
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-device",
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-device", 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-device", 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_device",
"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. |