This is a tutorial to build a screenshot API yourself. If you want a managed screenshot API instead of building browser infrastructure, use ScreenshotOne.

In case you don’t want to read the tutorial, feel free to check out the complete result a screenshot API on GitHub.

In this tutorial, we will build a small screenshot API from scratch. It is not a full replacement for a production service like ScreenshotOne, but it shows the main moving parts: request validation, browser rendering, cookie banner handling, full-page screenshots, S3 uploads, Docker, and deployment options.

A few reasons behind this exercise:

I want to assess the modern landscape of technologies that enable screenshot rendering and rethink some architectural choices I made for ScreenshotOne.
I want to share a practical guide for developers who want to understand how screenshot APIs work under the hood or build their own internal service. If you prefer to buy instead of build, compare the best screenshot APIs.
I want to show how much more complex a screenshot API becomes once you move beyond a basic page.screenshot() call.

It still fascinates me that building a screenshot API is fun, even the second time.

Features

To keep this tutorial from turning into a book, we will implement four core features:

Full-page screenshots that trigger lazy-loaded images.
Blocking cookie banners.
Changing viewport parameters like dimensions and device scale factor.
Upload screenshots to any S3-compatible storage.

Of course, there are a hundred more features that screenshot APIs have, but these few will be enough for demonstration purposes.

API comes first

In a real product, customer needs and documentation should come first. For this tutorial, I will take a small subset of ScreenshotOne features and reimplement them right away by writing code.

Technologies

I decided to go with:

Hono—a simple and fast framework for processing HTTP requests.
OpenAPI specification—for documentation, SDK generation, validation (Hono has a decent middleware for that), and interoperability with modern AI and other systems.
TypeScript—I am lazy and static typing saves me from overthinking.
Node.js—it is bullet-proof, battle-tested, and will be with us for years to come. Also, most of the best libraries like Puppeteer and Playwright for working with headless browsers are written for Node.js. Playwright supports many other languages and is worth considering, too.
LocalStack for running AWS S3 storage locally for playing and testing purposes.

I also have a decent experience with these technologies and that matters a lot. If you are good with Python, consider going with it, Python also can render website screenshots.

API for rendering screenshots

Starting with Hono is as simple as:

1
npm create hono@latest

I chose the Node.js runtime.

Hono combined with Zod is a turbo rocket. Let’s define the request and response schemes in src/schema.ts:

1
import { z } from "@hono/zod-openapi";
2

3
export const ScreenshotOptionsSchema = z.object({
4
    url: z.string().url().openapi({
5
        description: "A website URL.",
6
        example: "https://example.com",
7
    }),
8
    block_cookie_banners: z.boolean().default(true).openapi({
9
        description: "Render clean screenshots.",
10
        example: false,
11
    }),
12
    viewport_width: z.coerce.number().int().min(1).default(1920).openapi({
13
        description: "Change the viewport width.",
14
        example: 1920,
15
    }),
16
    viewport_height: z.coerce.number().int().min(1).default(1080).openapi({
17
        description: "Change the viewport height.",
18
        example: 600,
19
    }),
20
    device_scale_factor: z.coerce.number().int().min(1).default(1).openapi({
21
        description: "Change the device scale factor.",
22
        example: 2,
23
    }),
24
    full_page: z.boolean().default(false).openapi({
25
        description: "Render the full page screenshot.",
26
        example: false,
27
    }),
28
});
29

30
export const ScreenshotResultSchema = z
31
    .object({
32
        screenshot_url: z.string().url(),
33
    })
34
    .openapi("Screenshot");

As you see, I added all the options that reflect the features we are going to build: changing viewport parameters, full-page screenshots, blocking cookie banners, and returning the URL of the rendered screenshot.

Now, see how easy it is to define a route, handle typed requests, and return typed responses:

1
import { OpenAPIHono } from "@hono/zod-openapi";
2
import { createRoute } from "@hono/zod-openapi";
3

4
import { ScreenshotOptionsSchema, ScreenshotResultSchema } from "./schema";
5

