Saving a website to the Mac desktop as an app

Dragging the address bar onto the desktop takes half a second and produces an icon, which is why most people stop there. Then the icon gets double clicked, the browser jumps to the front, the page opens as tab number thirty one, and nothing has improved. The request behind "save this website to the desktop as an app" is usually not about the desktop at all. It is about getting one site out of the tab strip and giving it a place of its own. Those are two different jobs, and on macOS they are done by two different kinds of file.

Three things get called the same name

macOS produces three different objects here and they look similar in Finder. Knowing which one you just made explains every strange behaviour that follows.

	Webloc file	Alias to an app	App bundle
How it is made	Drag the URL out of the address bar	Option and Command drag an app out of a folder	Safari Add to Dock, Chrome Install page as app, or a builder
What double clicking does	Opens a tab in the default browser	Launches the app it points at	Launches the app
Own Dock icon while running	No	Follows the app	Yes
Own Command Tab entry	No	Follows the app	Yes
Own notification settings	No	Follows the app	Yes
Survives moving the target	Nothing to move	Yes, macOS tracks the file	Yes

The first row is a bookmark. The third row is what people mean by app. The middle row is the bridge, and it is the piece most guides skip.

What the drag to the desktop actually creates

Dragging a URL out of the address bar writes a small file with a .webloc extension. It stores an address and nothing else. Double clicking hands that address to whatever browser is set as the default, and the page opens as a normal tab in whatever window happens to be frontmost.

That is genuinely useful for some things. A quarterly report, an onboarding form sent to a new hire, a page to be handed over on a USB stick. Webloc files can be renamed freely, dropped in a project folder next to the documents they relate to, and copied into a shared folder without anyone needing the same bookmarks.

One detail is worth knowing before relying on them. A webloc file carries an address and no browser preference, so it opens in whatever browser macOS currently treats as the default. Hand one to a colleague whose default is different from yours and the page may open signed into a different account, or not signed in at all. For a link that has to land in a specific browser profile, a webloc file is the wrong container.

It fails at the job people usually want. Nothing about a webloc file separates the site from the browser. There is no icon in the Dock while the page is open, no Command Tab entry, no way to give it its own notification rules, and no protection against the window drifting off to another site. If a site is being opened every morning, a webloc file just moves the click from the bookmarks bar to the desktop.

Making a real app, then putting it on the desktop

The order matters. Build the app first, then decide where the icon lives.

Safari

Since macOS Sonoma 14, Safari can save a page as a web app. Open the site, choose File then Add to Dock in the menu bar, or click the Share button and pick Add to Dock. Name it and confirm. Apple's support page is specific about where the result goes:

The web app is saved to the Applications folder of your home folder, and you can also open it from the Dock or Spotlight. Source: support.apple.com

That is the home folder's Applications folder, not the system one at the top level of the disk. Reach it in Finder with Go then Home. To get it onto the desktop, hold Option and Command while dragging the app out of that folder, which makes an alias and leaves the original where it belongs. Deleting the alias later does not delete the app, and moving the app does not break the alias.

Chrome

In current Chrome the command is Install page as app, under the three dot menu in Cast, save, and share. The similarly named Create shortcut item makes something closer to a webloc file: a launcher that opens the page as a tab. Installed apps are listed at chrome://apps, and the app that Chrome creates can be dragged from there or found through Spotlight, then aliased to the desktop the same way.

Builders

A dedicated builder produces an ordinary application bundle, so it behaves like any other app you install. It can be moved into the system Applications folder, added to the Dock, added as a login item, given a custom icon, and aliased to the desktop with no special handling. This is also the only route where the icon and the window behaviour are fully under your control rather than inherited from a browser.

The desktop is a worse home than it looks

Once the app exists, the desktop is rarely where it should live, and it is worth being blunt about why.

