You press play expecting Spotify, and a YouTube tab you forgot about starts blasting instead. Here's what's actually happening, and every way to fix it.
The short answer: macOS sends the media keys to whichever app most recently registered itself as the system's “now playing” source — not to the app you're looking at, and not to the app you'd expect. There is no built-in setting to pin them.
The play/pause, next and previous keys on a Mac keyboard aren't wired to any particular application. When you press one, macOS decides where to deliver it, and the rule it uses is roughly “the most recent thing that played audio.”
That rule works fine when one app is playing. It falls apart the moment two things can play, which on a modern Mac is nearly always. A video in a background tab, a podcast you paused an hour ago, an autoplaying clip on a page you've already scrolled past — any of them can claim the keys, and none of them announce that they have.
Browsers make it worse, because a browser doesn't register as one source. Individual pages register, so “Safari has the keys” really means “one particular tab in one particular window has the keys,” and you may have no idea which.
If nothing is registered at all, the play key falls through to the system default and launches Apple Music — which is why pressing play on a freshly booted Mac so often opens a music library you didn't ask for.
These are worth trying first, and for some people they're enough.
Closing the offending tab or quitting the app releases its claim, and the keys fall back to whatever registered before it. This works reliably. It's also the fix you have to perform again every time it happens, which is the real problem with it.
Finding the culprit is the hard part. In Chrome and other Chromium browsers, tabs playing audio show a speaker icon you can click through. In Safari, the speaker icon in the address bar lists the tabs currently making sound.
Chromium browsers have a hidden switch for this. Open chrome://flags/#hardware-media-key-handling, set it to Disabled, and relaunch. The browser then ignores the media keys entirely, so they go to your music app instead.
This is all-or-nothing: with it disabled, the keys will no longer control video in that browser either, which is a real loss if you use the keys to pause YouTube. Safari has no equivalent setting.
In System Settings → Keyboard, turning on “Use F1, F2, etc. keys as standard function keys” means the top row sends function keys unless you hold fn. This doesn't change where a media key goes — only how you press it — but if your complaint is mostly accidental presses, it helps.
There's no macOS preference that says “send the media keys to this app.” People look for it in Keyboard settings, in Sound, in the Shortcuts app; it isn't in any of them. Choosing a target requires software that intercepts the keys before macOS routes them.
That's the gap Beamhook fills. It's a small open-source menu-bar app: you pick one target, and play/pause, next and previous go there until you change your mind. Nothing can steal them in the meantime — not a background tab, not Apple Music, not the app you happen to be looking at.
It captures the keys with an event tap before macOS gets to route them, so the “most recent player wins” rule never applies. Browsers are hooked to one specific tab rather than to the whole browser, so it's that YouTube tab that answers rather than whichever page most recently made noise. It'll take the volume keys too if you want, with ⌘ + volume still adjusting system volume.
Built-in targets include Spotify, Apple Music, Apple TV, VLC, VOX, QuickTime Player, Downcast, IINA, Amazon Music, Plexamp and Deezer, plus Safari, Chrome, Brave, Arc and Vivaldi. You can add your own with AppleScript. It needs macOS 14 or later.
Beamhook is GPL-3.0. Building it yourself costs nothing and takes one command; the €5 purchase gets you the signed, notarized, ready-to-run app and funds the work.