6
const app = new OpenAPIHono();
7

8
app.openapi(
9
    createRoute({
10
        method: "get",
11
        path: "/screenshot",
12
        request: {
13
            query: ScreenshotOptionsSchema,
14
        },
15
        responses: {
16
            200: {
17
                content: {
18
                    "application/json": {
19
                        schema: ScreenshotResultSchema,
20
                    },
21
                },
22
                description: "Rendered screenshot.",
23
            },
24
        },
25
    }),
26
    (c) => {
27
        const screenshotOptions = c.req.valid("query");
28
        console.log(screenshotOptions);
29
        // Output:
30
        // {
31
        //     "block_cookie_banners": true,
32
        //     "viewport_width": 1920,
33
        //     "viewport_height": 1080,
34
        //     "device_scale_factor": 1,
35
        //     "full_page": false
36
        // }
37

38
        const screenshotUrl = "https://example.com";
39

40
        return c.json({ screenshot_url: screenshotUrl });
41

42
        // For http://localhost:3000/screenshot, it returns:
43
        // {"screenshot_url":"https://example.com"}
44
    }
45
);
46

47
app.doc("/openapi.json", {
48
    openapi: "3.0.0",
49
    info: {
50
        version: "1.0.0",
51
        title: "The Screenshot API",
52
    },
53
});
54

55
export default app;

Then I just update the src/index.ts file:

1
import { serve } from "@hono/node-server";
2
import app from "./app";
3

4
const port = 3000;
5
console.log(`Server is running on port ${port}`);
6

7
serve({
8
    fetch: app.fetch,
9
    port,
10
});

And that’s it. The API is ready to handle screenshot rendering requests.

As a bonus, we get the OpenAPI specification automatically at the /openapi.json route:

1
{
2
    "openapi": "3.0.0",
3
    "info": {
4
        "version": "1.0.0",
5
        "title": "The Screenshot API"
6
    },
7
    "components": {
8
        "schemas": {
9
            "Screenshot": {
10
                "type": "object",
11
                "properties": {
12
                    "screenshot_url": {
13
                        "type": "string",
14
                        "format": "uri"
15
                    }
16
                },
17
                "required": ["screenshot_url"]
18
            }
19
        },
20
        "parameters": {}
21
    },
22
    "paths": {
23
        "/screenshot": {
24
            "get": {
25
                "parameters": [
26
                    {
27
                        "schema": {
28
                            "type": "string",
29
                            "format": "uri",
30
                            "description": "A website URL.",
31
                            "example": "https://example.com"
32
                        },
33
                        "required": true,
34
                        "name": "url",
35
                        "in": "query"
36
                    },
37
                    {
38
                        "schema": {
39
                            "type": "boolean",
40
                            "default": true,
41
                            "description": "Render clean screenshots.",
42
                            "example": false
43
                        },
44
                        "required": true,
45
                        "name": "block_cookie_banners",
46
                        "in": "query"
47
                    },
48
                    {
49
                        "schema": {
50
                            "type": "integer",
51
                            "minimum": 1,
52
                            "default": 1920,
53
                            "description": "Change the viewport width.",
54
                            "example": 1920
55
                        },
56
                        "required": true,
57
                        "name": "viewport_width",
58
                        "in": "query"
59
                    },
60
                    {
61
                        "schema": {
62
                            "type": "integer",
63
                            "minimum": 1,
64
                            "default": 1080,
65
                            "description": "Change the viewport height.",
66
                            "example": 600
67
                        },
68
                        "required": true,
69
                        "name": "viewport_height",
70
                        "in": "query"
71
                    },
72
                    {
73
                        "schema": {
74
                            "type": "integer",
75
                            "minimum": 1,
76
                            "default": 1,
77
                            "description": "Change the device scale factor.",
78
                            "example": 2
79
                        },
80
                        "required": true,
81
                        "name": "device_scale_factor",
82
                        "in": "query"
83
                    },
84
                    {
85
                        "schema": {
86
                            "type": "boolean",
87
                            "default": false,
88
                            "description": "Render the full page screenshot.",
89
                            "example": false
90
                        },
91
                        "required": true,
92
                        "name": "full_page",
93
                        "in": "query"
94
                    }
95
                ],
96
                "responses": {
97
                    "200": {
98
                        "description": "Render a Screenshot",
99
                        "content": {
100
                            "application/json": {
101
                                "schema": {
102
                                    "$ref": "#/components/schemas/Screenshot"
103
                                }
104
                            }
105
                        }
106
                    }
107
                }
108
            }
109
        }
110
    }
111
}

