PWAsForFirefox: standalone web apps in Firefox without Chromium

The gap Firefox leaves open, and who fills it with this

Firefox implements many Progressive Web App APIs but, as the README states plainly, it "does not support functionality to install them as a standalone system app with an app-like experience." There is no install button, no separate window without browser chrome, and no entry in the application menu. Chromium browsers ship that path by default, which is why people who rely on PWAs tend to keep Chrome or Edge around for a handful of sites.

PWAsForFirefox closes that gap from outside the browser. It is aimed at Firefox users on desktop who want a web app to behave like a local application: its own start menu or app menu entry, its own taskbar icon, its own window, no tab strip and no address bar. The README describes the target audience implicitly rather than explicitly, but the feature list makes the intent clear: anyone who wants the app-like feel of an installed PWA without switching browsers.

It is not a Firefox fork in the distribution sense. Nothing is rebuilt from Mozilla source. The project ships a console tool and a browser extension, and the console tool produces a separate Firefox installation that it patches.

A patched runtime, a separate profile, and a native host in between

The architecture has three moving parts, visible in the top-level repository layout: a native directory, an extension directory, and a docs directory. The native part is a command-line program. The extension is the Firefox add-on that talks to it. The docs site holds the usage and limitation pages.

The mechanism the README describes is runtime modification of the browser chrome, meaning the UI layer, using JavaScript and CSS rather than compiled changes to Firefox itself. The project creates "a custom modified Firefox runtime" and keeps PWA installs in "isolated Firefox installation and profile(s) that store the PWAs." That isolation is deliberate. The README lists using the same profile for PWAs and normal browsing under not planned features, on the grounds that a shared profile could destabilise the main browser and would prevent tuning the PWA profile for app use, including installing custom addons.

Data flow is therefore split. The extension runs inside your normal Firefox and handles install, management and launch requests. The native program performs the privileged work: patching the runtime, creating and updating the isolated installation, and registering the operating system entries that make an app appear in the start menu or taskbar. Because the two halves are separate programs, the extension needs the native component present and reachable before anything can be installed.

One consequence of patching at runtime is stated openly in the README: the approach is "officially unsupported by Mozilla and can break with Firefox updates." The project compensates with automatic, user-triggered installation and patching of the installation and profile, which is listed as an available feature. That is a maintenance treadmill by design, not an accident.

Installing PWAsForFirefox and running your first web app

The README's short path is to install the browser extension from addons.mozilla.org and then follow the in-browser instructions. That is accurate but incomplete, because the extension cannot patch anything until the native program exists. The README points to the native and extension READMEs for the details, and to the documentation site at pwasforfirefox.filips.si for usage instructions.

On Linux, the project publishes DEB and RPM packages through packagecloud.io, and the README also links a Repology page tracking distribution packages. The package name used across those repositories is firefoxpwa. The README does not print an install command for either format, so the exact apt or dnf invocation is something you take from the packagecloud repository page rather than from this article. What the repository does confirm is the Repology project name, firefoxpwa, which is how distribution packages are indexed.

Once the native program is installed, check that it is on your path. The README does not print a version flag, so the reliable check is to confirm the binary exists and that the extension can reach it. Next, install the extension from addons.mozilla.org and open its settings page. The extension should report that it found the native program. The README describes the extension as able to "set up native programs, and install, manage and run PWAs and their profiles directly from the main Firefox browser", so the first-run flow is: let the extension create the isolated runtime and profile, then install a site as an app.

Once a site is installed, it appears as a separate application entry. Launching it opens a window with no tabs and no address bar, which the README lists as a deliberate feature for the app-like feel. If the extension cannot see the native program, nothing downstream will work; that handshake is the single point to debug first.

Where PWAsForFirefox breaks or is the wrong choice

