ExeBrowser

▶ Quick Play — hosted games & apps

Free, license-clean software we host for you. One click to play — no upload needed.

🎮 = opens its own play page (DOSBox)  ·  🖥 = runs right here in Wine  ·  See all 53 app guides →

1 Boot Wine

First boot downloads ~12 MB of runtime + on-demand Wine filesystem. Cached after that.

3 Wine display

Click the canvas to capture mouse and keyboard. Press Esc to release.

Console

Popular apps people run in the browser

Looking to run a specific program? These guides cover whether it works in ExeBrowser, which Wine variant to pick, and how to load it. See all app guides →

• DOOM (free shareware)The 1993 classic — free, legal, hosted here.
• 3D Pinball Space CadetPlay the open-source port free — instant, hosted here.
• WinRARGuide: load your own copy — see what works in Wine.
• Notepad & classic utilitiesGuide: tiny Win32 tools run great with your own copy.
• Windows SolitaireGuide: runs well via Wine — bring your Windows copy.
• AbiWordGuide: the free word processor runs well — load your copy.
• Age of EmpiresCan the RTS classic run? What to expect.
• 7-ZipExtract archives with the open-source tool.

Will my app run?

Best chance: classic 32-bit Win32 apps (1995–2008 era). Solitaire, Notepad, AbiWord, Age of Empires, old shareware, simple installers without modern dependencies.

Probably won't run:

• 64-bit apps (Wine here is 32-bit only)
• Anything needing DirectX 10/11/12, Vulkan, or modern GPU features
• Modern .NET (Framework 4.5+ or .NET Core/5+) — limited support
• Apps with online activation, DRM, or anti-cheat
• Anything calling Win32 APIs added after ~Windows 7

Wine speed is roughly 10–40% of native. CPU-heavy apps will feel slow.

FAQ

How WebAssembly + Wine actually works under the hood

When you boot Wine in your browser, three distinct technologies are stacked on top of one another. Understanding the layering helps explain both the magic and the limitations.

Layer 1 — the x86 CPU emulator. The foundation is Boxedwine's CPU interpreter. A real Windows EXE is a stream of x86 (or x86-64) machine instructions: MOV EAX, [EBP+8], CALL printf, and so on. Your browser doesn't speak x86 directly; it speaks WebAssembly, a portable bytecode format. So Boxedwine ships a software CPU written in C++ that reads x86 instructions one at a time and simulates the effect each one would have on a real Pentium-era processor. That C++ CPU itself is then compiled to WebAssembly, which the browser executes. This is the slow part — you're paying for two levels of indirection.

Layer 2 — Wine. A Windows EXE doesn't just contain CPU instructions; it also makes thousands of calls into Windows DLLs like kernel32.dll, user32.dll, gdi32.dll, ddraw.dll, and so on. Wine ("Wine Is Not an Emulator") is a re-implementation of the Windows API on top of POSIX. When the emulated CPU executes a CALL CreateWindowExA instruction, Wine intercepts that call and runs its own POSIX-compatible version of CreateWindowExA. This is why Wine adds a runtime cost beyond emulation: every API call gets translated.

Layer 3 — the browser bridge. Wine's POSIX-style output still has to render somewhere. Boxedwine maps Wine's framebuffer to an HTML5 <canvas>, routes keyboard and mouse events from the browser into Wine's input queue, and synthesizes a virtual filesystem (BrowserFS) so Wine sees a normal-looking C:\ drive even though it's just JavaScript holding bytes in memory. Audio goes to Web Audio. The whole pipeline runs single-threaded on the page's WebAssembly instance, so it needs no special browser flags or headers.

The whole pipeline — emulator-in-Wasm running Wine running your EXE — typically delivers around 10–40% of native CPU performance. For UI-driven apps that's invisible. For 3D games or compression-heavy work it's noticeable.

Application compatibility guide

The following observations are based on hundreds of test runs across the four Wine variants. They are guidelines, not guarantees — Wine's behavior is sensitive to even minor differences in DLL usage.

Categories that work well

• Pre-2005 utilities and shareware — file managers, hex editors, CD rippers, weather widgets, the early generations of WinRAR and 7-Zip GUIs, Notepad-style text editors.
• 2D games from the Win9x / early XP era — point-and-click adventures, classic puzzle games, turn-based strategy, 2D RPGs. Anything that ran happily on a 500 MHz Pentium III.
• Old Microsoft Office and clone office suites — Office 97, Office 2000 mostly work; later versions get progressively flakier. AbiWord and Gnumeric run very reliably.
• Programming and demo tools — early Delphi / VB6 apps, Turbo Pascal binaries, classic demoscene executables targeting Win32.
• Educational software — Encarta-era CD-ROM content, math tutors, language learning apps from the late 90s.

