Website to EXE — turn any URL into a Windows app

How a URL becomes a Windows .exe

Your site is not rewritten and not copied. The build produces a small native Windows program that opens your URL in WebView2 — the Edge rendering engine already installed on every supported version of Windows — in a frameless window carrying your name, your icon and no address bar. Because your code stays on your server, anything you deploy to the site shows up in the installed app the next time it opens. No second release, no asking users to reinstall.

From URL to .exe in four steps

1. 1. Paste your web address

   Any HTTPS site works — Lovable, Bubble, Webflow, Framer, Softr, or something you wrote yourself. Unlike the Android route, you need no manifest and no service worker: a plain website is enough.

2. 2. Name the window

   App name, icon, and the size the window opens at. That name is what appears in the title bar, the Start menu and Add or remove programs, so it is worth settling before you build.

3. 3. Build

   One click starts a cloud build on a real Windows runner. It compiles the native shell, embeds your icon and packages everything into an .msi. A few minutes, and nothing installed on your own machine — you never need a Windows PC to produce a Windows app.

4. 4. Download and distribute

   The installer lands on GitHub Releases behind a signed download link. Put it behind a Download for Windows button on your site, email it to your customers, or submit it to the Microsoft Store.

.exe, .msi and .msix: which file do you actually need?

This is where most of the confusion lives. People look for a website to .exe converter and expect one file to appear. What they usually want is an installer — and Windows has three formats that do different jobs.

"Windows protected your PC" — the SmartScreen warning, explained

The first time someone runs a freshly built installer, Windows will probably show a blue panel saying it protected their PC and that the publisher is unknown. It is the most under-documented part of turning a website into an .exe, and no converter makes it disappear on its own. Here is what is actually happening.

• It is a reputation check, not a virus check

  SmartScreen compares the file against downloads Microsoft has seen before. A brand-new installer nobody has downloaded yet has no reputation, so it gets flagged — even when it is perfectly clean.

• Your users can still install it

  The way through is More info, then Run anyway. Say so plainly on your download page, with a screenshot: a user who was not warned assumes something is broken and leaves.

• Downloads build the reputation back

  Reputation accrues with volume. An unsigned installer that a few hundred people install will eventually stop being flagged — but you have no control over when.

• A code signing certificate removes it properly

  Signing attaches a verified organisation identity to the file. With an EV certificate the warning goes immediately; with an OV certificate it clears once modest reputation is built.

Code signing: what it fixes, and what it costs

A certificate is not a formality you can skip forever if you sell the app — and it is the part nobody prices honestly. So: an organisation-validated (OV) certificate runs roughly 150–400 € a year from a traditional certificate authority, or about 10–15 € a month through Azure Trusted Signing, which keeps the key in the cloud rather than on a USB token. An extended-validation (EV) certificate costs more and is the only one that clears SmartScreen on day one. Either way the issuer verifies that your company exists — expect a DUNS number or equivalent business registration, and a few days of back-and-forth.

Why the installer weighs a few megabytes, not 150

An Electron app ships its own copy of Chromium and Node.js, which is why a hello-world weighs more than a video game from 2005. SaasToStore uses the webview Windows already has, so there is nothing to bundle.

macOS and Linux come out of the same URL

The same build also produces a macOS .dmg and a Linux .AppImage, so one web address covers every desktop. macOS has its own version of the unknown-publisher problem: Gatekeeper refuses an app from an unidentified developer until the user right-clicks it and chooses Open, or approves it once under Privacy & Security. Clearing it properly takes an Apple Developer ID certificate and notarisation — Apple scans the app and staples the verdict to the .dmg. Same idea as Windows signing, different vocabulary, and also on the roadmap rather than live.

What you get

When a .exe is the wrong answer

• Your app has to work with no connection

  The window loads your live site. If you need a genuinely offline product, give the site a service worker with an offline cache first — the wrapper then inherits it. A wrapper alone does not make a web app work offline.

• You need deep operating system access

  Crawling the filesystem, talking to USB devices, kernel drivers or background services are outside what a webview reaches. That is a native application, not a wrapped site.

• Your users are mostly on phones

  Then Windows is not the first stop. The same URL also builds a signed Android app and an iOS app, and the LAUNCH plan covers all of them together rather than one at a time.

PWA to EXE: what changes when your site is already a PWA

Any HTTPS site builds. But if yours is a PWA, three things come for free. The window takes its name and its icon from your manifest instead of you typing them in. Your service worker keeps caching inside the desktop app, so it survives a dropped connection exactly as it does in the browser tab — which is the one way a wrapped app becomes genuinely usable offline. And your theme color sets the window chrome. A plain website produces the same installer; it simply starts from nothing, and you set those three by hand.