How to Test Websites in Chromium-Based Microsoft Edge

To test a website in Chromium-based Microsoft Edge, start with Edge DevTools to inspect the page and reproduce a problem, then automate repeatable user journeys with Playwright or WebDriver. Use viewport and network emulation for quick diagnosis, and test on the actual device or operating system when the issue depends on real hardware or browser behavior.

This guide covers manual checks, responsive and network testing, Playwright setup, WebDriver setup, environment coverage, and common failures.

1. Start with the page in Edge

Open the site in the Edge version, account state, and viewport relevant to the issue. You can open DevTools in any of these ways:

Right-click a page element and choose Inspect.
Press F12.
Press Ctrl + Shift + I on Windows or Linux, or Command + Option + I on macOS.

In Elements, inspect the DOM and try temporary style changes. In Console, look for JavaScript errors and examine runtime behavior. DevTools also lets you inspect the resources used to construct the page. Treat edits made there as diagnostic: they do not change the deployed site. See Microsoft’s DevTools overview.

2. Check responsive layouts and network behavior

Open Device Emulation in DevTools and choose a mobile viewport or enter the dimensions relevant to the issue.
Exercise the layout: open menus, submit forms, scroll, and check content near the edges of the viewport.
Use network emulation to reproduce constrained conditions, then inspect network requests for failed or slow resources.
Reload after changing conditions if the page only makes the relevant requests during startup.

Emulation is useful for finding responsive layout problems and diagnosing likely network causes. It does not prove behavior on every real device. If the bug depends on an operating system, input method, physical device, or specific browser version, reproduce it on that target before considering it fixed.

3. Diagnose behavior and quality issues

Use DevTools findings to investigate the cause rather than treating a passing check as a certification:

JavaScript and rendering: inspect Console errors and use the debugger and breakpoints to follow code paths.
Network: identify failed requests, unexpected responses, and resources that take a long time to arrive.
Accessibility: investigate reported issues and manually verify the relevant keyboard and assistive-technology flows.
Performance: use available diagnostics to locate expensive rendering or resource work, then repeat measurements under consistent conditions.
Compatibility and security: treat findings as leads to verify against the affected feature and deployment configuration.

A tool finding is evidence to investigate. A clean report alone does not establish comprehensive accessibility, security, performance, or cross-browser correctness. Microsoft’s DevTools documentation describes its inspection and diagnostic capabilities.

4. Automate Edge journeys with Playwright

Playwright can drive Microsoft Edge because Edge is based on Chromium. Its Edge channel names are msedge, msedge-beta, msedge-dev, and msedge-canary. Select the channel according to whether you need to check the stable release or a preview channel. Playwright runs headless by default; use headed mode when you want to watch the browser. See Microsoft’s Playwright guide for Edge for current setup details.

Install and configure

In a Node.js project, install the test package and Edge browser support:

npm init -y
npm install --save-dev @playwright/test
npx playwright install msedge

Create playwright.config.js:

import { defineConfig } from '@playwright/test';

export default defineConfig({
  testDir: './tests',
  use: {
    channel: 'msedge',
    baseURL: 'http://127.0.0.1:3000',
  },
});

Create tests/home.spec.js with a real user journey appropriate to your site:

import { test, expect } from '@playwright/test';

test('home page navigation works in Edge', async ({ page }) => {
  await page.goto('/');
  await expect(page).toHaveTitle(/Example/);
  await page.getByRole('link', { name: 'Contact' }).click();
  await expect(page).toHaveURL(/contact/);
});

Replace the title and link with elements that exist on your application. Run headless, or open the browser to inspect the flow:

npx playwright test
npx playwright test --headed

To check another installed Edge release channel, set channel to msedge-beta, msedge-dev, or msedge-canary. Keep the rest of the test stable so a channel change isolates browser-version differences. Playwright can also target other browser engines; Edge channel testing answers a different question from cross-engine coverage.

5. Automate Edge with WebDriver

WebDriver is a good fit when your project already uses that standard and framework ecosystem or needs its session and interaction model. Microsoft’s overview describes WebDriver as simulating user interactions and supporting browser information, windows, tabs, pages, and multiple sessions. For Chromium-based Edge, use Selenium 4; Selenium 3 is no longer supported. See Microsoft’s Edge WebDriver guide.

The setup has three parts: Edge, Microsoft Edge WebDriver, and a WebDriver framework. The first three components of the driver version must match the installed Edge version. Since browser and driver versions change, check the installed browser version and obtain the corresponding current driver before running automation.

Example in Python with Selenium 4, assuming the matching Edge WebDriver is available on PATH:

from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

