ScreenshotNeo
Sign in Get a free key

BlogAI agents

How to Choose a Browser with Playwright MCP

Choose Chrome, Firefox, WebKit or Edge with Playwright MCP, configure profiles and headless mode, and avoid compatibility traps.

By the ScreenshotNeo team1 October 20268 min read

Direct answer: use Chrome or Chromium for general-purpose Playwright MCP automation, Firefox when Firefox-engine behavior is your compatibility target, WebKit when Safari-like behavior matters, and Microsoft Edge when Edge is the deployment standard. Set the choice with --browser (or equivalent configuration), then decide whether you need headed or headless mode, a persistent or isolated profile, or a connection to an existing Chromium browser over CDP.

Playwright MCP supports the browser values chrome, firefox, webkit, and msedge. The MCP server uses Playwright-managed browser builds for Firefox and WebKit; it does not directly automate branded Firefox or Safari. For the closest Safari-oriented result, run WebKit on macOS, especially for video or codec-sensitive applications. See the Playwright MCP guide and Playwright browser documentation.

1. Pick the browser that matches your compatibility target

Browser value Choose it when Important detail
chrome You need broad, ordinary web automation or Chromium behavior. Use the bundled Chromium engine, or connect to branded Chrome through CDP when required.
firefox Firefox users or Firefox-engine differences are part of acceptance testing. Playwright uses its patched Firefox build; branded Firefox is not the supported direct target.
webkit Safari-like behavior is the target. WebKit is not branded Safari. Run it on macOS for the closest Safari experience; codecs and other platform features vary.
msedge Your users, enterprise policy, or deployment standard is Microsoft Edge. Edge is a supported branded Chromium channel and can also be reached through CDP.

Chrome and Chromium

Start with chrome for most MCP tasks: navigation, form completion, scraping, visual checks, and application workflows that target Chromium. If you only need a reproducible Playwright engine, use its bundled Chromium. If the workflow depends on a user’s installed Chrome, an enterprise extension, or an existing signed-in session, connect to that browser over CDP instead of assuming the bundled binary is identical.

Firefox

Select Firefox when Firefox engine behavior is the thing you need to validate. Differences in layout, event handling, permissions, and standards implementation can expose bugs hidden in Chromium. Playwright’s Firefox target relies on patches, so use the Playwright-provided build rather than trying to point MCP at a normal branded Firefox installation.

WebKit

Use WebKit for Safari-oriented coverage. Playwright WebKit is derived from WebKit sources and is not Safari itself, so treat results as Safari-like rather than proof of behavior on every Apple device. Operating-system differences matter; macOS is the preferred environment for the closest Safari comparison, and media codecs can remain environment-dependent.

Microsoft Edge

Choose msedge when Edge is the browser your production users run or your organization standardizes on. Because Edge is Chromium-based, most page behavior resembles Chrome, but policies, installed extensions, channel version, and enterprise configuration can still affect a workflow.

2. Configure the browser in Playwright MCP

Add the browser argument to your MCP client configuration. This example selects Firefox:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest", "--browser=firefox"]
    }
  }
}

Replace firefox with chrome, webkit, or msedge. The same setting can be supplied through a Playwright MCP config file or the PLAYWRIGHT_MCP_BROWSER environment variable. Keep the value explicit in team configuration so an agent does not silently run against a different engine on another machine.

Headed versus headless execution

MCP runs headed by default, which lets you watch the browser while an agent works. Add --headless for CI, containers, remote workers, or any environment without a display:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest", "--browser=chrome", "--headless"]
    }
  }
}

Use headed mode while diagnosing selectors, authentication, consent dialogs, and navigation. Switch to headless after the workflow is stable and your runtime provides the required browser dependencies.

Persistent and isolated profiles

A persistent profile keeps browser state such as cookies and login data between runs. That is useful for a development workflow that repeatedly uses the same account. For clean, repeatable jobs or parallel agents, pass --isolated so each run starts with a fresh session:

npx @playwright/mcp@latest --browser=chrome --isolated

Do not share one writable profile between concurrent jobs. Use isolation for tests that must not inherit a prior login, consent choice, cache entry, or extension state.

3. Connect MCP to an existing Chrome or Edge session

If the required session is already open, connect through a Chromium-family CDP endpoint. This is useful when a human has completed multi-factor authentication, when a profile contains required extensions, or when an enterprise-managed browser must remain the source of truth.

Supported channel names include chrome, chrome-beta, chrome-dev, chrome-canary, msedge, msedge-beta, msedge-dev, and msedge-canary. The exact launch and endpoint details depend on how your browser is started; keep the endpoint private and reachable from the MCP process.

npx @playwright/mcp@latest --browser=chrome

When your MCP client or deployment exposes a CDP endpoint option, point that option at the running Chromium-family browser. Verify that the endpoint is available before starting the agent, and expect browser-version or policy differences when the existing installation updates.

