Screenshot API Comparison: Puppeteer vs Playwright vs CustomJS (2026)

Quick feature comparison

Interactive demo: build your screenshot request visually

The fastest way to avoid “it works locally but fails in CI” issues is to use a tool that makes browser actions explicit: wait conditions, cookie banner clicks, scrolling, and cropping.

Use the widget below to build a screenshot request (including interactions) and get ready-to-use API code.

The widget uses our Native API. For the full request/response schema and endpoint details, see Native API documentation.

Puppeteer: screenshot example

Puppeteer is a Node.js library that controls Chromium. It’s excellent when you already operate Node services and want full control, but you also inherit all responsibility: browser updates, concurrency limits, timeouts, CPU spikes, and flaky rendering.

Node.js (Puppeteer)

const puppeteer = require('puppeteer');

async function screenshotWithPuppeteer(url) {
  const browser = await puppeteer.launch({
    headless: 'new'
  });

  try {
    const page = await browser.newPage();

    await page.setViewport({ width: 1280, height: 720 });
    await page.goto(url, { waitUntil: 'networkidle2', timeout: 30000 });

    // Example: click cookie banner (update selector for your site)
    // await page.click('#accept-cookies');

    await page.waitForTimeout(500);

    await page.screenshot({ path: 'screenshot.png', fullPage: true });
  } finally {
    await browser.close();
  }
}

screenshotWithPuppeteer('https://example.com');

Operational note: in real systems you usually do not launch a new browser per request. You keep a browser pool or a worker queue. That’s where complexity starts.

Playwright: screenshot example

Playwright provides a robust API, great tooling, and multi-browser automation. If you must test and screenshot with browser parity (Chromium/Firefox/WebKit), Playwright is usually the strongest self-hosted option.

Node.js (Playwright)

const { chromium } = require('playwright');

async function screenshotWithPlaywright(url) {
  const browser = await chromium.launch();

  try {
    const page = await browser.newPage({ viewport: { width: 1280, height: 720 } });
    await page.goto(url, { waitUntil: 'networkidle', timeout: 30000 });

    // Example: wait for a selector to appear
    // await page.waitForSelector('main');

    await page.screenshot({ path: 'screenshot.png', fullPage: true });
  } finally {
    await browser.close();
  }
}

screenshotWithPlaywright('https://example.com');

CustomJS Screenshot API: screenshot example

With a managed API, you trade direct browser control for speed of integration and lower ops. You simply send a request with the URL and optional commands (click, type, wait, scroll, crop).

cURL

curl -X POST 'https://e.customjs.io/screenshot' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "input": {
      "url": "https://example.com",
      "commands": []
    }
  }' \
  > screenshot.png

Node.js

const axios = require('axios');
const fs = require('fs');

async function screenshotWithCustomJS(url) {
  const response = await axios.post(
    'https://e.customjs.io/screenshot',
    {
      input: {
        url,
        commands: []
      }
    },
    {
      headers: {
        'x-api-key': process.env.CUSTOMJS_API_KEY,
        'Content-Type': 'application/json'
      },
      responseType: 'arraybuffer'
    }
  );

  fs.writeFileSync('screenshot.png', response.data);
}

screenshotWithCustomJS('https://example.com');

To add interactions (cookie clicks, waits, scrolling) use the visual builder above and copy the generated command list.

Benchmarks: what matters (and what doesn’t)

Public benchmarks for screenshot generation are often misleading because latency depends heavily on:

• Target site complexity: JS-heavy SPA vs static HTML.
• Wait strategy: fixed wait vs network idle vs selector-based readiness.
• Concurrency: 1 screenshot vs 50 parallel requests.
• Rendering determinism: fonts, animations, ads, A/B tests, cookie banners.

In practice, the “winner” is usually the approach that gives you consistent results with minimal operational burden.

Costs and operational overhead

The biggest hidden cost of Puppeteer/Playwright isn’t the library—it’s everything around it:

• Queueing: preventing CPU/RAM spikes when many screenshots arrive at once.
• Browser updates: keeping headless Chrome/WebKit versions stable.
• Sandboxing: running browsers safely inside containers.
• Retries & timeouts: handling flaky pages without hanging workers.
• Monitoring: diagnosing why a single site started failing today.

If screenshot generation is a core competency for your business, self-hosting can be right. If it’s an enabling feature, a managed API usually wins.

Make.com and n8n: automation workflows

For many teams the screenshot itself is just a step inside an automation:

• Marketing: generate social previews and upload them to storage/CDN.
• QA: capture screenshots nightly and compare against baselines.
• Monitoring: screenshot competitor pages and notify on changes.
• Content: generate blog thumbnails on publish.

If you’re already working in Make.com or n8n, native modules dramatically reduce setup time compared to running Node workers and managing browser containers.

Decision guide: what should you pick?

Choose Puppeteer if…

• You only need Chromium and you already operate Node services.
• You need very custom behavior and want direct browser hooks.
• You can invest in infra and long-term maintenance.

Choose Playwright if…

• You need cross-browser coverage (Chromium/Firefox/WebKit).
• Your main use case is testing and automation with excellent tooling.
• You can still manage browser workers and scaling.

Choose CustomJS Screenshot API if…

• You want to ship screenshot generation quickly without operating browsers.
• You want a visual builder that outputs correct API code for interactions.
• You need Make.com and n8n modules for no-code workflows.
• You want predictable costs and fewer production failures due to infra.

FAQ

1. Which is faster: Puppeteer or Playwright?

In many real-world cases the difference is negligible compared to network latency and page complexity. Choose based on browser support, reliability, and operational fit.

2. Can I handle cookie banners and popups?

Yes. With self-hosted tools you write automation steps; with CustomJS you send commands (or use the visual builder to generate them).

3. What about full-page screenshots?

All approaches support it. Be careful with long pages and lazy loading: you typically need scroll/wait strategies.

4. Where can I find the full request schema?

See Native API documentation for details.

Conclusion

Puppeteer and Playwright are excellent tools when you want maximum control and can operate browser automation infrastructure.

If you want to ship a screenshot feature quickly—with low maintenance and easy automation via Make.com and n8n—a managed Screenshot API is usually the most pragmatic choice.

Start free with 600 screenshots per month