Free tools Windows power users keep installed
One-click scans. No signup required.
To test a website on older browser versions, choose browsers from your audience data and support commitments, then run your most important user journeys in those actual browser engines. Check feature support before implementation, provide fallbacks where needed, and use emulation only for quick layout or user-agent checks—not as proof that a site works in Safari, Firefox, or an older browser.
What cross-browser testing should prove
Cross-browser testing checks that a site works across browsers and devices, including older versions that may lack newer JavaScript, CSS, or Web API features. The goal is not necessarily identical rendering everywhere: users should be able to access the site’s core functionality, with any differences handled deliberately. MDN recommends agreeing on the supported browser and device range with the site owner before implementation.
For an older-browser test, ask whether a person can complete important tasks—not just whether a page loads. A page may look acceptable while its form submission, navigation, or payment flow is broken.
How to choose the browsers and versions
There is no universal browser list that every site should support. Build a matrix from audience analytics, geography, device mix, contractual or support obligations, and the impact of a failure. Include the latest major desktop browsers, then add specific older versions that still appear in your audience data or are required by an agreement.
#1 Best Overall
MDN’s approach is to test important browser combinations rather than every possible browser-and-device pair. A browser known to lack capabilities the site needs may receive a lower support grade, but that decision should be explicit rather than accidental.
| Decision axis | What to consider |
|---|---|
| Engine and version | Does the test use the browser engine and version you need to support, or only imitate its screen and user-agent string? |
| Feature coverage | Does it cover the JavaScript, CSS, and Web APIs the site relies on? |
| Critical-flow automation | Can the team repeat the same important journeys and catch regressions? |
| Operating system and device | Can it reproduce the OS or device constraints that matter to the audience? |
| Accessibility and input | Can the team test keyboard use, screen readers, touch, and other relevant input methods? |
| Evidence and repeatability | Can the team capture screenshots, logs, and environment details to reproduce a defect? |
| Operational cost | Can the team maintain the test environment and tolerate its setup time or queue time? |
Check compatibility before writing the feature
For each API, CSS property, or JavaScript feature that matters to a release, check MDN Browser Compatibility Data (BCD). BCD is machine-readable compatibility information used by MDN and developer tools. A compatibility check early in implementation can reveal that a planned feature needs a fallback in a supported browser.
Rank #2
When a required feature is missing, choose an appropriate response: use a simpler baseline, progressively enhance the experience, add a suitable polyfill, or transpile newer JavaScript syntax to code older engines can parse. Record the intended fallback in acceptance criteria. A polyfill may supply an API, but it does not automatically reproduce every browser behavior or make unsupported CSS work.
A repeatable older-browser test workflow
- Set the support boundary. Use audience and risk data to write down supported browsers, versions, operating systems, and devices. Note any exclusions and the reason for them.
- Choose critical journeys. Build a smoke suite for the site’s highest-value paths, such as navigation, authentication, forms, payments, media playback, and error handling. Include the actions and expected outcomes, not just the pages to visit.
- Run fast checks during development. Use stable local browsers for quick checks after each implementation phase so basic regressions surface early.
- Run the same journeys in the target legacy environments. Use a local browser, a virtual machine, a hosted real-browser service, or an automated WebDriver setup that actually provides the engine and version in question.
- Test accessibility and input. Repeat relevant checks with keyboard-only operation and screen readers. Browser support includes whether people can use the site, not only whether its layout renders.
- Record enough detail to reproduce failures. For each defect, capture browser and version, operating system, viewport, locale, network condition, screenshots, console output, and WebDriver logs where applicable.
- Triage the cause. Classify failures as product bugs, unsupported features, environment defects, or accepted graceful degradation. Fixes depend on the category.
- Re-run high-risk paths after a fix. A compatibility change can affect other browsers, so repeat the affected journey and the most consequential regression checks.
Emulation is useful, but it is not a substitute for a browser
Microsoft Edge’s Device Emulation can change screen size, touch events, and the user-agent string. That makes it useful for quick responsive-layout checks and for seeing how a site responds to user-agent-based logic.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
It does not reproduce how another browser engine implements Web APIs or CSS. Microsoft specifically cautions that Edge’s device emulation does not emulate how Firefox or Safari support the Web APIs and CSS features a site uses. Use an actual target browser engine, a virtual machine, or a hosted real-browser environment when making conclusions about feature support, rendering, input, performance, or accessibility.
| Approach | Useful for | Important limitation |
|---|---|---|
| Emulator or DevTools device mode | Fast viewport, touch-event, and user-agent checks | Does not establish another engine’s CSS or API behavior |
| Local real browser or virtual machine | High-control testing, including environments that need to stay local or offline | The team must maintain the browsers and test environments |
| Hosted real-browser service | Access to multiple browser and OS combinations with shareable test evidence | Verify current browser coverage and the service’s data-handling terms |
| WebDriver and Selenium | Repeatable automated journeys across supported browsers | Automation still depends on a correctly configured real browser environment |
MDN names BrowserStack and Sauce Labs as commercial services that automate much of the cross-browser setup. The particular service and available browser versions should be checked against the matrix you actually need.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Testing Internet Explorer-dependent applications now
Microsoft ended security updates and technical support for Internet Explorer on June 15, 2022. Treat an application that still depends on IE behavior as a legacy dependency: define how it will be contained or retired instead of treating IE desktop as an ordinary, current browser target.
Automate Edge IE mode with Selenium
For a workflow that still needs IE behavior, Microsoft’s documentation describes launching Microsoft Edge in IE mode through Internet Explorer Driver (IEDriver) and Selenium. The documented requirement is IEDriver version 4.0.0.0 or later; the driver starts Edge and loads content in IE mode. This is a controlled compatibility route, not a reason to assume that every old IE installation remains supported.
Use a hosted IE-mode environment when appropriate
BrowserStack documents hosted IE-mode testing with Internet Explorer 11 running under Edge, on Windows 10 or Windows 11, using Selenium 4 or higher. This gives teams a hosted route for that documented configuration; it does not establish support for every IE version or environment.
Check document mode before blaming the browser version
A rendering discrepancy can come from the document’s mode rather than from the browser version you are testing. MDN explains that quirks mode emulates behavior associated with Navigator 4 and Internet Explorer 5, while no-quirks mode follows modern HTML and CSS expectations. Confirm the doctype and document mode before diagnosing a layout difference as a legacy-browser defect.
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.
