Use a browser automation library to launch a browser without a visible window, navigate to a page, interact with controls, verify the result, and save evidence such as a screenshot or PDF. For a new general-purpose workflow where cross-browser coverage matters, Playwright is a practical starting point: its documentation covers Chromium, Firefox, and WebKit, as well as branded Chrome and Edge channels. Puppeteer is also a fit when its Chrome and Firefox automation model and JavaScript API suit your project. Choose based on the engines, runtime, and workflow you need—not an assumed speed advantage.
What headless browser automation does
A headless browser is controlled by code without showing a browser window. It still loads and renders pages, maintains browser state, and interacts with page controls; the lack of a visible window does not remove the need to handle asynchronous loading, changing interfaces, or failures.
A typical automation job follows this sequence:
- Install an automation library and compatible browser binaries.
- Launch the browser in the required mode.
- Create an isolated context and open a page.
- Navigate, locate controls, take actions, and verify visible results.
- Save evidence or output, then close the browser even if something fails.
Browser automation is not permission to bypass a site’s bot protections or disregard its terms. Confirm that you are authorized to automate the target and expect some sites to block or limit automated access.
Choose Playwright or Puppeteer
| Decision point | Playwright | Puppeteer |
|---|---|---|
| Documented browser coverage | Chromium, Firefox, WebKit, and branded Chrome and Edge channels. Playwright browser documentation | Chrome and Firefox automation using CDP and WebDriver BiDi. Chrome for Developers overview |
| Workflow features described by the official docs | Locators, auto-waiting, Playwright Test, cross-browser configuration, screenshots, and PDFs. Migration guidance and Page API | Page interaction, screenshots, PDFs, performance analysis, and network interception. Chrome for Developers overview |
| Headless behavior | Supports a Chromium headless shell and a newer Chromium headless option; behavior can differ from Chrome and Edge channels. Playwright browser documentation | The official overview describes headless, headful, and shell modes. Chrome for Developers overview |
| How to choose | Choose when its engine coverage, language support, locator model, and test workflow fit the job. | Choose when its API and browser model fit your existing code and target browsers. |
These capabilities do not establish that one library is universally faster or more reliable; there is no comparable benchmark here. Also distinguish browser engines from branded browser channels: a Chromium build is not automatically identical to Chrome or Edge. For visual or browser-specific behavior, run the same mode and channel you intend to use in deployment.
#1 Best Overall
Install Playwright and its browser binaries
The example below uses Node.js and Playwright. In a new project, install the package and its supported browser binaries:
npm init -y
npm install --save-dev playwright
npx playwright install chromiumUse npx playwright install instead of the last command if the workflow needs all supported browser builds. Playwright versions are tied to specific browser binaries; after updating the package, rerun the browser installation command. On a Linux environment missing system libraries, install the required dependencies with:
npx playwright install-deps chromiumFor a combined browser and dependency install, Playwright also documents npx playwright install --with-deps chromium. Browser downloads use Microsoft’s CDN by default. In restricted build environments, check whether downloads are permitted and provide the required browser build and system dependencies through your normal deployment process. See Playwright’s browser installation guide for the current commands and platform details.
Build a repeatable browser task
This example opens a page, clicks a link found by its accessible role and name, checks that the destination is visible, and saves a screenshot. Replace the example URL and link name with a site and action you are authorized to automate. The assertion uses Playwright Test, so install it alongside Playwright:
Recommended Free Tools
npm install --save-dev @playwright/testSave the following as task.spec.js:
const { test, expect } = require('@playwright/test');
test('open a page, follow a link, and save evidence', async ({ page }) => {
await page.goto('https://example.com');
await page.getByRole('link', { name: 'More information' }).click();
await expect(page).toHaveURL(/iana.org/);
await expect(page.locator('body')).toBeVisible();
await page.screenshot({ path: 'result.png', fullPage: true });
});Run it headlessly with:
npx playwright test task.spec.jsPlaywright Test runs in headless mode by default. If you need to see the browser while developing, run npx playwright test task.spec.js --headed. The test runner manages browser and page lifecycles for this example. In a standalone script, close the browser in a finally block so an error does not leave the process holding browser resources:
const { chromium } = require('playwright');
(async () => {
const browser = await chromium.launch({ headless: true });
try {
const context = await browser.newContext();
const page = await context.newPage();
await page.goto('https://example.com');
await page.screenshot({ path: 'result.png', fullPage: true });
} finally {
await browser.close();
}
})();The standalone example demonstrates browser launch, context creation, navigation, and screenshot capture; add the relevant locator action and assertion for your task. See the Playwright Page API for page operations and output options.
Make interactions wait for page state
Prefer locators and assertions tied to what the page shows over fixed delays such as “sleep for three seconds.” Playwright locators wait and retry around actions, while web-first assertions check conditions over time. That reduces races without guessing how long a page takes to load. It does not mean that every task can omit explicit waits: when an application exposes a particular state or navigation boundary, wait for that state rather than an arbitrary duration. See Playwright’s migration guidance.
Use locators that describe the control
When possible, identify a control by its accessible role and name, as in getByRole('button', { name: 'Save' }). If the page has no useful accessible name, choose a stable attribute or locator that matches the actual interface. A locator matching multiple elements can fail rather than silently clicking an arbitrary one; treat that as a useful signal to make the target unambiguous.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesHandle overlays and dialogs deliberately
If a predictable modal or banner blocks an action, make handling it part of the workflow. Playwright supports locator handlers for unexpected overlays, but a handler can change keyboard focus and mouse position. Keep the action that follows self-contained: re-identify the intended control and do not assume the pointer or focus remains where it was.
Handle file selection
For a file upload, respond to the file chooser and provide the intended file with its setFiles method. This is more explicit than expecting a headless browser to open a visible operating-system file picker. Keep the upload path under your control and verify the resulting page state.
Choose the right browser mode and evidence
“Headless” does not identify one identical implementation. Playwright distinguishes its Chromium headless shell from a newer Chromium headless option, and documents differences involving Chrome and Edge. Chrome for Developers quotes its documentation about the newer Chrome mode: “New Headless on the other hand is the real Chrome browser, and is thus more authentic, reliable, and offers more features.” The statement refers to that newer Chrome headless mode, not every headless implementation. Check Playwright’s browser guide for mode and channel distinctions.
Choose evidence according to the job:
- Assertions confirm that the intended page state or action occurred.
- Screenshots preserve visual output for review or debugging; Playwright supports full-page capture.
- PDFs are useful when the task needs a document artifact rather than an image.
- Traces and logs can help diagnose failures in longer-running workflows; preserve failure artifacts as part of your own job design.
Do not rely on a screenshot alone as proof that a workflow succeeded. Pair it with an assertion that checks the result the task actually requires.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Troubleshoot common failures
- A locator finds nothing or matches several elements: the page may have changed, or the locator may not uniquely identify the control. Inspect the current page state, use a stable role/name or attribute, and assert the relevant state before interacting. A strict locator failure is preferable to clicking an unintended match.
- The click races the page: replace a guessed sleep with a locator action and a web-first assertion. If the application has a distinct state or navigation transition, wait for that specific condition.
- A modal blocks a click: handle the expected overlay in the flow or use a locator handler for an unexpected one. After a handler runs, reacquire the control because focus and pointer state may have changed.
- The browser will not launch in CI: install the browser binary that matches the Playwright package and add the system dependencies. Check whether the environment permits the documented browser download.
- CI looks different from a developer machine: record the Playwright and browser versions, then align the deployed browser mode and channel with the one used for development. Headless shell, newer Chromium headless, Chrome, and Edge can differ.
- A screenshot looks unexpected: confirm which browser build and channel produced it, then capture again in the mode required by the task. Do not assume a generic Chromium build exactly reproduces branded Chrome or Edge.
Performance, reliability, and operating cost
There is no supported basis here for a speed ranking between Playwright and Puppeteer. For a repeatable job, avoid unnecessary browser launches, keep the browser and package versions aligned, isolate task state in a browser context, and close resources after completion. Those are implementation practices, not a measured performance guarantee.
Make failures observable: report the page URL, operation, browser/package version, and error; preserve a screenshot or other useful artifact when appropriate. Treat timeouts, failed navigation, and blocked access as outcomes to diagnose, not as reasons to assume the task succeeded. The documentation describes the libraries’ capabilities, not guaranteed success on every third-party site.
Or skip the browser setup
If the task is to get a screenshot or PDF rather than interact with a site’s controls, ScreenshotNeo provides a website screenshot API and MCP server. One GET request can return an image or PDF; the API also supports full-page capture and many browser-rendering options. Use the documented parameters and response behavior in the ScreenshotNeo API documentation.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com -o shot.webpIt accepts cookie/consent banners and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers identify the page verdict and billing status. Its MCP server exposes take_screenshot, get_page_info, and capture_pdf for AI agents and MCP clients. The Free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 shots.
Sign up free for 1,000 screenshots a month with no card.
Sources and version notes
Browser support, installation commands, and headless behavior can change with library and browser releases. Check the official documentation for the version you install: Playwright Browsers, Playwright Page API, Chrome for Developers: Puppeteer, and Playwright migration guidance.
Frequently Asked Questions
Can I automate any website with a headless browser?
No. A site’s access controls, terms, or bot defenses may restrict automation; get authorization and do not treat automation as a way to bypass those controls.
Is headless always faster than headful?
The cited documentation does not establish a general speed advantage. Choose the mode based on the behavior and fidelity your task requires.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