Asynchronous versus synchronous API

This tutorial uses a simple synchronous API method for rendering screenshots. If I were starting a production screenshot API today, I would seriously consider an asynchronous-first API from scratch.

It is much easier to scale and manage resources with asynchronous jobs. But it requires a lot of work upfront: queues, a database, status tracking, webhooks, retries, and more complicated customer integration.

For users, a synchronous API is much easier to start with. But you can still encourage asynchronous usage when it matters, for example by making asynchronous requests cheaper or charging fewer credits for them.

Unfortunately, building the asynchronous API is out of the scope of this tutorial.

Now, let’s proceed to the most fun part (at least for me)—rendering screenshots.

Rendering screenshots

One simple function to render screenshots

To make sure we are now focused on building only the core features, let’s introduce a simple function in src/screenshots.ts:

1
import { ScreenshotOptions } from "./schema";
2

3
export async function render(options: ScreenshotOptions): Promise<{ url: string }> {
4
    // return the URL of the screenshot
5

6
    return { url: "https://example.com" };
7
}

It requires new type introduced as in src/schema.ts:

1
export const ScreenshotOptionsSchema = z.object({
2
    url: z.string().url().openapi({
3
        description: "A website URL.",
4
        example: "https://example.com",
5
    }),
6
    // ...
7
});
8

9
export type ScreenshotOptions = z.infer<typeof ScreenshotOptionsSchema>;

And let’s use it in the route handler (src/app.ts):

1
// ...
2
import { render } from "./screenshots";
3

4
app.openapi(
5
    createRoute({
6
        // ...
7
    }),
8
    async (c) => {
9
        const screenshotOptions = c.req.valid("query");
10

11
        const result = await render(screenshotOptions);
12

13
        return c.json({ screenshot_url: result.url });
14
    }
15
);

Now, we can fully focus on implementing rendering.

Preferring Puppeteer to Playwright

Playwright seems to be a superior library for working with headless browsers than Puppeteer, but I will go with Puppeteer.

Playwright is focused more on automation testing, while Puppeteer is about browser automation. Puppeteer is still actively developed and has a much better ecosystem in terms of plugs you can use for screenshotting, like blocking ads, cookie banners, and much much more.

Long story short, These are libraries designed with different goals and they suit different needs. If you are interested read more about the differences and similarities between Puppeteer and Playwright.

And, frankly, I have plenty of experience with Puppeteer—it is a decent library that just does the job.

If you are curious, you can read more about how to take screenshots with Puppeteer.

Now, let’s install Puppeteer:

1
npm i puppeteer

And try to render our first screenshot.

The first screenshot

In the first simple implementation, we omit blocking banners and scrolling before rendering the full page and uploading it to any S3-compatible storage. But everything else is fairly easy to implement:

1
import { ScreenshotOptions } from "./schema";
2

3
import puppeteer from "puppeteer";
4

5
export async function render(options: ScreenshotOptions): Promise<{ url: string }> {
6
    const browser = await puppeteer.launch();
7

8
    const page = await browser.newPage();
9
    await page.setViewport({
10
        width: options.viewport_width,
11
        height: options.viewport_height,
12
        deviceScaleFactor: options.device_scale_factor,
13
    });
14

15
    await page.goto(options.url);
16

17
    const encodedScreenshot = await page.screenshot({
18
        type: "jpeg",
19
        encoding: "base64",
20
        fullPage: options.full_page,
21
    });
22

23
    await browser.close();
24

25
    return { url: `data:image/jpeg;base64,${encodedScreenshot}` };
26
}

