Custom icons for shortcuts: how to decide what you need

Search for how to make a shortcut icon on a Mac and four unrelated answers come back under the same heading. One says to copy an image and paste it into the Get Info window. One says to build a bundle file with a command line tool. One says to open a browser menu and pick a picture. One says to drop a URL file on the desktop. All four work. They solve different problems, and picking the wrong one costs a rebuild a few weeks later when the artwork quietly reverts.

The useful question is not which method is best. It is which of the four matches the thing you are trying to attach an icon to, and how long that icon has to stay put.

The four routes, and what each one actually attaches artwork to

Every method belongs to one of four families. The difference is where the picture ends up living, and that single fact decides almost everything else.

Pasting into Get Info attaches the artwork to an existing item as extra metadata. The item itself is untouched. The original icon is still in there, underneath. This is why a Get Info icon can vanish: nothing was changed inside the app, only wrapped around it.

Building a bundle puts the artwork inside the application itself, in the format macOS reads as an app icon. It takes more steps because several sizes have to be assembled into one file, but the picture becomes part of the thing rather than a label stuck on it.

Creating a Safari web app makes a small application in the Applications folder of the home folder. It picks up the site's own artwork at the moment it is created, and the app holds an icon setting you can change later from its own settings window.

Installing a page through a Chromium browser creates an app whose name and icon come from what the site publishes. You are borrowing the site's artwork, and the site keeps the right to change it.

A URL file on the desktop is a fifth option people reach for, but it is a document rather than an app. It will not appear in the app switcher and cannot hold a Dock position, so it drops out of this comparison early for anyone who wants a real launcher.

Who owns the artwork decides whether it stays

The most common disappointment is an icon that reverts. Sorting the routes by who controls the picture predicts this before it happens.

Route	Where artwork lives	What replaces it
Get Info paste	Metadata on the item	An app update that replaces the item
Bundle	Inside the app	Nothing, unless you rebuild
Safari web app	The app's own setting	Only a change you make
Chromium install	Published by the site	The site publishing new artwork

The last row is the one that surprises people. Chrome's help describes what happens when a site changes what it publishes, and it is worth reading before choosing this route.

When a web app wants to update its name or icon on your screen, Google Chrome notifies you about the updates. You can choose to accept the update, ignore it, or uninstall the app. Source: support.google.com

Ignoring keeps the look you have. It also means a prompt arrives every time the service rebrands. That is fine for one or two apps and tiresome across a dozen.

Safari sits in a different place. Apple's documentation on web apps is explicit that the app carries its own icon setting, and that setting is yours: open the web app, click its name in the menu bar, choose Settings, and click the icon to pick a different image. No bundle assembly, no command line, one picture file.

How long it has to survive

Ask how long the icon needs to hold before asking how to make it. The answer sorts the routes faster than any feature list.

If the target is something that updates on a schedule, a pasted icon is a recurring chore. The metadata rides along with the item, and a replaced item arrives with no metadata attached. A monthly updater means a monthly repaste. Nobody keeps that up.

If the target is something you built and control, pasting is fine and takes under a minute. Nothing is going to overwrite it.

If the target is a website you want behaving like an app, the honest comparison is between the two browser routes, and the deciding factor is whether you want the artwork pinned or delegated. Delegated means the site handles it and you never think about it again, until the day the site rebrands. Pinned means you choose once and it holds.

There is one more wrinkle worth knowing. Apple documents that a Safari web app keeps its own history, cookies, and website data, separate from Safari itself. If part of why you want a separate icon is that you are signed into the same service under two accounts, that separation is doing more work for you than the picture is.

How many you are making

Count before you start. The count changes the answer more than any preference does.

At one or two, hand work wins outright. Find a square image, open it in Preview, copy, select the item, open Get Info, click the small icon at the top of the window under the title bar, paste. Under a minute each. Building a repeatable process for two items is wasted effort.

At five or more, hand work stops being the cheap option. Each one needs a source image found, cropped square, checked at large and small sizes, and pasted. Multiply the fiddly parts and an afternoon disappears. This is the point where a route that supplies artwork automatically starts to pay, because the expensive step is not the pasting, it is the hunting for pictures.

