Can Firefox turn a website into a Mac app

The menu item is not hidden and the setting is not buried. Desktop Firefox has no command that turns a website into a standalone application, and searching the preferences for one is time spent looking for something that was deliberately taken out. That is the short answer. The useful part is what replaced it, which of the remaining routes actually produces a window in the Dock, and whether the requirement is really Firefox or just a window.

The feature existed, then it was removed

For a period, Firefox shipped an experimental site specific browser mode. It was reachable only by creating a preference called browser.ssb.enabled in about:config and setting it to true, and it opened a site in a stripped down window without tabs or an address bar. It was never promoted to a shipping feature.

Mozilla removed it, and the reasoning is recorded in the bug that did the work.

The SSB feature has only ever been available through a hidden pref and has multiple known bugs. Additionally user research found little to no perceived user benefit to the feature and so there is no intent to continue development on it at this time. Source: bugzilla.mozilla.org

The same bug adds a fourth reason: leaving the code in place signalled that the feature was supported when it was not. The removal shipped in 2021, so on any current build, recreating the preference does nothing at all.

Firefox on Android still supports adding a page to the home screen and opening it on its own. Desktop is the platform that was dropped. That split is why the question comes up so often. Someone does it on a phone, tries the same thing on a Mac, and finds nothing.

On desktop, there is no first party route. Every option below is a workaround, and each one gives up something different.

Three workarounds, and what each one actually delivers

Separate profiles

Firefox supports multiple profiles on one machine. The page about:profiles lists them, creates new ones, and launches a chosen profile in a new window. Each profile has its own cookies, its own logins, and its own extensions, so a work account and a personal account of the same service can both stay signed in.

There are two ways to launch one. The about:profiles page can open a chosen profile in a new window directly. The other is a command line launch with the profile flag and a profile name, which can be saved as a shell script to shorten the daily version of the operation. The same page shows where each profile is stored on disk, which matters if backups are involved.

What it does not do is change the window. The tab strip and the address bar stay, the Dock still shows one Firefox icon, and Command Tab treats every window as the same application. If the goal is separating accounts, this is enough and it is the only route that is fully supported. If the goal is finding one site quickly among thirty tabs, this route does not touch that problem.

For account separation alone there is a lighter option still. An extension that gives each tab its own cookie jar keeps two accounts of one service alive inside a single window, with no second profile to maintain. It solves the login half of the problem and none of the window half, which is the same trade in a smaller package.

Kiosk mode from the command line

Firefox has a kiosk mode that opens a page full screen with the interface removed. Launching /Applications/Firefox.app/Contents/MacOS/firefox with the kiosk flag and a URL produces exactly one page and no browser furniture.

The catch is that it starts from a terminal. Turning it into something clickable means wrapping the command in a small application bundle, which the built in scripting and automation tools on macOS can do. From there, the icon, the window size, and the update behaviour are all handled by hand. For a display screen or a reception terminal this is a good fit. For a tool used all day it is more maintenance than most people want.

Kiosk mode also assumes a full screen. Sites meant to sit beside other work, a chat client pinned to the right half of the display for instance, fight that assumption rather than fitting into it. Anyone who wants a small persistent window in a specific position will spend the afternoon fighting the wrapper instead of using the site.

A community extension with a native helper

A third party extension adds installable web apps to Firefox. An extension alone cannot do this, so it pairs with a separate small program installed outside the browser, which launches Firefox against a dedicated profile to produce the standalone window.

It is the only workaround that gives a Dock icon, a custom name, and a Gecko engine at the same time. In exchange, two components have to be installed and kept working, and major browser releases can require waiting for the project to catch up. There is no official support channel when it breaks.

The install also touches more of the system than an extension normally would, because the helper lives outside the browser sandbox. That is not a reason to avoid it, but it is a reason to read what is being installed rather than clicking through, particularly on a machine managed by an employer where installing a native component may not be permitted at all.

	Separate profile	Kiosk mode	Extension plus helper
