ExeBrowser

The Complete Guide to Running Windows EXE Files in a Browser

Last updated: June 8, 2026 · ~12 minute read

Running a Windows program inside a web browser sounds like it shouldn't be possible. There's no Windows underneath, no x86 processor guaranteed, no installer — just a tab. Yet it works, and this guide explains both how it works and, more usefully, how to get the most out of it. Whether you're trying to revive an old shareware game, recover a document from a legacy utility, or just satisfy your curiosity, this is the practical manual.

1. Why would anyone run an EXE in a browser?

The honest answer is friction. The classic 32-bit Windows era — roughly 1995 to 2008 — produced an enormous catalog of software: utilities, games, educational CD-ROM titles, business tools, demoscene productions. A great deal of it still functions, but the hardware and operating systems it was built for are vanishing. If you own a Chromebook, an iPad, a modern Mac, or a Linux box, running a 1999 Windows installer is a chore: you need a virtual machine, a Windows license, and patience.

Browser-based execution collapses that. The application logic travels to wherever a modern browser runs, which is essentially everywhere. Common motivations include:

• Software preservation. Museums, archivists, and hobbyists keeping old programs runnable without shipping virtual machines.
• Education on locked-down devices. Schools on Chromebooks that still need a specific legacy learning tool.
• Quick demos. Showing a colleague an old internal tool without an installer or a VM.
• Recovery. Extracting data from a file that only an old EXE knows how to open.
• Nostalgia. Revisiting shareware you remember from a 56k modem and a beige tower.

2. How it actually works: three stacked layers

It helps to understand the machinery, because the limitations follow directly from it. Three technologies sit on top of one another.

Layer one is the CPU emulator. A Windows EXE is a stream of x86 machine instructions. Your browser speaks WebAssembly, not x86, so it can't run those instructions directly. The solution is a software CPU: a program, written in C++, that reads each x86 instruction and simulates its effect on a virtual Pentium-era processor. That C++ emulator is compiled to WebAssembly, and the browser runs that. You are therefore running an emulator inside an emulator of sorts — which is exactly why it's slow.

Layer two is Wine. An EXE doesn't only contain CPU instructions; it constantly calls into Windows system libraries like kernel32.dll, user32.dll, and gdi32.dll. Wine — recursively named "Wine Is Not an Emulator" — is a from-scratch reimplementation of those Windows APIs on a POSIX foundation. When the emulated program calls CreateWindowExA, Wine intercepts it and runs its own compatible version. Wine is decades-deep and astonishingly complete, but it isn't 100% of Windows, which is the second source of incompatibility.

Layer three is the browser bridge. Wine's output still has to appear somewhere. The runtime maps Wine's framebuffer to an HTML <canvas>, pipes your keyboard and mouse into Wine's input queue, sends audio to Web Audio, and fabricates a virtual C:\ drive (using an in-memory filesystem) so Wine believes it's looking at a normal disk. The whole pipeline runs single-threaded on the page's main WebAssembly instance, so it works in any modern browser with no special headers or flags.

Stacked together, the pipeline delivers roughly 10–40% of native CPU speed. For a menu-driven utility that's invisible. For a 3D game or heavy compression it is very noticeable.

3. Which applications actually run?

After a great many test runs, the pattern is consistent. The following categories work well:

• Pre-2005 utilities and shareware — file managers, hex editors, text editors, early WinRAR/7-Zip GUIs, small tools.
• 2D games from the Win9x and early-XP era — point-and-click adventures, puzzle games, turn-based strategy, 2D RPGs. Anything happy on a 500 MHz Pentium III.
• Early office suites — Office 97 and 2000 mostly work; AbiWord and Gnumeric are very reliable.
• Programming and demo tools — VB6 and early Delphi apps, Turbo Pascal binaries, classic Win32 demoscene productions.
• Educational software — late-90s CD-ROM titles, math and language tutors.

And the categories that struggle:

• Anything 64-bit. The Wine build here is 32-bit only; x64-only binaries won't load. Look for an older 32-bit release.
• 3D games using DirectX 9+, Direct3D 10/11/12, or Vulkan. The 3D pipeline is limited; OpenGL 1.x works, modern shader stacks don't.
• .NET 4.5 and later. The bundled Wine predates much of modern .NET. 2.0/3.5 apps sometimes work; newer runtimes usually don't.
• DRM, online activation, anti-cheat. These probe the system in ways Wine can't satisfy and refuse to start.
• Post-Windows-7 APIs. UWP apps, modern shell extensions, ribbon UIs from Office 2010+.

4. Choosing the right Wine variant

ExeBrowser offers four runtime variants, and picking the right one is the single biggest factor in whether an app starts.

