How to Screenshot a Website in TypeScript

Short answer: call https://screenshotrender.com/api/v1/screenshot?apiKey=YOUR_API_KEY&url=https://github.com&fullPage=true with the built-in fetch function, type the JSON response with a five-field interface, and TypeScript knows the shape of every field at compile time. No browser binary, no @types/puppeteer, no spawn.

By the end you'll know the Puppeteer route and the single fetch call route, which one ships with less to maintain, and how to type the response so TypeScript catches a mistyped field name before it reaches production.

How do you screenshot a website in TypeScript?

The shortest path is one fetch call to the ScreenshotRender API. No browser to install, no lifecycle to manage. The complete request is one URL: https://screenshotrender.com/api/v1/screenshot?apiKey=YOUR_API_KEY&url=https://github.com&fullPage=true. Fire it with await fetch(endpoint), parse the JSON, and read the hosted image URL from data.screenshot. Your TypeScript project stays browser-free.

The API key is the sr--prefixed key from the ScreenshotRender dashboard. The url parameter is the page you want to capture. fullPage=true screenshots the entire scrollable document instead of the default 1280 by 720 viewport. Those three parameters cover the common case; the rest of this post adds wait times, typed responses, and error handling on top.

If you would rather keep the rendering on your own server, the Puppeteer route below runs a real Chromium locally. Both approaches are here so you can pick by how much infrastructure you want to own.

How do you screenshot a website in TypeScript with Puppeteer?

You screenshot a website in TypeScript with Puppeteer by launching a Browser, opening a Page, navigating to the target URL, and calling page.screenshot(). Puppeteer ships its own TypeScript declarations, so there is no separate @types/puppeteer package to install and the compiler is satisfied from the first import.

The call chain in prose: const browser = await puppeteer.launch(), then const page = await browser.newPage(), then await page.goto("https://github.com"), then await page.screenshot({ path: "github.png", fullPage: true }), then await browser.close(). The Puppeteer screenshot API accepts type, quality, clip, and a full set of capture options when you need fine-grained control.

The cost shows up at deploy time. Puppeteer downloads a full Chromium binary on first install. Every server and CI runner needs that binary, the right shared libraries, and the fonts the page expects. A container image that worked locally will silently fail in a minimal Alpine build when system libraries are missing. Cloudflare-protected pages send a challenge interstitial to a vanilla headless Chrome, so you can capture the wrong page without any obvious error. Our Puppeteer screenshot guide goes deeper on those failure modes if you go that route.

How do you type the screenshot API response in TypeScript?

Define a ScreenshotResponse interface that mirrors the JSON shape, then cast the parsed response once. After that, TypeScript knows every field throughout your project.

The interface matches the API response exactly. The top level has a success boolean. Inside data you have screenshot as a string (the hosted image URL), width and height as number | null (null when fullPage=true), and title, description, and favicon as string | null pulled from the target page's metadata. The TypeScript handbook on object types covers the interface syntax if you are new to it.

With that interface in place, a reusable helper is a few lines: accept a url: string parameter, build the endpoint string, call fetch, cast the JSON result to ScreenshotResponse, check result.success, and return result.data.screenshot. TypeScript catches a typo like result.data.screensho at compile time rather than at runtime in production.

The fetch global is available without any extra package in Node.js 18 and above. On older versions, install node-fetch and the typings resolve the same way.

How do you capture a full page or add a wait time in TypeScript?

Add fullPage=true to capture the entire scrollable document instead of the default 1280 by 720 viewport. Add wait=2 to give JavaScript-heavy pages extra time to settle before the capture fires.

The full request with both parameters: https://screenshotrender.com/api/v1/screenshot?apiKey=YOUR_API_KEY&url=https://github.com&fullPage=true&wait=2. The wait value is in seconds. Two seconds is the API's built-in default, which handles most React and Vue apps that swap content after network idle. Raise it for slower apps, or pass a timeout value in seconds to cap how long a stalled page can hold the request open. That last one is useful in a Next.js Route Handler where you do not want an open connection to hang.

Cookie banners, GDPR consent popups, ad overlays, and chat widgets are removed automatically before every capture, on every plan including the free one. The screenshot you get back is the rendered page, not a consent layer stacked over it.

When does TypeScript website screenshot capture fail?

Most failures are access problems, not TypeScript or API problems.

• Internal URLs. A hosted screenshot service cannot reach http://localhost, http://10.0.0.5, or any URL inside a private VPC. For internal pages you need a headless browser running inside the same network, or a tunnel that exposes the page publicly.
• Login-gated pages. The public API takes a URL, not a session cookie. If the target requires a sign-in, generate a public share link on the source app first, or drive a local browser through the authentication flow with Puppeteer or Playwright.
• Cloudflare and bot protection. A vanilla headless Chromium gets served a challenge page on bot-protected sites, so the capture returns the wrong content without an obvious error. ScreenshotRender ships Stealth Mode on the Hobby plan and above for exactly this case. The free plan handles ordinary public pages. The full picture is in our guide to screenshotting Cloudflare-protected websites.
• Rate limits. The free plan caps at 40 requests per minute and the Hobby plan at 60. In a TypeScript loop processing many URLs, add a delay between iterations or upgrade to a plan with a higher per-minute cap to avoid 429 errors.

For the vast majority of cases (public marketing pages, documentation sites, competitor snapshots, OG image generation), the typed fetch call is the right answer. The full tier breakdown is on the pricing page.

Common questions about TypeScript screenshots

Can I use this in a Next.js API route or server action?

Yes. The fetch call works identically in a Next.js API route, a server action, or a Route Handler. Point the call at screenshotrender.com/api/v1/screenshot, read data.screenshot from the JSON response, and return or cache the URL. No browser binary runs on Vercel or any other serverless host, because ScreenshotRender handles the browser on its end.

How do I handle errors from the screenshot API in TypeScript?

Check the success field first. If it is false, the response carries an error string describing what went wrong. Wrap the fetch in a try/catch for network-level failures, and check res.ok before calling res.json() to catch non-2xx HTTP responses. ScreenshotRender only deducts a credit after a successful render, so a failed request costs nothing toward your monthly quota.

Does this work with Deno or Bun?

Yes. Both Deno and Bun ship a global fetch, so the same typed call works without modification. Define the ScreenshotResponse interface, call fetch with the endpoint URL, cast the result, and read data.screenshot. No Node.js-specific APIs are involved, so the pattern is runtime-agnostic.

How do I save the screenshot image to disk in TypeScript?

Fetch the image URL returned at data.screenshot with a second fetch call, get the ArrayBuffer from the response using the Fetch API, and write it with fs.writeFile in Node.js or Deno.writeFile in Deno. The URL is a standard hosted image, so any HTTP client that can download a URL can save it to disk.

The honest takeaway: match the method to your constraints. If you need full browser control, Puppeteer with TypeScript types works, at the cost of a Chromium binary on every host. If you want a typed, clean result in a serverless function, a Node.js script, or a Next.js route, the single fetch call is the least to maintain and the fastest to ship.