options = webdriver.EdgeOptions()
driver = webdriver.Edge(options=options)
try:
    driver.get('http://127.0.0.1:3000')
    link = WebDriverWait(driver, 10).until(
        EC.element_to_be_clickable((By.LINK_TEXT, 'Contact'))
    )
    link.click()
    WebDriverWait(driver, 10).until(EC.url_contains('contact'))
    print(driver.current_url)
finally:
    driver.quit()

Change the local URL and link text for your application. Explicit waits make the test wait for the condition it needs instead of relying on a fixed sleep.

6. Choose the right level of browser coverage

Need	Start with	Why
Explore a bug or inspect a page	Edge DevTools	Built into the browser; no separate runner is needed.
Repeat a known user journey	Playwright or WebDriver	Automates the same flow and can run from a command line or CI.
Use a WebDriver-based framework or session workflow	WebDriver with Selenium 4	Fits the existing standard and interaction model.
Check browser engines beyond Edge	A multi-browser automation setup	One local Edge result cannot establish behavior in other engines.
Cover a wider set of real browsers and environments	A hosted testing service, if needed	Evaluate browser and OS coverage, staging access, automation, debugging, privacy, CI fit, and budget.

BrowserStack describes manual cross-browser testing and browser automation on real browsers. Whether a hosted platform fits depends on the environments and workflow your project needs; consult its current service details and terms. Local testing is enough for many projects, while broader coverage is useful when target users span materially different browsers, operating systems, or devices.

Microsoft also describes the DevTools Protocol, Playwright, Puppeteer, and WebDriver as related but distinct automation choices. Choose based on whether you are exploring interactively, scripting journeys, or managing browser sessions. See Microsoft’s testing and automation overview.

7. Or skip the browser setup

If you need a screenshot artifact while investigating a page, ScreenshotNeo is a website screenshot API and MCP server for developers. A GET request takes a URL and returns a PNG, JPEG, WebP, or PDF. This does not replace interactive Edge testing, but it can avoid setting up a browser for captures.

See the ScreenshotNeo API documentation. Example request:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Cookie banners, popups, and chat widgets are removed before the shot. Bot checks, blank pages, and failed loads are never billed; response headers say which page verdict occurred and whether it was billed. Its MCP server lets AI agents use take_screenshot, get_page_info, and capture_pdf. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. Sign up for 1,000 free screenshots a month, with no card.

8. Troubleshooting

Symptom	Likely cause	Fix
DevTools does not open with a shortcut	The shortcut differs by operating system, keyboard, or browser configuration.	Right-click the page and choose Inspect, or use the platform shortcut listed above.
A layout looks correct in emulation but fails on a phone	The issue depends on actual hardware, OS behavior, input, or browser version.	Reproduce on the real target device and test the affected interaction there.
Playwright cannot find Edge	Edge is not installed or the selected channel is unavailable.	Run `npx playwright install msedge` and confirm the configured channel matches the installed release.
Playwright test passes locally but fails in CI	The CI image, browser channel, network, or application startup differs from local setup.	Make the browser channel and app startup explicit, then inspect the failing trace/log and network conditions.
WebDriver reports a session creation or version error	Edge and Edge WebDriver versions do not match in their first three components, or an unsupported Selenium version is used.	Install a matching driver and use Selenium 4.
A test flakes because an element is missing	The test acts before the page reaches the required state, or its selector is unstable.	Wait for a specific visible, enabled, or navigated condition; use a selector tied to accessible role or stable application markup.
A check reports a problem but the page seems fine	Diagnostics can flag a condition that needs context or further investigation.	Reproduce the user impact, inspect the underlying code/resource, and verify the actual acceptance criteria.

9. Performance, reliability, and cost considerations

Keep a fast local feedback loop: use DevTools while exploring, and automate only journeys that need repeatable regression coverage.
Control test conditions: pin the intended Edge channel, make app startup predictable, and avoid fixed sleeps where condition-based waits are available.
Separate diagnostic emulation from release confidence: repeat device-sensitive bugs on the real target and test other engines when users rely on them.
Budget for coverage: local DevTools and local automation use your development environment; hosted real-browser coverage can add service cost. Compare the environments you actually need and current provider terms.
Capture only what supports the question: a screenshot can document visual output, but it cannot demonstrate a form submission, keyboard interaction, or full user journey.

10. FAQ

Is Microsoft Edge a Chromium browser?

Yes. That is why Chromium-based automation tooling can target Edge, including Playwright’s Edge channel.

Can Playwright test Edge headlessly?

Yes. Playwright runs headless by default; pass --headed when you need to watch the browser.

Does a successful Edge test prove the site works in every browser?

No. It establishes behavior for the browser and environment actually exercised. Test other engines or real devices when those are part of the support requirements.

Should I use Playwright or WebDriver?

Use Playwright for its direct browser automation workflow and Edge channel support. Use WebDriver when an existing framework, standard, or session workflow calls for it.