I went with the JPEG format, since it is more performant and returned the image in the Base64 encoding for simplicity but in the data URL format.

If you request to render the example.com website as:

1
curl "http://localhost:3000/screenshot?url=https://example.com"

You will get a response as:

1
{ "screenshot_url": "data:image/jpeg;base64,/9j/4AAQSkZJRgABAQ..." }

You can copy and paste the URL into the browser and you will see the screenshot:

example.com

We won’t implement the complete solution to block cookies with Puppeteer, but we will one simple solution to demonstrate how it can be done—by using a plugin to block banners.

Let’s install and use the plugin first:

1
npm install @cliqz/adblocker-puppeteer cross-fetch

Integrating the plugin takes only a few lines of code:

1
import { ScreenshotOptions } from "./schema";
2

3
import puppeteer, { Page } from "puppeteer";
4
import { PuppeteerBlocker } from "@cliqz/adblocker-puppeteer";
5
import fetch from "cross-fetch";
6

7
let blocker: PuppeteerBlocker | null = null;
8
async function blockCookieBanners(page: Page) {
9
    if (!blocker) {
10
        blocker = await PuppeteerBlocker.fromLists(fetch, [
11
            // the list of the cookie banners to block from the https://easylist.to/ website
12
            "https://secure.fanboy.co.nz/fanboy-cookiemonster.txt",
13
        ]);
14
    }
15

16
    await blocker.enableBlockingInPage(page);
17
}
18

19
export async function render(options: ScreenshotOptions): Promise<{ url: string }> {
20
    const browser = await puppeteer.launch();
21

22
    const page = await browser.newPage();
23
    if (options.block_cookie_banners) {
24
        await blockCookieBanners(page);
25
    }
26

27
    await page.setViewport({
28
        width: options.viewport_width,
29
        height: options.viewport_height,
30
        deviceScaleFactor: options.device_scale_factor,
31
    });
32

33
    await page.goto(options.url);
34

35
    const encodedScreenshot = await page.screenshot({
36
        type: "jpeg",
37
        encoding: "base64",
38
        fullPage: options.full_page,
39
    });
40

41
    await browser.close();
42

43
    return { url: `data:image/jpeg;base64,${encodedScreenshot}` };
44
}

Now, let’s try and check if it blocks the cookie banners for StackOverflow. First without banners:

1
curl http://localhost:3000/screenshot?url=https://stackoverflow.com/&block_cookie_banners=false

And the result is:

StackOverflow with cookies banners

And now, without:

1
curl http://localhost:3000/screenshot?url=https://stackoverflow.com/&block_cookie_banners=true

And:

StackOverflow without cookies banners

But there are many corner cases where cookie banner blocking won’t work. In this case, you will need to block them by selectors and develop many other heuristics that search for “accept cookie” in buttons and similar.

It took me years to develop a sophisticated algorithm that blocks most cookie banners in ScreenshotOne.

Trigger lazy loading for full-page screenshots

Most websites don’t render images below the fold immediately. They use lazy loading to speed up the initial page load.

That causes problems when taking full-page screenshots. The fastest way to fix it is to scroll to the bottom of the page before taking the full-page screenshot.

For example, look at this Apple full-page screenshot without scrolling:

Before scrolling

And then we add scrolling:

1
// ...
2

3
async function scroll(page: Page) {
4
    return await page.evaluate(async () => {
5
        return await new Promise((resolve, reject) => {
6
            var i = setInterval(() => {
7
                window.scrollBy(0, window.innerHeight);
8
                if (
9
                    document.scrollingElement &&
10
                    document.scrollingElement.scrollTop + window.innerHeight >=
11
                        document.scrollingElement.scrollHeight
12
                ) {
13
                    window.scrollTo(0, 0);
14
                    clearInterval(i);
15
                    resolve(null);
16
                }
17
            }, 100);
18
        });
19
    });
20
}
21

