Using Virtual Machines for Cross-Browser Testing
Learn when virtual machines help with cross-browser testing, how to set up a repeatable workflow, and when emulation, simulators, or hosted testing are a better fit.
A virtual machine (VM) lets you run a guest operating system on your development computer, install a browser available for that operating system, and inspect your site in that environment. It is useful for repeatable local checks and debugging. It does not make the guest equivalent to every physical device, and changing a browser viewport or user agent does not reproduce another browser engine’s CSS or web API support. For browser-specific confidence, test the target browser on the target platform or use a sufficiently representative real device or service. Microsoft’s Edge guidance explains the limits of browser emulation.
What a VM can and cannot tell you
A VM runs a guest OS in an environment hosted by your computer. You can use it to install and exercise browsers available in that guest OS, inspect behavior there, and keep a test environment separate from your daily development setup. Microsoft describes using VMs to test other operating systems, including Windows and Linux variants with Hyper-V.
| Approach | Useful for | Limit to keep in mind |
|---|---|---|
| VM with target OS and browser | Local debugging and repeatable OS/browser checks | Still virtualized; it does not prove behavior on every physical device or hardware configuration. |
| Browser device emulation | Fast checks of viewport, resolution, touch settings, and user-agent conditions | Does not emulate differences in browser API or CSS support. |
| Device simulator or emulator | More OS-integrated behavior, such as mobile keyboard input | Still a modeled environment; confirm whether the behavior under investigation needs real hardware. |
| Hosted browser or device testing | Platform combinations unavailable locally and automated cross-platform runs | Check the exact browser, version, OS, device, current access terms, and whether the service can reach your test site. |
| Physical target device | Investigations that depend on actual device behavior | Requires access to the specific device and its software configuration. |
Microsoft’s concise warning is: “Browser emulators don’t emulate differences in web API support or CSS support.” Use emulation as an early layout check, not as cross-engine compatibility sign-off. Source: Microsoft Edge Developer documentation.
Choose the right test environment
Start with the failure you want to catch. A clipped mobile layout calls for viewport checks; a CSS support problem calls for the actual browser engine; keyboard behavior may require an OS simulator or device; an automated regression matrix may fit a hosted service.
- Identify your users’ combinations. List the relevant browser engine, browser version, operating system, and device class. Avoid selecting a combination only because it is easy to launch.
- Define the test goal. Separate visual layout checks from browser API behavior, OS integration, input behavior, and regression automation.
- Check local feasibility. Confirm host and guest compatibility, the availability of the needed OS and browser, and any licensing requirements. The source guidance does not guarantee that a particular image or browser version is available for every setup.
- Choose VM, simulator, hosted test, or real device. Use a VM when local access and debugging matter and you can maintain the image. Use hosted testing for combinations you cannot manage locally or for broader automated coverage. Microsoft identifies iOS Simulator with Xcode and Android Emulator as examples of platform simulators.
- Record the environment. Note guest OS, browser and version, viewport, test data, and steps to reproduce. This makes failures easier to compare and hand off.
- Recheck the exact combination before relying on it. Browser and OS inventories, service coverage, and terms can change.
Set up a repeatable VM testing workflow
- Choose a guest OS that matches the question. Use the target OS when OS-specific behavior matters. A different guest can help test another OS, but it does not stand in for a real device.
- Create or obtain a compatible VM image. Follow the virtualization platform’s current instructions and check host/guest compatibility and licensing. Hyper-V is one Microsoft example for running Windows and Linux virtual machines.
- Install the browser you need in the guest. Record the exact browser and version. Verify the browser is available for that guest OS rather than assuming a VM makes every combination possible.
- Make the test site reachable. Confirm DNS, network access, authentication, and any development-server or proxy requirements from inside the guest. For private sites, verify the setup allows the guest to reach them.
- Run the same scenario as the host. Use the same route, account state, test data, and interaction steps. Capture screenshots or logs when useful, and note the environment with each result.
- Keep a known-good baseline. Preserve a clean image or documented setup and update it deliberately. If a failure appears after an OS or browser update, compare against the recorded baseline.
- Escalate fidelity when needed. If a result depends on touch, keyboard integration, graphics, performance, or physical hardware, use the target simulator or a real device/service appropriate to that behavior.
Do not infer a VM’s fidelity from the fact that the browser launches. Validate the specific behavior and platform combination that matters to your users.
Build a useful test matrix
A small, purpose-driven matrix is easier to maintain than a list of every possible combination. Include representative combinations that cover your audience and the risks in your application.
| Test dimension | What to record | When it matters |
|---|---|---|
| Browser | Name, engine where known, and version | CSS, JavaScript, and web API differences |
| Operating system | OS and version | OS-specific browser behavior and integration |
| Device context | Physical device, simulator, VM, or hosted environment | Touch, keyboard, graphics, and hardware-sensitive behavior |
| Viewport | Width, height, and scale assumptions | Responsive layout and visual checks |
| Scenario | Route, actions, account state, and expected result | Reproducing regressions consistently |
| Environment upkeep | Image source and date updated | Understanding drift and reproducing older results |
Prioritize combinations based on user impact and known failure modes. The research sources do not establish a universally correct number of environments or a cost or speed winner; those depend on your project and setup.
Automate checks without overstating coverage
Automation can run the same scenario in multiple environments, but the result only covers the environments actually selected. A passing test in one browser or emulated viewport is not proof that another engine supports the same APIs or CSS.
- Keep test steps and test data stable across environments.
- Separate screenshots used for visual comparison from assertions about application behavior.
- When a test fails, preserve the browser, version, OS, and device context with the failure.
- For hosted testing, verify the required browser/version/OS/device combination and current service terms before building a required workflow around it.
BrowserStack’s Selenium documentation describes selecting browser, version, OS, device, and OS version. This is a vendor example; verify current coverage and terms directly with the provider.
Legacy Internet Explorer testing
Internet Explorer desktop support ended June 15, 2022. For sites with a continuing legacy requirement, Microsoft’s current direction is IE mode in Microsoft Edge. Whether and how it is enabled can depend on site configuration and organization policy. Consult Microsoft’s current IE mode support instructions and your organization’s managed-browser settings.
Microsoft’s February 2022 IE mode and Selenium guidance describes using Edge, Selenium 4 or later language bindings, and Internet Explorer Driver 4.0.0.0 or later. Because that post is dated, check current Edge and Selenium documentation before adopting those details in a maintained test suite.
Or skip the browser setup
If your goal is a clean capture of how a page looks, ScreenshotNeo can return a screenshot or PDF with one GET request. It complements browser compatibility testing: use the target browser or platform for engine-specific behavior, and use ScreenshotNeo when you need a page capture without setting up a browser environment.
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}`);
See the ScreenshotNeo API documentation for request options. Cookie banners are accepted like a visitor and more than 60 known consent platforms, newsletter popups, and chat widgets are removed before the shot; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers report the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents and MCP clients. The Free plan includes 1,000 shots per month with no card; paid plans start at $5 for 3,000 shots. Every feature is on every plan.
Create a free ScreenshotNeo account and get 1,000 screenshots a month with no card.
Troubleshooting
| Symptom | Likely cause | What to check |
|---|---|---|
| The browser or OS cannot be installed | The desired combination may not be available or compatible with the host/guest setup. | Verify host and guest compatibility, image availability, and licensing; choose a supported environment or hosted service. |
| The site works on the host but not in the VM | The guest may have different network, DNS, authentication, proxy, or local-server access. | Open the site from inside the guest and check its network and access configuration. |
| A layout looks right in emulation but breaks in another browser | Viewport emulation does not reproduce browser-engine CSS or API support differences. | Reproduce in the target browser engine on the target platform. |
| A mobile interaction differs | Browser-only emulation may not model OS-integrated keyboard or device behavior. | Use the relevant simulator/emulator or a representative physical device. |
| A regression cannot be reproduced by a teammate | The browser, OS, image, viewport, account state, or test steps differ. | Record the exact environment and scenario; compare against a known baseline. |
| IE behavior differs from the old desktop browser | IE desktop support has ended; managed policy or IE mode site configuration may affect behavior. | Check current Edge IE mode instructions and organization policy. |
| A hosted test does not offer the expected combination | Browser and device inventories change by provider and over time. | Confirm the exact combination and current terms with the service before depending on it. |
Performance, reliability, and cost considerations
A VM adds image setup and upkeep to local testing. A clean, documented environment helps with repeatability, while updates and configuration drift can make results harder to compare. Hosted testing avoids maintaining every environment locally and can run automated coverage across platforms, but availability, exact combinations, access, and cost depend on the current provider and plan. The reviewed sources do not support general claims that VMs are always faster, cheaper, or more accurate than hosted testing.
Choose the smallest matrix that covers your users and risks, then add environments when evidence or a product requirement calls for them. For behavior tied to hardware or OS integration, use a representative device rather than treating virtualization as proof.
FAQ
Does a VM count as real-device testing?
No. It provides a guest OS environment, but does not establish equivalence with a physical device’s hardware and behavior.
Can changing the user agent test another browser?
It can approximate a user-agent condition, but it does not switch the browser engine or reproduce that engine’s CSS and web API support.
Should I use a VM or a cloud testing service?
Use a VM when local inspection and a manageable OS environment suit the task. Consider hosted testing when you need combinations unavailable locally or automated cross-platform coverage, after checking current availability and terms.
Is Internet Explorer still supported?
IE desktop support ended June 15, 2022. Organizations with legacy requirements can configure IE mode in Edge, subject to site configuration and policy.


