Screenshot API or Playwright?

The short answer

Put the browser where its state belongs.

If the input is a public URL and the output is a PNG, JPEG, or PDF, a hosted screenshot API can remove browser installation, patching, queues, and capture diagnostics from your application. If the job depends on login state, private hosts, clicks, form input, arbitrary page code, or debugging the page itself, run Playwright in an environment you control.

Compare ownership, not syntax.

Both options ultimately drive Chromium. The material difference is which side owns the browser process and how much control crosses that boundary.

On a narrow screen, scroll the comparison table horizontally.

See the boundary in two requests.

The hosted version describes an artifact. The local version launches and controls a browser. Neither is universally better; each makes a different part of the system your responsibility.

Hosted screenshot API

curl --fail-with-body \
  -H "Authorization: Bearer $LATCHSHOT_API_KEY" \
  'https://latchshot.fly.dev/v1/screenshot?url=https%3A%2F%2Fexample.com&width=1440&height=900&format=png' \
  --output example.png

Local Playwright

import { chromium } from 'playwright';

const browser = await chromium.launch();
try {
  const page = await browser.newPage({
    viewport: { width: 1440, height: 900 },
  });
  await page.goto('https://example.com', {
    waitUntil: 'domcontentloaded',
  });
  await page.screenshot({ path: 'example.png' });
} finally {
  await browser.close();
}

In a production local path, add browser installation, an explicit timeout, bounded concurrency, job cancellation, process cleanup, egress policy, and diagnostics. In a hosted path, inspect the service's target restrictions, limits, retention policy, output contract, and failure behavior.

Keep Playwright when control is the product.

• Authenticated state: the page needs cookies, storage state, SSO, or a login sequence.
• Private network placement: the target is a preview deployment, internal host, loopback service, or non-public port.
• Multi-step interaction: the job clicks, types, uploads, downloads, intercepts requests, or evaluates page code.
• Test diagnostics: traces, video, DOM assertions, accessibility inspection, and step-level debugging matter more than the final image.
• Custom browser policy: extensions, proxies, certificates, executable flags, or a pinned system image are requirements.

Those are not edge cases a narrow screenshot API should pretend to support. They are reasons to keep the browser close to the application and its test environment.

Use a hosted endpoint when the artifact is the product.

• Stable input: each job starts from a public URL and bounded render options.
• Simple output: the caller needs an image or PDF, not a live page object.
• Variable workload: a shared render service can absorb browser startup and queue management outside the application process.
• Small operations surface: the team would rather integrate HTTP than package and patch browsers in every runtime.
• Explicit limits: the workflow benefits from fixed viewports, deadlines, output bounds, and predictable rejection of private targets.

Latchshot is one implementation of this narrower model. It accepts public pages on standard web ports, blocks private and special-use destinations, bounds render options and deadlines, returns capture diagnostics in headers, and counts only successful direct renders against quota.

Model the cost you actually own.

For local Playwright, estimate browser-runner compute, peak concurrency, image transfer and storage, failed-job retries, runtime maintenance, incident response, and the engineering time needed to keep the browser layer healthy. For a hosted API, estimate successful outputs, plan headroom, transfer and storage, integration maintenance, and the cost of provider limits that do not fit your job.

Latchshot's current plans are Free at 100 successful renders each UTC month, Launch at $19 for 2,500, Build at $49 for 12,000, and Scale at $149 for 50,000. Failed direct renders do not consume quota, and automatic overages are disabled. These prices are inputs to your comparison, not proof that outsourcing is cheaper.

Prove a narrow slice before moving it.

1. Separate public artifact jobs from authenticated, private, or interactive browser jobs.
2. Choose a representative public-page set, including slow, animated, and failure-prone targets.
3. Fix viewport, wait strategy, motion, timeout, and output format on both paths.
4. Compare the actual artifacts, latency distribution, failure reasons, and operating work.
5. Move only the public artifact slice that stays inside the hosted boundary. Keep the rest in Playwright.

The result can be a hybrid architecture: Playwright for browser workflows and a screenshot API for bounded public-page output. The provider migration checklist covers option mapping, representative tests, diagnostics, and rollback.