Add a website to the Dock on a Mac so it opens like an app

The site in question gets opened twenty times a day and is never where it was left. It starts as a pinned tab, drifts along the strip, gets closed by accident during a cleanup, and comes back as the fourteenth tab in a window that also holds a half-finished form. Putting it in the Dock is the obvious fix, and on a current Mac there is a supported way to do it that produces something much closer to an application than to a bookmark.

The mechanism has a name and a birthday. Safari 17.0, shipped with macOS Sonoma, added web apps on Mac, and the entry point is a single menu command. What decides whether one of these is genuinely useful, or whether ten of them simply move the mess from the tab strip to the Dock, is a narrow technical detail about cookies that almost nobody reads before starting.

What Add to Dock actually creates

The command does not drop a bookmark that reopens the browser. It creates a web app, and the WebKit team describes the result plainly:

You can add a website, any website, to your Dock. In Safari, go to File > Add to Dock, adjust the name and icon if desired, and the web app icon appears in your Dock. Source: webkit.org

Three things in that description carry more weight than they look like they do.

The first is "any website". A web app does not require the site to have been built for it. Clicking a web app icon always opens the site in its own window, even when the site has no web app manifest and no legacy meta tags. The decision about what deserves to be an app belongs to the person using the Mac, not to the people who built the site.

The second is that the result behaves like a Mac application rather than like a browser window. Web apps work with Stage Manager, with Mission Control and with Command-Tab, and they can be opened from the Dock, from Launchpad and from Spotlight Search. That is the practical difference from a pinned tab: the thing becomes findable through every route macOS already offers for finding apps.

The third is "adjust the name and icon if desired". The name is what appears under the icon and in Command-Tab, so a page title that reads as a full sentence should be shortened at creation time. With three or four of these in the Dock, distinct icons matter more than they sound like they should, because a row of similar favicons at Dock size is genuinely hard to read.

Sites that were built with a manifest get more control over the result. A manifest can set the display mode, the name, the theme colour and the start URL, and service workers can improve behaviour further. None of that is required for the feature to work.

The cookie rule that decides whether one is enough

This is the part worth understanding before creating the second one, because it is both the best feature and the hard limit.

When a website is added to the Dock, Safari copies that website's cookies into the web app. Anyone already signed in inside Safari stays signed in inside the web app, with no second trip through a password manager or a one-time code. That copy happens once, at creation. Safari does not copy any other kind of local storage, and after the web app exists, no other website data is shared between the two.

Two consequences follow, and they pull in opposite directions.

The good one is isolation. Ordinary browser housekeeping in Safari, clearing cookies for a site that is misbehaving, does not reach into the web app. A service with a slow sign-in, a hardware key or a one-time code is genuinely worth turning into a web app for this reason alone.

The awkward one is that the copy only works when the sign-in lives in cookies. Sites that keep their authentication state somewhere else will present a sign-in screen on first launch, because that state is not part of what gets copied.

The limit that follows is the one people hit at work. The documented behaviour is a one-time copy from Safari, not a way to run two isolated copies of the same service side by side. For a personal account and a client account on the same platform, both needing to stay signed in, this is not the tool. That requires either browser profiles or a browser that gives every app its own container.

Where the command is, and what it needs

Open the page in Safari, choose File in the menu bar, then choose Add to Dock. A sheet appears with the name that will be used. Adjust it, adjust the icon if wanted, and confirm.

The version requirement is the single most common reason the menu item cannot be found. Web apps on Mac arrived with Safari 17.0 on macOS Sonoma. On an older release the command does not exist, and no amount of dragging the address bar to the Dock produces the same object, because what is being created is an app and not a file.

There is a detail about the starting point that saves an annoyance later. The web app opens whatever address was showing when it was created, so creating one from a marketing page produces an icon that opens a marketing page. Navigate to the view that is actually used, the inbox or the board rather than the front door, and create it from there.

Notifications, badges and system permissions

The reason to prefer a web app over a pinned tab, for a service that sends alerts, is that macOS starts treating it as an app for permissions too.

Web apps on Mac support web push, badging, service workers and web app manifests, along with the usual web standards WebKit implements. Badging is the specific capability behind an unread count on a Dock icon, and web push is what allows a notification to arrive when the window is closed.