The most concrete failure mode is written into the project's own not-planned list. Because the browser chrome is modified at runtime with JS and CSS, a Firefox update can break the patched UI. The README does not document a rollback path for a bad patch, and it does not promise that every Firefox release will be supported. The documentation site maintains a current limitations page, which is the authoritative place to check before upgrading Firefox.

A second boundary is profile separation. If you want your PWA logins and history shared with your main browsing profile, this tool will not do it. The README recommends Firefox Account or a third-party sync solution instead. For some people that is a dealbreaker, because it means logging into the same service twice.

On Windows, the README states that PWAs installed as APPX or MSIX packages, or from the Microsoft Store, will always use Chromium-based Edge, and that overriding this is not something the project has solved. So the Windows experience depends on how the site is packaged, not only on PWAsForFirefox.

Finally, Chromium-specific APIs are out of scope. Filesystem, Bluetooth, NFC and USB are listed as not planned, since supporting them would require forking and modifying Firefox source directly. A web app that depends on Web Bluetooth will not gain that capability here. The README also questions whether giving websites native-app privileges is wise, which is a fair position but does limit what the tool can ever deliver.

How this differs from Chrome, Edge and plain Firefox shortcuts

The obvious alternative is a Chromium browser. Chrome and Edge install PWAs natively, with no patching, no separate runtime to maintain, and no risk that a browser update breaks the install mechanism. The difference in approach is fundamental: Chromium supports installable web apps in the browser itself, while PWAsForFirefox reconstructs that behaviour from the outside by modifying Firefox's UI layer at runtime. If PWA support is the only reason you keep Chrome installed, Chrome is the lower-maintenance answer.

The other alternative is not a different browser but a different technique: a plain Firefox shortcut or a userChrome.css tweak that hides browser chrome for a specific window. That avoids a second Firefox installation entirely, but it does not give you an isolated profile, a start menu entry, or a taskbar icon, and it does not survive as a managed app. PWAsForFirefox's value is precisely the packaging around the window: isolated profile, system entry, and management through an extension.

Between those two, the trade is maintenance burden against staying inside Firefox. The project's own README is candid that the runtime-modification route is unsupported by Mozilla and would need an almost complete rewrite to be contributed upstream properly, which the maintainer says they lack the time and knowledge to do.

Maintenance, releases and the MPL-2.0 licence

The repository is not archived, and the last push was on 2026-09-19, the same day as the v2.20.0 release. The two preceding releases, v2.19.0 and v2.18.4, landed on 2026-08-16 and 2026-06-23. That cadence suggests the project is being kept in step with Firefox changes rather than left to rot, which matters given the patching approach.

The upgrade cost is real and falls on you. Each Firefox update is a potential break, and the project's answer is user-triggered re-patching of the installation and profile. Budget for checking the current limitations page after major Firefox releases. On Linux, distribution packages tracked through Repology may lag behind the upstream releases, so a packaged install can leave you on an older version than the release notes describe.

The licence is MPL-2.0, a file-level copyleft licence. Modifications to covered files must be made available under the same licence, while larger works that combine the code with other files can be licensed differently. That is a summary of the licence's structure, not legal advice; if you plan to redistribute a modified build, read the licence text in the repository's LICENSE file and, where the stakes are high, consult a lawyer.

Versioning follows SemVer, and the README directs readers to the releases page for available versions and the changelog. That is where to look before upgrading, not the README itself.

Editorial conclusion

Adopt PWAsForFirefox if you want a PWA-style workflow without leaving Firefox, accept a separate runtime that is patched at install time, and are comfortable with the project's own warning that Mozilla does not support this approach. Do not adopt it if you need a single shared profile with your main browser, Chromium-only web APIs, or Microsoft Store packaging on Windows. Before committing, verify that your Firefox version is listed as supported in the project's current limitations page, and check which package format your distribution carries.

Frequently asked questions

Official sources

1. filips123/PWAsForFirefox on GitHub
2. License: MPL-2.0
3. Project website
4. README
5. Releases