Setup	Minutes	Script and bundle it yourself	Two installs
Own Dock icon	No	Only if wrapped	Yes
Tab strip and address bar	Still there	Gone	Gone
Cookie isolation	Per profile	Depends on launch	Per app
Custom icon	No	Supply your own	Yes
Engine	Gecko	Gecko	Gecko
Maintenance	Supported feature	Yours	Follows a volunteer project

The last row of that table is the one that decides how a choice ages. A supported feature is expected to keep working through browser updates. A hand rolled script and a volunteer maintained extension carry no such expectation, and the site being wrapped is by definition one that is opened every working day. How much tolerance there is for that breaking on a Tuesday morning is the practical question, not which option looks neatest today.

Three things to check before picking a workaround

Every route here costs something, so a few minutes of checking beforehand saves repeating the setup.

The first is how the site actually gets opened. If most visits arrive from a link in an email or a chat message, those links open in the default browser regardless of what container exists, and the result is two copies of the same site open at once. Counting a single day's visits, self initiated against link driven, settles this faster than reasoning about it.

The second is whether the address bar is load bearing. Checking a URL after a download, comparing two pages side by side, opening developer tools: any of these makes a stripped window worse rather than better. Sites that are operated suit this treatment. Sites that are read and researched usually do not.

The third is extension dependence. Password manager, translation, content blocking: knowing which of these would stop the work if it vanished narrows the options immediately. If one of them is essential, routes that keep Firefox underneath stay on the list and routes that switch engines have to be checked for an equivalent first.

Decide whether Firefox is the requirement

This is the question that settles the choice, and it is usually skipped.

If the engine is the requirement, the three routes above are the whole list. Tracking protection behaviour, Firefox specific extensions, and the way certain sites render are only available inside Gecko. Some internal tools are certified against one browser and misbehave in others, which is a real constraint rather than a preference.

If Firefox is simply the browser already open every day, then the requirement is a window that behaves like an application, and the engine is incidental. That reframing opens routes that are shorter than any workaround. Safari can add a page to the Dock as a web app on recent macOS versions. Chrome can install a page as an app. A dedicated site to app tool builds an application bundle with an isolated session per app.

Splitting the two cases is what makes the decision small. Ordinary browsing stays in Firefox. The three or four sites opened at fixed times every day get their own containers somewhere else. Nothing has to be migrated, no bookmarks move, and the change is limited to a handful of URLs. Trying to solve both cases with one browser is what keeps people cycling through workaround comparisons for a week.

Which sites are worth the trouble

Every route here costs something, so narrowing the list first is the productive step. Two tests cover most cases.

The first is how the site is opened. Sites entered deliberately at set times belong in a window: a calendar, a chat client, a ticket queue, an internal dashboard, a time sheet. Sites entered from a search result and closed again do not. Documentation and reading material are fine as tabs and always will be.

The second is what losing it costs. If closing a window by accident means finding the site again and signing back in, it has earned a container. If reopening is two seconds of typing, it has not.

Most people end up with three to five sites that pass both tests. That number is maintainable under any of the routes above. Converting thirty tabs moves the hunting from the tab strip to the Dock and leaves the volume problem exactly where it was.

Adding them one at a time is also worth the patience. A site that changes a daily habit proves itself within a few days, and a site that was installed because installing was easy proves nothing at all. Doing it in one batch removes the ability to tell those two apart later, which is when the clean up turns into guesswork.

Comparing the standalone route

If the engine requirement can be dropped, a dedicated tool becomes the shortest path, and three things are worth checking before comparing feature lists. Which services a tool already ships presets for says more about its intended use than any description does, and the Supported services list answers that quickly. What a standalone app adds over a browser window, meaning isolated sessions, custom icons, remembered window sizes and per app notification control, is set out under Features. How much manual work is left to the person doing it shows up in the Guide, which is the part that usually decides whether a setup survives past the first week.

What to change first

Keep browsing in Firefox and stop trying to make it do this. Take the single site that gets lost most often, give it a container outside the browser, and judge the result after a week before converting anything else. If that site also needs a login kept separate from everyday browsing, compare the standalone options at Kagemusha rather than adding another profile.