Permissions follow the same route as any other Mac app. Camera, microphone and location access are granted to a web app through system prompts and through the Privacy and Security section of System Settings, in exactly the way those permissions are granted to other applications. Sign-in help works the same way: web apps use AutoFill credentials from iCloud Keychain, and from third-party password managers that have adopted the Credential Provider Extension API.

The limit here is on the site, not on macOS. A service that was never built to send push notifications will not gain a Dock badge by being turned into a web app. Messaging and ticketing services usually qualify. Dashboards and admin panels usually do not, and giving one a Dock icon in the hope of a badge that never appears is exactly how a Dock fills with icons nobody clicks.

The Dock has its own rules, and they apply here too

A web app lands in a Dock that already has behaviour worth knowing, which Apple's own Mac User Guide sets out:

Add an item to the Dock: Drag apps to the left side of (or above) the line that separates the recently used apps. Drag files and folders to the right side of (or below) the other line that separates recently used apps. An alias for the item is placed in the Dock. Source: support.apple.com

Four points from that page save time.

The Dock has separator lines, and which side of them an icon sits on is not cosmetic. Apps belong on one side, files and folders on the other, and the middle section holds up to three recently used apps that are not already pinned.

Dragging an icon out of the Dock removes only the alias. The app itself stays on the Mac, which means a web app dragged out of the Dock has not been deleted and will still appear in Spotlight. Putting a removed app back is a two-step move: open it, then Control-click its icon and choose Options, then Keep in Dock.

The layout is adjustable without third-party tools. System Settings has a Desktop and Dock section for size, position and hiding, and the separator line can be dragged directly to resize the Dock.

The Dock can be driven from the keyboard. Fn-Control-F3 moves to the Dock, the arrow keys move between icons, and Return opens one. A red badge on an icon means there is something to act on inside that app.

If Safari is not the browser in use

Chrome has its own version of this, with different wording. Google's help pages describe installing a web app from the More menu, under Cast, save, and share, then Install page as app. Some sites also show an Install button at the right-hand end of the address bar.

Uninstalling works from inside the installed app: open it, then use the More menu and choose Uninstall, with an option to delete the site's data from Chrome at the same time. The full list of installed web apps lives at chrome://apps.

The difference from Safari that matters is session handling. A Chrome web app belongs to the Chrome profile it was created in, so for anyone already running several profiles to keep work and personal accounts apart, the installed app inherits that arrangement rather than replacing it.

Where this approach runs out

A web app is an excellent answer for one or two services. The shape of the problem changes once the list gets longer.

	Pinned tab in the browser	Safari web app in the Dock	A browser built around one window per app
Own Dock icon	No	Yes	Yes
Own entry in Command-Tab	No	Yes	Yes
Unread count on the Dock icon	No	Yes, if the site supports badging	Yes
Session separate from the main browser	No	Yes, after a one-time cookie copy	Yes
Two accounts of one service, both signed in	Profile juggling	Not a documented use	Yes, one container per app
Tabs inside the window	Yes	No	Yes
All alerts collected in one place	No	No, each app notifies separately	Yes, one notification centre

The row second from the bottom is the one that decides this for most people at work. Each web app is separated from Safari, which is useful, but the documented behaviour does not extend to running two isolated copies of the same service.

The other cost arrives quietly. Ten web apps mean ten Dock icons, ten separate notification permissions and ten windows to locate individually in the switcher. The tab clutter is gone and a different kind of clutter has replaced it. Tools that group web apps into named sets exist for this stage, and the case for grouping by the work being done rather than by which login owns it is set out on the page about Workspaces. Whether the specific services in daily use are covered is a separate question, answered by the list of supported apps.

A useful discipline in the meantime is a cap. Pick a number, three or four, and treat a new web app as something that has to displace an existing one. The value of the feature comes from a handful of services being one click away, and it falls off steeply once the row of icons has to be scanned.

What to change first

Pick the single site that gets opened most often, sign into it in Safari first so the cookie copy carries the session across, then create the web app from the view actually used rather than from the home page. Live with one for a week before making a second. If the count passes three or four, or if two accounts of the same service both need to stay signed in, the next thing to look at is a browser that gives every web app its own contained window and collects their alerts in one place, which is what SpaceDeck is built for.