22
//...
23

24
export async function render(options: ScreenshotOptions): Promise<{ url: string }> {
25
    // ...
26
    await page.goto(options.url);
27

28
    if (options.full_page) {
29
        await scroll(page);
30
    }
31

32
    const encodedScreenshot = await page.screenshot({
33
        type: "jpeg",
34
        encoding: "base64",
35
        fullPage: options.full_page,
36
    });
37

38
    // ...
39
}
40

41
//...

Now, look at the result:

After scrolling

All images are loaded and the full-page screenshot is rendered properly.

If you are curious, read more about how to take full-page screenshots with Puppeteer.

Uploading to S3 storage

Later you can use any S3 compatible storage because the code I write will still work, but for testing purposes on my local machine, I will use LocalStack:

1
python3 -m pip install localstack

And start it:

1
localstack start -d

Configure your AWS CLI (set access/secret keys to “test”):

1
aws configure --profile localstack

Create your bucket:

1
aws s3 mb s3://screenshots --endpoint-url http://localhost:4566 --profile localstack

Install the AWS SDK for JavaScript:

1
npm install @aws-sdk/client-s3 @aws-sdk/lib-storage

Now, let’s try to upload screenshots to the bucket:

1
import { CompleteMultipartUploadCommandOutput, S3Client, S3ClientConfig } from "@aws-sdk/client-s3";
2
import { Upload } from "@aws-sdk/lib-storage";
3

4
// ...
5

6
const cfg: S3ClientConfig = {
7
    region: process.env.S3_REGION ?? "us-west-2",
8
    maxAttempts: 5,
9
    retryMode: "standard",
10
    credentials: {
11
        accessKeyId: process.env.ACCESS_KEY_ID ?? "test",
12
        secretAccessKey: process.env.SECRET_ACCESS_KEY ?? "test",
13
    },
14
    endpoint: process.env.S3_ENDPOINT ?? "http://localhost:4566",
15
    forcePathStyle: true,
16
};
17

18
const client = new S3Client(cfg);
19

20
export async function uploadToS3Storage(screenshot: Buffer, key: string, contentType: string) {
21
    const bucket = "screenshots";
22

23
    const upload = new Upload({
24
        client: client,
25
        params: {
26
            Bucket: bucket,
27
            Key: key,
28
            Body: screenshot,
29
            ContentType: contentType,
30
            StorageClass: "STANDARD",
31
        },
32
        queueSize: 4,
33
        partSize: 1024 * 1024 * 5,
34
        leavePartsOnError: false,
35
    });
36

37
    const result: CompleteMultipartUploadCommandOutput = await upload.done();
38
    if (!result.Location) {
39
        throw new Error("Failed to upload");
40
    }
41

42
    return result.Location;
43
}
44

45
export async function render(options: ScreenshotOptions): Promise<{ url: string }> {
46
    // ...
47

48
    const location = await uploadToS3Storage(screenshot, "example.jpeg", "image/jpeg");
49

50
    return { url: location };
51
}

The result URL will be just http://localhost/screenshots/example.jpeg which is not correct, since it doesn’t contain the port.

As an exercise, you can fix that and also add a parameter to specify the resulting filename or compute it automatically from the website URL.

Containerize

Since we went with Puppeteer, it already provides instructions on how to build a Docker and run a headless browser with Node.js:

1
FROM node:20@sha256:cb7cd40ba6483f37f791e1aace576df449fc5f75332c19ff59e2c6064797160e
2

3
# Install latest chrome dev package and fonts
4
# to support major charsets (Chinese, Japanese, Arabic, Hebrew, Thai and a few others)
5
# Note: this installs the necessary libs to make the bundled version of Chrome that Puppeteer
6
# installs, work.
7
RUN apt-get update \
8
    && apt-get install -y wget gnupg \
9
    && wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | gpg --dearmor -o /usr/share/keyrings/googlechrome-linux-keyring.gpg \
