YouTube Music on a PC: there is no desktop app to download
Searching for a YouTube Music desktop app usually ends on a download page that offers Android and iOS, and nothing for a computer. That is not an oversight in the search results. Google's own device documentation lists mobile apps, TV connected devices, cast targets, and then a section for computers headed supported web browsers. On a Mac or a PC, the browser is the product. Everything else on offer is a way of making that browser window behave less like a tab, and the routes differ in ways that matter once music is playing all day.
What Google actually ships for a computer
The supported devices page for YouTube Premium and YouTube Music Premium is organised by device class. Mobile devices get the YouTube app and the YouTube Music app. TV connected devices get the YouTube app, with a note that the YouTube Music app is not available on living room devices. Music streaming devices covers Chromecast audio and Google Cast speakers. For computers, the instruction is to sign in at youtube.com or music.youtube.com from a Premium account in a web browser.
There is a second line on that page that changes what a desktop window can be expected to do. Offline and background play are described as available only on the YouTube, YouTube Kids and YouTube Music mobile apps. Downloads for offline listening are a phone and tablet capability. No arrangement of windows on a laptop unlocks them, because the restriction is not about the window.
That is the useful thing to establish before comparing routes. Installing the site as an application changes where it lives on the machine, not what the service allows. Anyone hoping a desktop app would give offline playback on a flight is looking for something that does not exist on the platform, and the honest answer saves an evening of searching for a third party client that promises it.
What is left to gain is real but narrower: a Dock or taskbar icon, an entry in the application switcher, a window that survives closing the browser, and separation from the fifty other tabs that a music player tends to get buried under.
The site's own manifest decides how the window looks
A detail that explains a lot of confused reports: music.youtube.com ships a web app manifest, which is what makes the Install option appear in Chrome and Edge in the first place. The manifest declares the name YouTube Music, the short name YT Music, a black background colour, and a display mode of minimal-ui.
Display mode is the part worth knowing. A site that declares standalone opens installed in a window with no browser interface at all. A site that declares minimal-ui keeps a reduced set of navigation controls at the top of the installed window. So an installed YouTube Music window is expected to show a slim bar rather than being completely chromeless, and that is the site's decision, not a failed installation or a Chrome setting waiting to be found.
This also settles a recurring argument about which browser installs it better. The manifest travels with the site, so any browser that honours it produces a similar frame. The variation between browsers is in what surrounds the window: where the icon is filed, whether it can launch at login, whether it shares cookies with normal browsing, and what happens to it when the browser profile is deleted.
A tool that builds a standalone application from a URL is not bound by the manifest in the same way, because the frame is decided locally when the bundle is made. That is the main reason the same site can end up looking different depending on how it was turned into an application.
What actually improves when the player leaves the tab strip
Since the service itself does not change, the gain has to be measured in handling, and for a music player it concentrates in three places.
The first is retrieval. A player tab is opened once in the morning and then needs to be found forty times, usually to skip a track or change a playlist. In a tab strip that has grown past the point where titles are readable, finding it is a scan. As a separate application it has a Dock icon in a fixed position and an entry in the application switcher, so it is reachable by muscle memory with the keyboard rather than by looking.
The second is accidental closure. Quitting the browser at the end of a task takes the music with it. A window that is not part of the browser survives that, and it also survives the browser reloading every tab after an update. For anything that is meant to run continuously in the background, being outside the browser's lifecycle is the whole point.
The third is window management on a second display. A separate application can be assigned to a Mission Control desktop or parked on an external monitor and stay there. A tab cannot be assigned anywhere, because it inherits whatever its window is doing.
None of these are features of YouTube Music. They are features of being an application. That is worth saying plainly, because it sets the bar for judging the routes below: the question is not which one adds capability, it is which one gives the cleanest ownership of the icon, the session and the launch behaviour.
Installing it from Chrome, and what Chrome keeps control of
Chrome documents the route as installing a web app. Open the site, then use the More menu, Cast, save, and share, then Install page as app. On some sites an Install icon appears at the right of the address bar instead. Google's help page describes web apps as accessible from the launcher or home screen, and notes that some of them add storage for offline content, notifications, file system access and icon badges.
Three follow up settings live in the same place. Typing chrome://apps into a new tab lists everything installed, and right clicking an entry there offers Create shortcut, which puts the launcher on the desktop or in the menus. The same right click menu has Launch at startup, which opens the app automatically when signing in to Windows, Mac or Linux. Uninstalling is done from inside the app window through the More menu, with an optional tick to also delete the app's data from Chrome.
Chrome's help also notes that web apps work offline in the general case, with the caveat that some will not work completely without a connection. That is a statement about the browser's capability, not about YouTube Music, and the service level rule above still applies. Reading the two together avoids a common misunderstanding: an installed window can cache its own interface, and it still cannot hand over licensed audio for offline playback on a computer.
Two ownership rules come with that convenience. The installed app belongs to the Chrome profile it was created from, so removing that profile removes the app. And Chrome watches for changes to a web app's declared name and icon: when a site tries to change either, Chrome shows an App update available prompt in the window offering to accept, ignore or uninstall, and its help page frames this as a defence against an app quietly renaming itself to resemble something else. Useful protection, and also a reminder that the label under the icon is not set by the person who installed it.
Safari and the built in route on a Mac
Safari's route is the Dock, and the isolation model is different. A site added from Safari runs in its own container rather than sharing Safari's browsing session, which is exactly what somebody wants when a personal account and a work account both need to stay signed in. It is also the route with the shortest setup, since there is nothing to install first.
The trade is version floor. Adding a site to the Dock from Safari arrived in macOS 14. Chrome's own stated minimum on Mac is macOS 13. So on a Mac that has stopped receiving major macOS updates, the built in route can be unavailable while a third party browser is still supported, which inverts the usual assumption that the system's own tool has the widest reach.
For a music player specifically, there is one more consideration that is worth testing rather than assuming. Media key behaviour, the Now Playing controls, and what happens when the window is closed while audio is playing are all browser level behaviours, and they differ between routes and between versions. Playing something, closing the window with the keyboard shortcut, and seeing whether the audio stops takes about fifteen seconds and answers a question that no comparison table can.
| Browser tab | Chrome installed app | Safari added to Dock | Purpose built bundle | |
|---|---|---|---|---|
| Own icon in the Dock | No | Yes | Yes | Yes |
| Window frame decided by | Browser | Site manifest, minimal-ui | Site manifest | The bundle |
| Session shared with normal browsing | Yes | Yes, within the profile | No | Depends on the profile chosen |
| Launch at login | No | Yes, from chrome://apps | System login items | Yes, as a normal app |
| Survives deleting the browser profile | Not applicable | No | Not applicable | Yes |
| Offline downloads | No | No | No | No |
When a purpose built bundle is the better answer
Building a standalone Mac application from the URL is worth it in three situations, and not otherwise.
The first is two accounts. A household plan and a work account, or a personal library and a shared one, cannot both stay signed in inside one window. Separate bundles hold separate sessions, so both icons sit in the Dock and neither one logs the other out.
The second is naming. An installed web app takes the name the site declares, and Chrome will prompt when the site changes it. A bundle built locally takes whatever name is typed at build time, which is what makes it findable in Spotlight by a word the reader actually thinks of.
The third is the machines the official routes leave out. A tool that builds on the Chromium browser already installed inherits that browser's update cycle, its extensions and its signed in state, rather than shipping a second engine that needs its own updating. On a Mac that cannot add sites to the Dock from Safari, that is the difference between having a route and not having one. The Supported services list shows how wide that group has become, and the Guide covers what building one involves.
What to change first
Decide whether the goal is offline listening or a clean window, because only the second one is achievable on a computer. If it is the window, install from Chrome or add to the Dock from Safari today, run it for a week, and only reach for a purpose built bundle like Kagemusha if a second account or a custom name turns out to be the actual requirement.
Frequently asked questions
Is there an official YouTube Music app for Mac or Windows?
No. Google's supported devices page lists the YouTube Music app for mobile devices and directs computer users to sign in at music.youtube.com in a web browser. The routes that produce a desktop icon all start from that browser window rather than from a downloadable installer.
Can music be downloaded for offline playback on a computer?
No. Google's documentation states that offline and background play are available only on the YouTube, YouTube Kids and YouTube Music mobile apps. Installing the site as a desktop window does not change this, because the limit belongs to the service rather than to the browser frame.
Why does the installed window still show a browser bar at the top?
Because the site's web app manifest declares a display mode of minimal-ui rather than standalone, which keeps a reduced set of navigation controls in the installed window. That is the site's own setting, so it appears the same way in any browser that follows the manifest. A locally built bundle decides its own frame instead.
Can two YouTube Music accounts be kept open at the same time?
Not in one window. The usual approaches are a second browser profile with its own installed app, a Safari web app in the Dock, which runs in its own container rather than sharing Safari's session, or two separately built application bundles. Each of those holds its own cookies, so both accounts stay signed in.