Categories that struggle

• Anything 64-bit — Wine here is 32-bit only. Modern apps shipping only x64 binaries will refuse to load. Older 32-bit installers are usually still available on archives like archive.org.
• 3D games using DirectX 9+, Direct3D 10/11/12, or Vulkan — Boxedwine's 3D pipeline is limited. OpenGL 1.x works; modern shader stacks do not.
• .NET 4.5 and later — Wine 1.7.55 predates much of modern .NET. .NET 2.0 and 3.5 apps sometimes work; later runtimes are usually a non-starter without manual DLL replacement.
• Software with DRM, online activation, or anti-cheat — these typically probe the kernel in ways Wine can't satisfy and refuse to start.
• Anything calling Win32 APIs added after Windows 7 — UWP, modern shell extensions, ribbon UI from Office 2010+, hardware-accelerated text rendering.

Tips for getting borderline apps to work

• Try the +Gecko variant first if the app mentions HTML, IE, or HTML Help. A surprising number of late-90s apps embed an IE control for help screens or licensing screens.
• For 16-bit programs, use the Win 3.x variant. Win32 variants don't include WoW (Windows-on-Windows) for 16-bit support.
• If an app needs extra DLLs or data files, bundle them as a folder or zip. Use the folder picker to upload the entire install directory at once so DLLs sitting beside the EXE are found at runtime.
• If the default engine crashes immediately, try 18R2. The two engines have slightly different quirks and one will sometimes succeed where the other doesn't.
• Watch the console output. Wine prints fixme: and err: lines that pinpoint missing functions. A flood of fixme:msi usually means the app needs an MSI feature Wine doesn't implement.

Troubleshooting common problems

"Boot Wine" never finishes

The most common cause is 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. Open DevTools, switch to the Network tab, and check whether requests under /boxedwine/ are failing or hanging. Try a different network, or temporarily disable ad-blocking extensions and reload.

The canvas is black after I click Run