• Wine 1.7.55 · Win32 (default). The everyday choice for almost anything from 1995–2008. Most of the filesystem is fetched on demand, so the first boot only pulls what the app touches — usually 30–60 MB. Start here.
• Wine 1.7.55 · Win32 + Gecko. Same as the default but with an offline copy of the Wine Gecko package bundled in. Use it when an app or installer embeds Internet Explorer / HTML-help components and prompts to download Gecko — for example 3D Pinball Space Cadet, or MSI installers that call into HTML help.
• Wine 3.1 · Win 3.x 16-bit only. A specialized build for 1990–1994 16-bit Windows programs using the WIN16 API. It will not run Win32 apps. Reach for it with genuinely old 16-bit shareware.
• Boxedwine 18R2. An older 2018 snapshot of the engine. The Wine version is similar but the emulator and integration differ, so occasionally an app that fails on the default engine succeeds here (or vice versa). It's the "try this when nothing else works" option.

A reasonable strategy: try the default first; if the app mentions HTML/IE/help, switch to +Gecko; if it's clearly 16-bit, use Win 3.x; if it crashes instantly on the default, try 18R2.

5. Bringing your own DLLs and data files

Many real applications aren't a single self-contained EXE — they expect DLLs, data files, or configuration sitting beside them in their install directory. Dropping just the EXE leaves those behind, and the app fails to find data\maps\level1.dat or plugins\render.dll.

The fix is to upload the whole folder (or a zip of it) instead of the lone EXE. Use the folder or zip picker on the loader. Everything you provide is copied into Wine's virtual C:\Users\username\Desktop\userapp\ directory before the program runs, so relative-path lookups succeed. When a bundle contains more than one EXE, an entry picker lets you choose which one to launch. This single step resolves a large share of "it just won't start" cases.

6. Troubleshooting the common failures

"Boot Wine" never finishes. Usually a blocked or stalled download of the runtime files — a corporate proxy, firewall, or aggressive browser extension interfering with the multi-megabyte .wasm and filesystem fetches. In DevTools → Network, check whether requests to /boxedwine/… are failing or hanging. Try another network, disable ad-blocking extensions for this site, and reload.

Black canvas after Run. The app started but crashed during init or is waiting on something invisible. Open the Console section and look for lines beginning with err:. err:module:import_dll Library X.dll not found means a missing DLL — bundle the install folder. Codes like 0x80004005 or STATUS_DLL_NOT_FOUND mean the same. An empty console? Try the 18R2 variant.

"MSI install error 1627." A Wine 1.7.55 limitation — incomplete MSI custom-action support, not an ExeBrowser bug. There's no in-browser workaround. Find a non-MSI installer if one exists, or extract the MSI on your own machine (7-Zip or msiextract) and upload the extracted folder.

Impossibly slow. Expected — you're emulating an x86 CPU inside WebAssembly. Enable any "fast"/"low quality" render mode the app offers, close other tabs, and prefer a Chromium-based browser (its WebAssembly tier-up is currently fastest).

Keyboard/mouse not reaching the app. Click directly on the canvas to capture input; press Esc to release it. Wine defaults to a US keyboard layout, so wrong characters can mean a code-page mismatch the app assumes.

Files vanish after reload. The virtual C:\ lives in memory and is wiped on reload. Use "Download files written by this app" before reloading, then re-upload that zip alongside the EXE next time to restore your state.

7. Saving and recovering your work

Because the filesystem is in-memory, anything the program writes — installer output, save files, generated documents — disappears when the tab closes. The "Download files written by this app" button packages everything the program wrote to C:\ into a zip you can keep. This is the canonical way to extract installer results or game saves, and to carry state between sessions: download the zip, then re-upload it as a folder/zip next visit.

8. A short history of Windows-in-a-browser

The idea predates most current browsers. In the early 2010s, projects like v86 booted whole operating systems (DOS, Windows 95, ReactOS) inside a JavaScript x86 emulator, and Fabrice Bellard's JSLinux showed a full Linux userland running client-side. They were slow curiosities, but they proved the concept. The turning point was WebAssembly, standardized in 2017, which let browsers run compiled bytecode near native speed — suddenly large C/C++ codebases like Wine became viable targets. Boxedwine gained an experimental WebAssembly target around 2018 (the "18R2" build still used as the alternate engine here), and later builds added on-demand range-fetched filesystems so boots take seconds instead of minutes.

9. Frequently asked questions

Is my file uploaded? No. It's read locally and written into an in-memory filesystem; nothing leaves your device. See the privacy policy.

Do I need a fast computer? Any modern browser (Chrome, Edge, Firefox, Safari) and ideally 4 GB+ free RAM. Single-core speed matters most; a 2018-or-newer laptop is comfortable.

Can I run 64-bit apps? No — the engine is 32-bit only. Find a 32-bit build of the same software.

Is this legal? Running software you have the right to run is fine. You're responsible for the executables you load; see the terms of use.

Ready to try it?

Head back to the main page, boot Wine, and drop in an EXE. Start with something small and old — a classic puzzle game or a simple utility — to get a feel for it before reaching for anything ambitious. And if you discover something that works especially well (or amusingly fails), the contact page is open.