10
    && sh -c 'echo "deb [arch=amd64 signed-by=/usr/share/keyrings/googlechrome-linux-keyring.gpg] https://dl-ssl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google.list' \
11
    && apt-get update \
12
    && apt-get install -y google-chrome-stable fonts-ipafont-gothic fonts-wqy-zenhei fonts-thai-tlwg fonts-khmeros fonts-kacst fonts-freefont-ttf libxss1 dbus dbus-x11 \
13
    --no-install-recommends \
14
    && service dbus start \
15
    && rm -rf /var/lib/apt/lists/* \
16
    && groupadd -r apiuser && useradd -rm -g apiuser -G audio,video apiuser
17

18
USER apiuser
19

20
WORKDIR /home/apiuser/app
21

22
COPY --chown=apiuser:apiuser package*json tsconfig.json  ./
23
COPY --chown=apiuser:apiuser src ./src
24

25
RUN npm ci && \
26
    npm run build && \
27
    npm prune --production
28

29
CMD ["node", "/home/apiuser/app/build/index.js"]

I also changed the TypeScript configuration (tsconfig.json):

1
{
2
    "compilerOptions": {
3
        "target": "ESNext",
4
        "strict": true,
5
        "module": "commonjs",
6
        "esModuleInterop": true,
7
        "types": ["node"],
8
        "outDir": "./build"
9
    },
10
    "exclude": ["node_modules"],
11
    "include": ["**/*.ts"]
12
}

Then I installed the TypeScript compiler:

1
npm i typescript --save-dev

I updated the scripts section in package.json:

1
{
2
    // ...
3
    "scripts": {
4
        "dev": "tsx watch src/index.ts",
5
        "build": "tsc"
6
    }
7
    // ...
8
}

And tuned a bit the configuration of the browser when launching:

1
const browser = await puppeteer.launch({
2
    args: [
3
        "--disable-setuid-sandbox",
4
        "--disable-dev-shm-usage",
5
        "--disable-accelerated-2d-canvas",
6
        "--no-first-run",
7
        "--single-process",
8
        "--disable-gpu",
9
    ],
10
    headless: true,
11
});

Now, let’s check that it works:

1
docker build -t learnshot .

And:

1
docker run -p 3000:3000 learnshot -e S3_ENDPOINT=... -e ACCESS_KEY_ID=... # and other S3-related environment variables

Using the local version of S3 will not work with Docker out of the box. You can either use a real S3 bucket or make localhost available inside Docker’s internal network.

It should work and respond as before.

Containerizing the application will allow us to host the API anywhere from serverless to VPS.

Deploy

For ScreenshotOne, I use a combination of bare metal servers with GPU, managed Kubernetes, and Google Cloud Run.

But there are one thousand more ways to deploy the screenshot API we have just built.

Kubernetes

It has a lot of advantages and I enjoy using it. Some of them are:

Scalability: It can automatically adjust resources based on demand.
Flexibility: It supports a wide range of environments, including on-premises, cloud, and hybrid clouds.
Rich and strong ecosystem: Offers a rich set of features and integrations thanks to its widespread adoption and active community.

But it also has two serious downsides:

Complexity: Setting up and managing a Kubernetes cluster can be complex, requiring significant expertise. Start with the managed option first. Even that will be complex most of the time.
Cost: While Kubernetes itself is open-source and free, running it, especially in cloud environments, can incur substantial costs based on the resources utilized. But I consider it a much cheaper alternative to Google Cloud Run and AWS Fargate at scale.

I wouldn’t start with Kubernetes today in most cases, but at later stages of a project, it can be irreplaceable and valuable.

AWS Fargate, Google Cloud Run, or Azure Container

I use Google Cloud Run and still believe it is one of the easiest and fastest options to start with. Typical advantages of such platforms are:

Serverless-style deployment: these environments remove the need to manage servers or clusters, simplifying deployment and management.
Scalability: Automatically scales computing capacity in response to application demands.
Integration: Seamlessly integrates with other Google Cloud, AWS, or Azure services, offering a comprehensive ecosystem for deployment, monitoring, and security.