This usually means the app started, but either crashed immediately during init or is waiting on something invisible (a missing DLL, a missing registry key, a console window we don't render). Open the Console section and scroll for lines starting with err:. If you see err:module:import_dll Library X.dll not found, the app needs a DLL we don't ship — bundle the install folder using the folder picker. If you see 0x80004005 or STATUS_DLL_NOT_FOUND, same story. If the console is empty, try the 18R2 variant.

"MSI install error 1627"

This is a Wine 1.7.55 limitation, not an ExeBrowser bug. The bundled Wine version has incomplete MSI installer support; some MSI custom actions and table types aren't implemented. There's no workaround inside the browser. If you can find a non-MSI installer for the same app (some shareware ships both), or extract the contents with a tool like 7-Zip or msiextract on your local machine first and upload the extracted folder, that usually gets you past it.

App opens but is impossibly slow

Remember that you're running an x86 emulator inside WebAssembly inside a browser. Expect 10–40% of native performance on a fast laptop, less on a tablet. CPU-heavy apps (compression, encryption, large file parsing, software 3D) feel especially slow. If the app has any "low quality" or "fast" rendering mode, enable it. Close other tabs. Use a Chromium-based browser if possible — V8's Wasm tier-up is currently the fastest.

Keyboard or mouse input isn't reaching the app

Click directly on the canvas to capture input. The canvas needs focus to receive events. If you press Esc, focus is released back to the page. Some apps expect a certain keyboard layout — Wine here uses US English by default; if you type and see wrong characters, the app may be assuming a different code page.

Files I created inside the app are gone after a reload

The virtual C:\ drive lives in memory, not on your disk. Reloading the page wipes everything. Before reloading, click Download files written by this app to save anything you generated. On the next visit, upload it as a folder or zip alongside the EXE to restore your working state.

Why run Windows apps in a browser? A short history

The dream of "Windows in a browser" is older than most browsers. It started in earnest in the early 2010s with projects like v86, which booted full PC operating systems (DOS, FreeDOS, Windows 95, ReactOS) inside a JavaScript x86 emulator. Around the same time, Fabrice Bellard's JSLinux demonstrated that a complete Linux userland could run client-side. These were curiosities — performance was poor and integration with the browser was minimal — but they proved the concept.

The big shift came with WebAssembly, standardized in 2017. Suddenly browsers could execute compiled bytecode at near-native speed, and large C/C++ codebases like Wine became plausible targets. Boxedwine — originally a desktop project to bundle Wine + a CPU emulator for Windows users — gained an experimental WebAssembly target around 2018. The 2018 Release 2 ("18R2") build is the snapshot still distributed by sourceforge and used here as the alternative engine option. The current engine builds use a more recent Wine integration with on-demand range-fetched filesystems, which is what makes the default variant boot in seconds rather than minutes.

The practical use cases turned out to be more compelling than the academic ones. Schools running Chromebooks needed a way to run legacy educational Win32 software. Museums and archives wanted to make CD-ROM-era content browsable without shipping a virtual machine. Hobbyists with iPads wanted to revisit shareware from their youth. Developers wanted to demo old internal tools without installers. And every year, more of the early Win32 software ecosystem slipped out of practical reach because it had been written for an OS and CPU that newer machines no longer ran. Running it in a browser is the easiest preservation strategy that doesn't ask the user to install anything.

ExeBrowser fits into this lineage as a focused front-end: take a Windows EXE, get it running, get any files it produced back out, and require nothing on the client side beyond a modern browser tab. The Boxedwine and Wine projects do the heavy lifting; this site is the glue that makes them approachable.

Glossary

Wine

"Wine Is Not an Emulator" — an open-source re-implementation of the Windows API on top of POSIX (Linux, macOS, etc.). Wine translates Windows DLL calls into native ones. It doesn't emulate the CPU; it relies on running on x86 hardware (or, in our case, an x86 emulator). Maintained by WineHQ; large parts are upstreamed from CodeWeavers' commercial CrossOver product.

Boxedwine

A project that combines Wine with an integrated 32-bit x86 CPU emulator, so Wine can run on platforms where x86 isn't available — like ARM phones, or WebAssembly. Created and maintained primarily by James Banks (danoon2 on GitHub). Distributed under GPL-2.0.

WebAssembly (Wasm)

A portable binary instruction format designed for safe, fast execution in browsers (and increasingly outside them). Compilers like Emscripten can take C/C++ codebases and produce .wasm files that browsers execute at near-native speed.

SharedArrayBuffer

A JavaScript API that lets multiple threads share a memory region. The standard 32-bit runtime here is single-threaded and doesn't use it; only the experimental 64-bit (wine64) runtime relies on it for its thread support, which is why that runtime lives on its own cross-origin-isolated page.

COOP / COEP

Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy — HTTP response headers that, together, put a page into "cross-origin isolated" mode, unlocking SharedArrayBuffer and high-resolution timers. Only the experimental 64-bit runtime pages send them here.

Gecko (Wine Gecko)

A Wine-flavored build of Mozilla's Gecko rendering engine, used as a stand-in for Internet Explorer's MSHTML when an app embeds a browser control. Some apps and installers (notably 3D Pinball Space Cadet, older HTML-help-using installers) refuse to start until Gecko is available.

PE (Portable Executable)

The Windows executable file format. .exe, .dll, .ocx, and .sys files are all PE files. A PE starts with a small DOS stub, followed by a "PE\0\0" signature and headers describing sections, imports, and entry point.

Win16 vs Win32

Win16 is the 16-bit Windows API used by Windows 1.0 through Windows 3.11 and partially on Windows 9x. Win32 is the 32-bit API that became dominant with Windows 95 / NT 3.51 and is still the basis of desktop Windows today. ExeBrowser ships separate variants because supporting both in one build is more work than it's worth here.

BrowserFS

A JavaScript library that presents an in-memory virtual filesystem to code that expects a POSIX-style filesystem. Boxedwine uses BrowserFS to give Wine a real-looking C:\ drive that is actually just an object tree in your browser tab.

Open source & licensing

ExeBrowser is built entirely on free and open-source software. The components and their licenses:

• Boxedwine — GPL-2.0. The Wine + x86 emulator runtime.
• Wine — LGPL-2.1. The Windows API re-implementation that Boxedwine bundles.
• BrowserFS — MIT. The virtual filesystem.
• JSZip — MIT. Used to package files the running app writes, and to unpack folder/zip uploads.
• ExeBrowser glue code — GPL-2.0. The site, the variant dropdown, the upload pipeline, the writable-layer downloader. Source on GitHub.

Wine is a trademark of CodeWeavers. ExeBrowser is an independent project and is not affiliated with WineHQ, CodeWeavers, Microsoft, or the Boxedwine project.