Windows Sandbox provides a temporary, completely isolated Windows environment that self-destructs when you close it. Whatever you do inside — install software, download files, run executables, modify settings — disappears entirely when the window closes. The host Windows installation is untouched. This makes it ideal for testing software you’re not sure about, reproducing issues in a clean environment, or running something without leaving any trace on the main system. For a broader walkthrough, our Windows 11 How-To Guides is a good next read.
Requirements and enabling Windows Sandbox
Windows Sandbox is available on Windows 11 Pro, Enterprise, and Education. Home edition doesn’t include it. Hardware requirements: virtualisation support (AMD-V or Intel VT-x, enabled in BIOS), at least 4GB RAM (8GB or more recommended for comfortable performance), and a CPU with SLAT (Second Level Address Translation) — any modern CPU from the last 10 years qualifies.
Enable it: Win+S → “Turn Windows features on or off” → scroll to “Windows Sandbox” → check the box → OK → restart required. After restart: Win+S → “Windows Sandbox” → the sandbox environment opens.
Using Windows Sandbox
The Sandbox opens as a window on your main desktop — a full Windows desktop inside a window, completely separate from your actual Windows installation. It uses a copy of your Windows 11 installation as its base but doesn’t share files, settings, or anything else with the host.
Copying files in: drag and drop files from your main desktop into the Sandbox window. Or: copy on the host → paste inside the Sandbox. This one-way file sharing lets you bring a downloaded installer or file into the Sandbox for testing without running it on the host.
Internet access: Sandbox has internet connectivity by default, sharing the host’s network connection. This lets you download from the internet inside the Sandbox — useful for testing website behaviour, verifying downloads, or running software that checks in to its servers during installation.
What Sandbox is good for
- Testing installers from unknown sources: run the installer, see what it does, see if it asks for unusual permissions. If it installs something unwanted: close the Sandbox, it’s gone.
- Reproducing bugs in a clean environment: a fresh Windows installation without any of your customisations or software removes the “it works on my machine” problem for debugging.
- Running software that conflicts with existing installations: some tools can’t coexist with existing versions. Test the new version in Sandbox before committing to an upgrade.
- Browsing questionable websites: visit a URL in the Sandbox rather than the host. Whatever tracking, fingerprinting, or drive-by download happens: it stays in the Sandbox.
- Training demonstrations: a clean Windows environment shows software being installed from scratch without requiring a VM setup or factory reset.
Limitations to understand before relying on it
Sandbox is temporary by design — there’s no persistence. If you want to keep something from a Sandbox session: copy the output files back to the host before closing. If you close the Sandbox: everything inside is gone immediately and permanently.
Performance: Sandbox shares the host’s CPU and RAM. On 8GB RAM with 4GB allocated to the host: the Sandbox may feel slow, especially if the host is also running demanding applications simultaneously. For comfortable Sandbox use: 16GB total RAM is the practical minimum for running both the host and the Sandbox at reasonable performance.
Sandbox doesn’t protect against hardware-level exploits or vulnerabilities in the hypervisor itself (extremely rare but exist in theory). For the vast majority of software testing use cases: the isolation is complete and effective. For nation-state-level threat scenarios: Sandbox isn’t an appropriate security boundary.
Our guide on Windows 11 Hyper-V covers persistent virtual machines for scenarios where Sandbox’s ephemeral nature isn’t appropriate, and our guide on Windows Defender covers the antivirus and malware protection layer that complements Sandbox for software safety. For Windows Sandbox configuration file format (advanced), Microsoft’s Sandbox configuration documentation covers the .wsb file format for pre-configured Sandbox environments.
Windows Sandbox configuration files (.wsb)
The default Sandbox opens a clean environment. For reproducible, pre-configured Sandbox sessions: create a .wsb configuration file (a simple XML file) that specifies settings. Open the .wsb file → Sandbox opens with your configuration automatically applied. Configurable options:
- Mapped folders: share specific folders from the host into the Sandbox with read or read/write access. Example: share a folder containing a test installer so it’s immediately available inside without drag-and-drop.
- Networking: disable networking inside the Sandbox (“Disable” setting) for air-gapped testing scenarios where internet isolation is needed.
- vGPU: enable or disable virtual GPU (affects graphics performance inside Sandbox).
- Logon command: automatically run a command or script when Sandbox starts. Set up a test environment automatically without manual steps after each Sandbox open.
A simple .wsb file example:
<Configuration>
<MappedFolders>
<MappedFolder>
<HostFolder>C:TestFiles</HostFolder>
<ReadOnly>true</ReadOnly>
</MappedFolder>
</MappedFolders>
<LogonCommand>
<Command>C:UsersWDAGUtilityAccountDesktopTestFilessetup.exe</Command>
</LogonCommand>
</Configuration>This maps C:TestFiles as read-only inside the Sandbox and runs setup.exe automatically on start — a one-double-click workflow for repeatable software testing.
Windows Sandbox vs Hyper-V VMs — when to use which
| Need | Use |
| Quick, temporary test environment | Windows Sandbox |
| Keep state between sessions | Hyper-V VM |
| Test on Linux or other OS | Hyper-V VM (or WSL for Linux) |
| Completely reproducible clean Windows | Windows Sandbox |
| Snapshot capability (roll back to saved state) | Hyper-V VM with checkpoints |
| Run software without any trace on host | Windows Sandbox |
Sandbox and Hyper-V complement each other: Sandbox for ephemeral tests that don’t need persistence, Hyper-V for long-running virtual environments that need to maintain state. Many users find they want both — Sandbox for quick tests and Hyper-V VMs for development environments that take time to configure and should persist between sessions.
Windows Sandbox is one of those features that sounds more technical than it is to use. The actual experience is: open a clean Windows desktop in a window, do something, close it, it’s gone. No setup, no disk images to manage, no VM overhead to worry about. For testing purposes it’s perfect. The one thing to internalise before using it regularly: always copy files out before closing, because the Sandbox’s entire point is that it doesn’t remember anything — including the work you did inside it.
Clipboard and Sandbox security
By default: the host and Sandbox share a clipboard. Text copied inside the Sandbox can be pasted on the host, and vice versa. This is convenient but worth being aware of for security-conscious use. If testing potentially malicious software: clipboard-based exfiltration is possible if the malware copies sensitive data from the Sandbox to the clipboard and you accidentally paste it into the host. For higher-security testing: disable clipboard sharing in a .wsb configuration file or be cautious about pasting clipboard content after a Sandbox session with unknown software.
Using Sandbox for browser testing
A particularly useful pattern: testing web applications in a clean browser environment. Open the Sandbox → Edge is installed by default → browse to the application. This gives you a fresh browser without extensions, cookies, local storage, or any previous browsing state — a clean baseline for testing how the application appears to a new visitor.
For cross-browser testing: the Sandbox has Edge by default. If you need to test in Chrome or Firefox: download and install them inside the Sandbox (they’ll be gone when you close it). Or configure a .wsb file with a logon command that automatically installs Chrome or Firefox using winget: winget install Google.Chrome runs in the Sandbox and installs Chrome for the session.
Audio and graphics in Sandbox
Sandbox provides audio output — applications inside that play audio work. Graphics: hardware acceleration is available if vGPU is enabled in the sandbox configuration, providing acceptable performance for most applications. 3D games and applications requiring high-performance GPU may perform poorly in Sandbox, but standard business and productivity software runs well.
The resolution of the Sandbox window adapts to the window size — resize the Sandbox window and the desktop inside scales accordingly. This makes using the Sandbox on high-DPI displays comfortable — it doesn’t lock to a fixed resolution the way older VM approaches often did.
How the Sandbox starts so quickly
Unlike a Hyper-V VM that boots a complete OS (taking 30-60 seconds): the Sandbox typically opens in 5-15 seconds. This speed comes from how Sandbox works internally: it’s based on the running Windows 11 host installation, using a copy-on-write model where it shares the host’s read-only OS files rather than maintaining its own complete copy. Only differences from the base Windows installation (things you do inside the Sandbox) are stored in the temporary working set. This architectural approach provides VM-like isolation with startup times closer to opening a regular application.
This also explains why Sandbox always starts with the current Windows 11 version — it inherits the host’s OS version and update level. There’s no separate Windows installation to update inside the Sandbox; it starts from the same base as the host every time.
Windows Sandbox and organisational security
For corporate environments: Windows Sandbox provides a built-in secure testing environment for evaluating vendor software, running legacy applications that require older system states, or opening suspicious email attachments in an isolated environment before determining whether they’re legitimate. IT teams can pre-configure .wsb files for standard testing scenarios — a security team might have a dedicated .wsb file that maps a malware samples folder and has network disabled for safe analysis.
This built-in capability means organisations don’t need dedicated “detonation” VMs or expensive sandboxing products for moderate-risk software evaluation. For enterprise-grade malware analysis with deep inspection, dedicated products are still appropriate — Windows Sandbox is for ad-hoc testing and light-duty isolation, not for professional malware research.
Windows Sandbox is a feature that genuinely changes how you think about running unfamiliar software once you start using it. The habit of “test in Sandbox first” provides a real safety net for the common scenarios (unknown installers, questionable downloads, unfamiliar software from new vendors) where most users currently just run things and hope for the best. The feature is built-in, starts in seconds, and requires no ongoing management. For Windows 11 Pro users who haven’t enabled it: it’s worth enabling before the next time an unfamiliar executable arrives.
Troubleshooting Windows Sandbox
If the Sandbox fails to open or crashes on launch: common causes and fixes:
- Virtualisation not enabled: check BIOS → enable Intel VT-x or AMD-V → Windows features → ensure Hyper-V and Windows Hypervisor Platform are enabled alongside Windows Sandbox
- Insufficient memory: Sandbox needs available RAM — if the host is running near capacity, Sandbox may fail to start. Close other applications first.
- “Windows Sandbox failed to start” error: Open Services (services.msc) → check that “Windows Sandbox App Helper” service is running. Also: ensure virtualisation is enabled in Windows Features (Hyper-V and Windows Hypervisor Platform) — Sandbox depends on these even on systems that don’t use Hyper-V directly.
- Sandbox available but greyed out in Windows Features: the processor doesn’t support SLAT, or virtualisation is disabled at BIOS level. Check BIOS settings first.
The Sandbox’s fast startup and zero-configuration-needed approach for basic use makes it among the most accessible of Windows 11’s advanced features. Enable it, open it when needed, close it when done. The default configuration covers most use cases without any .wsb file or additional setup. The configuration file approach is for users who need consistent, reproducible sandbox environments — optional for most users, powerful for those who need it. You might also run into Reset Chrome Settings Without Losing Data.
One more practical note: if you’re on Windows 11 Home and need Sandbox-like isolation, a few alternatives exist. Windows Sandbox is exclusively Pro/Enterprise/Education, but Windows Defender Application Guard provides similar ephemeral isolation for Edge browser sessions (Settings → Privacy & security → Windows Security → App & browser control → Isolated browsing). For software testing specifically, the free tier of cloud services (AWS, Azure, Google Cloud) can provide a temporary Windows VM for testing purposes — it’s more setup, but removes the hardware requirement and local resource consumption of Sandbox. Related: Software Supply Chain Security.
