Site specific browsers on the Mac, explained

A site specific browser on a Mac is a small app that opens one website and nothing else: its own Dock icon, its own window, its own slot in Command Tab, and usually its own cookies. There are three ways to get one today. Safari can do it for free on macOS Sonoma 14 or later with File, Add to Dock. Chrome can do it for free with Install page as app. And a handful of dedicated tools do it with more control, at prices that ranged on 18 October 2026 from free to $39.99 one time to a monthly subscription. Which route fits depends on three things: whether the site needs browser extensions, whether it needs a separate login from the main browser, and what happens when a link inside it points somewhere else. This page walks through each route with the exact menu names, then compares the dedicated tools on the points that actually decide the choice.

What changes when a site becomes its own app

A site specific browser does not add anything to the website. It removes the parts of a browser that have nothing to do with that site: the address bar, the tab strip, the bookmarks, and the chance that the window is now showing something else. What it gives back is the treatment macOS reserves for applications.

That treatment is the real reason to bother. An app has a fixed position in Command Tab, so a chat or a calendar is two keystrokes away whether or not a browser is running. It shows up by name in Mission Control instead of as one of several identical browser windows. It can be assigned to a specific desktop from the Dock icon's Options menu, so it opens in the same place every day. It can be added as a login item. And it gets its own entry in System Settings, Notifications, which lets a Focus mode allow one site through while keeping the browser quiet.

The second change is the session. Most routes keep the app's cookies apart from the browser, which means signing in once more inside the app. That looks like friction at first. It is also what makes it possible to keep a work account and a personal account of the same service signed in side by side, each in its own window with its own icon.

The trade off is that a window with no tabs has to decide what to do with links that leave the site. A ticket that links to a vendor page, a chat message with an article in it, an email with a payment link. Some routes send those to the default browser. Some open a plain window inside the app. Some just load the page in place, which quietly turns the single site app back into a general browser. That one behaviour separates the routes more than any feature list.

The Safari route, step by step

Apple's support page for Safari web apps lists the requirement as macOS Sonoma 14 or later. The steps are short:

1. Open the page in Safari.
2. Choose File, Add to Dock from the menu bar, or click the Share button and choose Add to Dock.
3. Type a name and click Add.

The app is saved to the Applications folder inside the home folder, not the main Applications folder at the root of the disk. In Finder, that is Go, Home, then Applications. It also appears in the Dock and in Spotlight.

Apple states that a web app shares no browsing history, cookies, website data, or settings with Safari. So the first launch lands on a login screen. The toolbar is reduced to back, forward, Share, and any Safari extension buttons. When Safari features such as tabs or bookmarks are needed, the Share button has Open in Safari.

Settings live under the app's name in the menu bar, then Settings. The options Apple documents are:

• Application Name and Application URL, with a Set to Current Page button for the start page
• Icon, which takes any image file
• Show navigation controls, to hide or show the toolbar
• Show color in title bar, to let the title bar take the site's colour
• A Privacy tab to clear the site's data, and an Extensions tab to turn Safari extensions on or off for that app

Notifications are the one part with a catch. Apple says the unread badge on the Dock icon only works if the site's notification request is answered inside the web app, not in Safari. Once allowed, the app appears in System Settings, Notifications under its app name rather than the site address.

To remove one, drag it from the home folder's Applications folder to the Trash. Because this route is free and built in, it is the sensible first test for any single site.

The Chrome route, and how it differs

Google's help page on web apps gives the desktop path as More, then Cast, save, and share, then Install page as app. On some sites an Install icon also appears at the right of the address bar. Settings for an installed app are under More, App info, Settings inside the app window.

The behaviour is close to the opposite of Safari's. A Chrome web app runs inside the Chrome profile that installed it. It opens already signed in, autofill works, and extensions from that profile are available. That is convenient for a tool used with one account all day. It also means the app depends on the profile: two accounts of the same service need two Chrome profiles, and removing a profile removes its apps.

Google's page also notes something specific to this route. When a web app wants to change its own name or icon, Chrome shows App update available and asks whether to accept, ignore, or uninstall. Google advises uninstalling if the change looks like an attempt to resemble a different app.

	Safari, Add to Dock	Chrome, Install page as app
Requirement	macOS Sonoma 14 or later	Current Chrome
Engine	Safari's WebKit	Chromium
Cookies and login	Separate from Safari	Shared with the Chrome profile
Extensions	Safari extensions, per app	Chrome extensions from the profile
Change the start URL later	Yes, in Settings	Recreate the app
Custom icon	Any image file	Taken from the site
Cost	Free	Free

Dedicated site specific browser tools compared

Dedicated tools exist because the built in routes leave gaps: no menu bar mode, limited link control, no per app extension choice, or a dependency on a browser profile. The figures below were checked on each vendor's official page on 18 October 2026.