The main downside for me is cost, it is expensive for long-running and resource-intensive applications (like headless browsers!) due to its pricing model.

VPS

Virtual Private Servers (VPS) provide another viable option for deploying our screenshot API. And that’s how I actually started, but it quickly gets out of control, once you have a considerable load, you need to always adjust and check the capacity of your servers.

The main upside is cost-effectiveness, but managing VPS is still painful which can be solved with PaaS like Heroku, Render, or similar.

Or you can use Kamal and GitHub Actions to automate at least deployments, but you will still have infrastructure issues to solve.

PaaS

Heroku and similar providers can simplify the server management issues, but you can use something much better that can combine both cost efficiency and ease of deployment—Coolify:

It can automate your CI/CD process, generate SSL certificates, provision servers, and has powerful server automation and monitoring.

If I were starting today again, I would seriously consider using Coolify and provisioning and managing my own servers with it.

What is next?

You might want to continue further development, but there is so much more about screenshot APIs. Let’s grasp quickly what could be done next.

Caching

Except for specific categories of sites like news, most sites don’t change frequently and you can enable caching for rendered screenshots.

For example, ScreenshotOne does that by utilizing Cloudflare Workers, Cache, and R2 storage. It is also provided as a free option for all ScreenshotOne customers since it almost costs nothing.

Proxies and retries

Requests to websites often fail. Networks fail, pages time out, and sometimes your screenshot request is blocked.

Combine using proxies and retry requests if the site does not respond.

Advanced image processing

You can add a feature to specify the image size, and format and convert it on the fly.

It is not requested frequently but is used by some of my customers to store already processed images and serve them from the cache.

There are a lot more features to build but I listed the most frequently asked features.

Improve error handling

Make sure to handle all the possible errors from Puppeteer and when uploading screenshots to the S3 storage.

Also, for every function you can call, always set timeouts and make sure to handle them properly if the function call exceeds the configured timeout.

Automate testing

Screenshotting websites have so many pitfalls that I would recommend to write automation tests if it is possible.

You often fix one thing, and two others break. Writing automated tests can help prevent that and keep screenshot quality stable.

The end

I know that screenshot APIs are boring, that’s what most developers tell me. But I hope I shared a little bit of my passion for this domain with you and you learned a thing or two.

Thanks for reading!

How to Build a Screenshot API

Written by

Updated on

Tags

Features

API comes first

Technologies

API for rendering screenshots

Asynchronous versus synchronous API

Rendering screenshots

One simple function to render screenshots

Preferring Puppeteer to Playwright

The first screenshot

Trigger lazy loading for full-page screenshots

Uploading to S3 storage

Containerize

Deploy

Kubernetes

AWS Fargate, Google Cloud Run, or Azure Container

VPS

PaaS

What is next?

Caching

Proxies and retries

Advanced image processing

Improve error handling

Automate testing

The end

Read more Engineering

How to take website screenshots with JavaScript or TypeScript (Node.js)

Cloudflare Workers as an API gateway

How to add custom scripts to a page in Puppeteer

Automate website screenshots

Integrations

Use Cases

Screenshot Tools

Customers

How to Build a Screenshot API

Written by

Updated on

Tags

Features

API comes first

Technologies

API for rendering screenshots

Asynchronous versus synchronous API

Rendering screenshots

One simple function to render screenshots

Preferring Puppeteer to Playwright

The first screenshot

Block cookie banners

Trigger lazy loading for full-page screenshots

Uploading to S3 storage

Containerize

Deploy

Kubernetes

AWS Fargate, Google Cloud Run, or Azure Container

VPS

PaaS

What is next?

Caching

Proxies and retries

Advanced image processing

Improve error handling

Automate testing

The end

Read more Engineering

How to take website screenshots with JavaScript or TypeScript (Node.js)

Cloudflare Workers as an API gateway

How to add custom scripts to a page in Puppeteer

Automate website screenshots