4. A practical selection workflow

  1. Write the compatibility requirement. Name the browser engine or branded browser your users depend on.
  2. Start with the matching engine. Use chrome for general work, firefox for Firefox coverage, webkit for Safari-oriented checks, and msedge for Edge deployments.
  3. Choose the session model. Use a persistent profile for a continuing signed-in workflow, --isolated for clean runs, or CDP for an existing Chromium-family session.
  4. Choose execution mode. Keep the default headed mode while debugging; use --headless in automation environments.
  5. Run the same acceptance steps on every target you promise. Record operating system, browser channel, profile mode, and headless setting with the result.

5. Cross-browser edge cases

  • Safari claims: WebKit coverage is a strong signal for Safari-like behavior, but it is not a branded Safari run. Confirm device-specific issues on the Apple platforms you support.
  • Video and codecs: playback can differ by operating system and browser build. Treat a WebKit result as environment-dependent, especially for codec-sensitive pages.
  • Authentication: a persistent profile may contain the right cookies while an isolated profile will not. Make login setup an explicit step.
  • Extensions and policies: an existing Chrome or Edge session can include extensions or enterprise policies that the bundled browser lacks. Use CDP when those are part of the requirement.
  • Parallel agents: separate profiles and temporary directories to prevent cookie, cache, and lock-file collisions.
  • Headless differences: rendering, permissions, downloads, and available display features can differ from headed runs. Reproduce a failure in the same mode used in production.

6. Troubleshooting Playwright MCP browser selection

Symptom Likely cause Fix
MCP starts in the wrong browser The browser argument is missing, misspelled, or overridden by environment configuration. Set one explicit --browser=chrome|firefox|webkit|msedge value and check PLAYWRIGHT_MCP_BROWSER.
Branded Firefox will not launch Playwright Firefox depends on patches and does not support the normal branded binary as a direct target. Use the Playwright-managed firefox build.
WebKit differs from Safari WebKit is not Safari, and operating-system capabilities vary. Run WebKit on macOS for the closest comparison, then validate device-specific behavior separately.
The agent is not logged in You started an isolated or new profile. Use a persistent profile, complete login in the run, or connect to an existing authenticated browser through CDP.
Headless startup fails in CI The runner lacks browser dependencies or a display configuration. Install the Playwright browser dependencies for the runner and pass --headless; reproduce locally in the same mode.
CDP connection cannot be reached The endpoint is not listening, is bound to another interface, or is blocked by the runtime. Start the Chromium-family browser with a reachable debugging endpoint, verify connectivity from the MCP process, and keep the endpoint protected.
Two jobs interfere with one another They share a persistent profile or browser process. Use --isolated or a separate profile per job; avoid concurrent writes to one profile.

7. Performance, reliability, and cost considerations

Browser choice is primarily a compatibility decision. Reliability improves when the engine, operating system, browser channel, profile mode, and headed/headless setting are fixed and documented. Headless mode generally fits unattended workers; headed mode makes failures easier to inspect. Persistent profiles reduce repeated login work but increase state leakage risk. Isolated profiles improve repeatability and parallel execution.

For media-heavy or platform-sensitive pages, test on the operating system that matches your users. For broad coverage, run a small matrix rather than assuming one engine represents all browsers. Keep screenshots, console output, and the selected configuration together so a failure can be reproduced.

8. Or skip the browser setup

If your goal is a clean screenshot rather than browser-engine control, ScreenshotNeo provides a one-request website screenshot API and MCP server. It accepts consent banners before capture and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each cleanup step can be turned off. Only clean shots are billed: bot checks, CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and the response reports the verdict in X-Page-Verdict and X-Billed headers.

See the ScreenshotNeo API documentation for all options, including full-page and element capture, device presets, dark mode, custom CSS and JavaScript, waits, request blocking, cookies and headers, geolocation, PDFs, caching, signed links, async jobs, bulk capture, and usage reporting.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp
import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo also has an MCP server with take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000. Create a free ScreenshotNeo account.

9. FAQ

Can Playwright MCP control Safari?

It controls Playwright WebKit, which provides Safari-like coverage. It does not directly automate branded Safari. Use macOS WebKit runs for the closest comparison and validate device-specific behavior where needed.

Which browser should I select first?

Select chrome unless your acceptance requirement names Firefox, Safari-like WebKit, or Edge specifically.

Does --browser=chrome always use my installed Chrome?

It selects the Chrome channel for MCP. If you need an already-running branded session, use a supported Chromium-family channel or CDP connection and document that environment.

Should CI use headless mode?

Usually yes, provided the runner has the required browser dependencies. Debug locally in headed mode, then reproduce failures in the exact headless configuration used by CI.

When should I use an isolated profile?

Use --isolated for clean tests, parallel jobs, and workflows that must not inherit cookies or cache state.

Keep reading