The desktop sits under every open window. Reaching an icon there means minimising or moving whatever is in front, which is more work than the tab you were trying to escape. Stage Manager tucks the icons away by default, and recent macOS versions let a click on the wallpaper sweep the windows aside, both of which change how reliably that icon is where you left it. Desktops also fill up. An icon that was obvious on day one is one of forty by month three.

Three alternatives beat it. The Dock keeps the icon visible and one click away no matter what is in front, and it is where a badge with an unread count can actually be seen. Spotlight opens the app by typing two or three letters of its name, which is why naming the app for the job rather than the vendor pays off. A login item opens it automatically at sign in, which suits the two or three tools that are open all day anyway.

Keep the desktop alias only when the app is tied to a project that lives in a folder there, or when someone else uses the machine and needs to be shown where things are.

There is one more reason the desktop feels right and is not. Putting an icon there is a decision that takes a second, so it gets made carelessly, and a place that collects careless decisions stops being a place you look. The Dock resists that, because space is visibly finite and adding a twelfth item makes the other eleven smaller. That friction is doing useful work. If an app is not worth displacing something already in the Dock, it was probably not worth building.

Give it an icon you can recognise

An app that looks like every other app defeats the purpose. In a Safari web app, open it, click its name in the menu bar, choose Settings, then click the icon and pick an image file. For any application bundle, select it in Finder, open Get Info from the File menu, click the small icon at the top left of the info window, and paste an image over it.

Distinct colour matters more than a pretty picture, because the Dock is scanned peripherally rather than read. Two blue icons next to each other cost more time than a slightly ugly orange one. Builders that ship ready made presets solve this by supplying a correct icon per service, and checking the Supported services list is faster than exporting artwork by hand.

The name deserves the same attention. Spotlight is the fastest way to reach any of these, and it matches on the name you gave the app, not on the site behind it. Naming an app after the job it does rather than after the vendor means two or three letters get you there. If four apps all start with the same company name, Spotlight becomes a menu to read instead of a shortcut to type.

Deciding which sites get this treatment

The test is how the site is opened, not how much it is liked. A site that gets opened first thing, by intent, and stays open, deserves an app. A site that gets opened from links inside other pages does not, because it will keep opening in the browser regardless of how many icons exist.

Two more cases justify an app. A site whose notifications are ones you would act on, since a real app gets its own line in System Settings under Notifications and a badge in the Dock. And a service where two accounts have to be signed in at once, which needs a route with its own cookie store rather than one that borrows the browser's.

Everything else is a bookmark. Ten apps in the Dock and nine of them unused is the same clutter problem in a different container, and the FAQ style questions people ask a month in are almost always about apps they built and then never opened.

When the icon stops working

Two complaints come up again and again, and both have plain causes.

The first is an icon that suddenly opens a login page, a redirect loop, or a blank window. Something on the site changed address, usually because a company moved a tool to a new subdomain. A Safari web app is repaired by opening it, choosing Settings from the menu named after the app, and typing the new address into the Application URL field, or clicking Set to Current Page after navigating there. A route with no settings panel has to be rebuilt, which is a reason to keep note of how each icon was made.

The second is an icon that no longer opens anything. For an alias, the target was deleted rather than moved, since macOS follows a move but cannot follow a deletion. For a Chrome installed app, the profile that created it was removed, renamed, or signed out, and the app went with it. For a webloc file, the default browser changed and the new one is handling the address differently.

An easy habit prevents most of this. Every couple of months, open the Applications folder in your home folder, look at what is there, and delete the ones that stopped being used. These files are small, so the cost is not disk space. The cost is that a crowded Dock and a crowded desktop stop being scannable, which was the entire point of building the icons in the first place. Anything you deleted by mistake takes two minutes to make again, which is the advantage of a route you can repeat.

What to change first

Take the one site opened every single morning, build it as a real app rather than a webloc file, and put it in the Dock instead of on the desktop. If it turns out you need a chosen icon, a second signed in account, or links that leave the window instead of drifting inside it, that is the point at which a dedicated builder such as Kagemusha is doing something the browser will not.