At twenty, the question stops being about icons at all. The real problem is that twenty daily destinations are sitting in browser tabs, and the artwork is a symptom. Tools that turn sites into standalone Mac apps exist for this shape of problem, and the supported services list is a quick way to check how many of your twenty already have name, URL, and artwork registered as a set.

Where the result ends up, and how you get rid of it

A detail that rarely appears in tutorials, and that matters once a route has been chosen: each method leaves something in a different place, and removing it works differently too.

A Safari web app is saved to the Applications folder inside the home folder, not the system wide one. Apple's documentation is specific that deleting one means going to the home folder, opening Applications, and dragging the app to the Trash. Being a real app in a real folder is why it shows up in Spotlight and can hold a Dock position, and it is also why a stray experiment is easy to forget about.

A Chromium install is managed from inside the browser. Chrome's help describes uninstalling from the app's own menu, with an option to delete the site's data from the browser at the same time, and a separate page at the browser's internal apps address for managing the full set. Removing the tile from the Dock alone does not uninstall anything.

A Get Info paste leaves nothing to remove, because nothing was created. Undoing it means selecting the item, opening Get Info, clicking the small icon at the top under the title bar, and choosing Cut. The original artwork returns immediately.

This is worth knowing up front because trying two routes on the same site is a reasonable way to decide between them, and the tidy up afterwards is only obvious if you know where each one put things.

Sizes, and the one number to remember

Whatever route you pick, one number governs the source image. macOS app icons are stored as a set of sizes rather than a single picture, and the largest member of that set works out to 1024 pixels square. Anything larger gets scaled down and buys nothing.

The trap runs the other way. A favicon pulled from a browser tab is often around 32 pixels. Enlarging it to fill a Dock tile produces a soft, smeared result, because the detail was never there. Many services publish brand assets at usable sizes, and finding that page takes less time than cleaning up an upscaled favicon.

Check the small end too. At 16 pixels a logo with three words in it becomes a grey smudge. One or two characters is the practical ceiling, and thin strokes need thickening. The reliable test is to look at the icon where it renders largest, usually Finder icon view at a big size, and then where it renders smallest, and accept only artwork that survives both.

Questions to answer before you pick

Four answers decide the route, and none of them require touching a Mac.

The first is what the icon attaches to: an app that updates itself, an app you built, or a website. The second is who should own the artwork, you or the service. The third is how long it has to hold, one session or several years. The fourth is how many you are making this week.

A website you want pinned, held for years, made once, points at a route where artwork lives inside the app. A local folder you want to spot in a list points at Get Info, and takes a minute. A dozen daily web destinations point at a different conversation entirely, one about how those destinations are opened, not how they are decorated. The features overview and the guide cover what can be set per app in that case, including name and window behavior alongside the icon.

What a wrong pick costs later

The reason to spend five minutes on this decision is that the routes are not equally easy to back out of.

Backing out of a Get Info paste is free. Select, Get Info, click the small icon, Cut, and the original returns. Nothing else is affected, which is why this route is the right place to experiment when the target allows it.

Backing out of a browser install is cheap but not free. The app has to be uninstalled properly rather than dragged off the Dock, and if the service was signed into inside that app, the session goes with it. Doing this twice on the same service, once per browser, means signing in twice.

Backing out of a hand built bundle is the expensive one, because the work that went into assembling it does not come back. This is the route to choose deliberately rather than to try out.

The asymmetry suggests an order. Try the free route first if the target accepts it, move to a browser route for websites, and reserve bundle assembly for things that have already proven they are worth the time. Most lists never reach that last step, and the ones that do reach it for a small number of items rather than all of them.

What to change first

Write down every site or item you want an icon for, then put the update frequency next to each one. Anything that updates on a schedule should not get a pasted icon, because the paste will not survive. Start with the single item you open most, pick the route its row points to, and confirm it holds through one update cycle before repeating it for the rest. If the list runs long, Kagemusha is one of the tools built for handling a set of them at once rather than one at a time.