Tool	Engine	Free tier	Paid	Extensions
Fluid	Not stated on home page	Unlimited apps	$5 licence	Not stated on home page
Unite Pro	WebKit	1 app	From $39.99 one time	No
Coherence X6	Chrome based browsers	1 app	From $39.99 one time	Yes, Chrome extensions
WebCatalog	Not stated on pricing page	2 desktop apps	Pro $5 per month, billed annually	Not stated on pricing page

Fluid is the oldest name in this category. Its home page offers version 2.1 as a 6.3 MB download that requires Mac OS 10.12 or later, and states that it is free with unlimited apps. A $5 licence adds pinning to the menu bar, userscripts and userstyles, and full screen mode. The copyright line on the page reads 2019, which is worth weighing when planning to rely on it for years.

Unite Pro from BZG builds apps on WebKit. Its purchase page lists $39.99 for one Mac, $59.99 for three, and $99.99 for five, for the 1.x series, and requires macOS 15 or later. The first app is free.

Coherence X6, from the same developer, runs apps on Chrome based browsers already on the Mac. BZG's comparison page lists Chrome, Canary, Chromium, Ungoogled Chromium, Opera, Edge, Vivaldi, Helium, and Brave as supported engines, and puts both tools at "From $39.99". The Coherence page lists macOS 13.5 or later and offers the first app free. The same page gives typical app sizes of about 90 MB for Unite and 200 MB or more for Coherence, and states that Unite does not support third party extensions while Coherence supports Chrome extensions such as 1Password and Grammarly.

WebCatalog takes a subscription approach. Its pricing page lists a free Basic plan with 2 desktop apps, 2 profiles, and 1 space, and a Pro plan at $5 per month billed annually, plus local taxes, with unlimited apps. It also runs on Windows and Linux, which none of the others on this list claim.

How to choose between them

Three questions settle most cases, in this order.

Does the site need a browser extension? Password managers, grammar checkers, translation tools, and ad blockers are the usual ones. Safari's route supports Safari extensions per app. Chrome's route brings the profile's extensions. Among dedicated tools, BZG states that Unite does not support third party extensions, while Chromium based tools generally do. If a password manager has to fill a login every morning, this question decides the matter on its own.

Does it need a separate login from the main browser? If the goal is a second account of a service the main browser is already signed into, or a client account that must never mix with a personal one, choose a route that isolates cookies per app. Safari's route does. Chrome's route does not, unless a separate profile is created for it.

Where do outside links go? Open the app, click one link that points to a different domain, and watch. The best outcome is that it opens in the default browser or in a dedicated window. The worst is that it loads in place. Tools that sell themselves on link control, such as BZG's "link forwarding" in Unite, let rules be set per address.

Cost comes after those three, because most routes have a free way in. The Safari route costs nothing. Fluid's free tier has no app limit. Unite gives one app free. WebCatalog gives two. A one time licence is cheaper than a subscription after a year or so in nearly every case, but only matters once the free options run out.

Requirements are the last filter. Unite's current version needs macOS 15. Safari's route needs macOS 14. Fluid lists 10.12. On an older Mac that cannot update, that alone narrows the list.

A one hour test before committing

Feature tables are hard to judge in advance. A short test with the real site is not.

Pick the one site that gets lost among tabs most often. Build it with the free Safari route first, then with one dedicated tool, and run these checks on each:

1. Sign in, quit, and relaunch. Then restart the Mac and launch again. A route where the session does not survive a restart turns into daily friction.
2. Ask someone to send a message. Confirm the alert reaches Notification Center and that a badge appears on the Dock icon.
3. Click an outside link. Note where it opens.
4. Download a file. Check that it lands in the normal Downloads folder.
5. Press the shortcuts used every day. Some wrappers claim keys that the site uses, and the site loses.
6. Quit the browser entirely. For Chromium based tools, check whether the app still runs, since some rely on the installed browser.

Keep a plain text list of every app built: its name, its exact starting URL, and where the icon came from. Site specific browsers are tied to one Mac, and rebuilding seven apps on a new machine from a list takes minutes, while rebuilding them from memory takes an afternoon. The same list makes it cheap to switch tools later, which is a good property to protect.

Before choosing a dedicated tool, it also helps to scan which services it has already tested. A list of supported services shows at a glance whether the sites on a shortlist are covered, and a step by step guide shows which settings can be changed after an app is built.

What to change first

Start with Safari's Add to Dock on the one site that costs the most tab hunting, and run the six checks above for a week. If the site needs a Chrome extension or a menu bar window, move to a dedicated tool. For a Chromium based option with a free tier, Kagemusha is one to run through the same checks.