Slack in the browser: the setup order that holds up
Most people who look up Slack in the browser are already using it. The browser opens, the workspace loads, messages send. What breaks is everything around the messages: a mention that never produced a notification, a keyboard shortcut that closed the tab instead of opening threads, a workspace that went quiet because its tab got closed three days ago. None of that is a bug. It is the browser version behaving exactly as documented, in an order nobody set up deliberately.
The setup has four decisions and they are not interchangeable. Each one constrains the next. Doing them out of order is why the browser route feels unreliable to people who are, technically, using it correctly.
The browser version is a different runtime, not a reduced Slack
The desktop application is a packaged browser engine that Slack controls. It decides when to update, it holds every signed-in workspace open at once, and it owns the keyboard while its window is focused. The browser version hands all three of those responsibilities to software Slack does not control.
That single difference explains almost every complaint about the web route. Update timing belongs to the browser vendor, so Slack publishes a floor and a cut-off date instead. Connection lifetime belongs to the tab, so a closed tab is a disconnected workspace. The keyboard belongs to the browser first, so the browser claims its own shortcuts before Slack ever sees the keystroke.
Nothing here is a limitation that gets fixed in a future release. It is the shape of running inside someone else's window. Once that is clear, the four setup decisions stop looking like preferences and start looking like consequences.
Decision one: the browser, chosen before anything else
Slack publishes a minimum version for each supported browser, and the list is short.
| Browser | Minimum version |
|---|---|
| Chrome | 137 or above |
| Firefox | 139 or above |
| Safari | 26 or above |
| Microsoft Edge | 136 or above |
The version floor is the easy part, because auto-update usually handles it. The part that decides the whole setup sits in a one line note on the same page: Google Chrome and Firefox are the only browsers that support huddles.
Note: Google Chrome and Firefox are the only browsers that support huddles. Source: slack.com
Messaging, search, files, threads and canvases behave the same everywhere. Voice does not. On a team where huddles happen several times a day, that note removes Safari and Edge from consideration before any other question gets asked, and it removes them permanently rather than until some future update.
This is why the browser is decision one. Choosing Safari because it is already open, then discovering three weeks later that huddles need Chrome, means redoing the sign-in, the notification permissions and the tab arrangement in a second browser. Teams that never touch huddles have a genuinely free choice here. Teams that do have two options.
Decision two: where the session is going to live
Signing in to the browser version starts at slack.com/signin with an email address and a confirmation code, or by continuing with an Apple or Google account. Where two-factor authentication is enforced on the workspace or organisation, a six digit code is added to that flow.
The part worth deciding on purpose is which browser profile receives the session. Slack does not store the signed-in state. The browser profile does. A work workspace signed in to a personal profile stays there, sharing cookies and extensions with everything else in that profile, and shows up on every device that profile syncs to.
Adding more workspaces works the same way it does in the desktop application. Click the workspace icon in the sidebar, choose to add a workspace, then sign in to the other one. The switcher appears in the browser exactly as it does in the app.
Being able to switch is not the same as being connected, and that distinction is where most browser setups quietly fail. The desktop application keeps every signed-in workspace live at once. The browser keeps live whatever is open in a tab. A person with three workspaces and one tab has one connected workspace and two that are merely reachable.
Decision three: notifications, which pass through three separate gates
Slack states the tab rule plainly in its notification troubleshooting article.
Note: You'll only get notifications for workspaces that you have open in your browser. Source: slack.com
So the first gate is structural rather than a setting: a workspace that needs to notify needs a tab, open, for as long as notifications are wanted. Closing the tab at the end of a task closes the connection with it. The practical answer is to keep one pinned tab per workspace that genuinely needs to reach you, and to accept that the others are places you visit rather than places that call.
The second gate is the browser's own permission, and it lives somewhere different in each one.
- Chrome: Settings, then Privacy and security, then Site settings, then Notifications under Permissions
- Microsoft Edge: Cookies and site permissions, then Notifications under All permissions
- Firefox: Privacy and security, then the Settings button next to Notifications under Permissions
- Safari: Settings, then Websites, then Notifications in the sidebar
The third gate is macOS. The browser itself has to be allowed to post notifications in System Settings, and a Focus mode will suppress them regardless of what Slack and the browser agree on. A banner only appears when all three gates are open at the same time, which is why browser notifications fail silently so often. Nothing reports which gate is closed.
One consequence is worth stating directly. Notification reliability in the browser is a property of how the tabs are arranged, not a property of Slack's settings. No amount of adjusting notification preferences fixes a workspace whose tab is closed.
Decision four: rebuilding the shortcuts, because some are gone
Slack's keyboard shortcut reference marks certain entries with a double asterisk and explains what the mark means: shortcuts marked with a double asterisk only work on the Slack desktop app. That turns a vague feeling into a specific list.
| Action | Shortcut | In the browser |
|---|---|---|
| Open your preferences | ⌘ , | Not available |
| Upload a file | ⌘ O | Not available |
| Quit Slack | ⌘ Q | Not available |
| Open the threads view | ⌘ Shift T | Not available |
| Browse channels | ⌘ Shift L | Not available |
| Open the activity view | ⌘ Shift M | Not available |
| Jump to the latest unread message | ⌘ J | Not available |
Two different things are happening in that table. Some of those shortcuts address desktop-only surfaces. Others collide with the browser, which sees the keystroke first and acts on it. The collisions are the ones that cause visible damage: ⌘ W closes the tab and the workspace connection with it, ⌘ Q quits the entire browser including every other tab, and ⌘ Shift T reopens the last closed tab in Chrome rather than opening the threads view.
Slack also states that custom keyboard shortcuts cannot currently be configured, so remapping around the collisions is not an option. The remaining approach is to rebuild habits on the shortcuts that survive. Shift Esc still marks everything read. ⌘ K still opens the quick switcher. ⌘ F still searches the current conversation.
People who never used ⌘ O or ⌘ , will not notice any of this. People who did will feel the browser version as slower without being able to say why, because the loss is a handful of keystrokes repeated a few dozen times a day.
The dates that decide how long the setup lasts
Slack updates its system requirements twice a year, in May and November, and supports a given browser release for 12 to 18 months. The published end of support schedule already names specific versions: Chrome 142 and below and Firefox 144 and below on 9 November 2026, Edge 142 and below on the same date, and Safari 18 and below on 18 May 2026.
What happens at the cut-off is stricter than most people expect. Slack states that an unsupported browser is blocked from using Slack in the browser, from signing in, from creating new workspaces, and from managing workspace or Enterprise Grid settings. It is not a degraded experience. It is a locked door, and the key is a browser update.
On a Mac that auto-updates its browser, this never surfaces. On a managed Mac where updates are pinned by an administrator, or on hardware too old to run the current browser release, it surfaces all at once on a specific morning.
The related date runs the other way. The desktop application requires macOS 13 or above and app version 4.44 or above, and macOS 13 and below reaches end of support on 9 November 2026. For anyone staying on older hardware, the browser is not the convenient alternative to installing an app. It becomes the only route that keeps receiving updates, which makes the browser's own floor the constraint that matters most.
When a correctly configured tab is still the wrong container
Work through all four decisions and the browser version becomes reliable. It does not become findable. A pinned tab that is connected, permitted and notifying is still a favicon in a row of twenty favicons, still reachable only by a browser window that also holds documentation, a ticket queue and whatever was opened to check one thing an hour ago.
Three questions separate a tab that is fine from a tab that should be a window.
- How many times a day does finding it require looking? Searching a tab strip is a cost paid per visit, and it scales with how often the tool is opened.
- Does it need to notify? A workspace that must notify is a tab that can never be closed, which means it permanently occupies space in a container designed for temporary things.
- Has the keyboard already caused damage? Anyone who has closed the workspace with ⌘ W while reaching for something else has an answer.
Where all three point the same way, the fix is a separate window rather than a better tab. A site to app tool builds a standalone macOS application around a single URL: its own Dock icon, its own entry in the application switcher, its own window that no other page can appear in. The engine underneath is the browser already installed, so the sign-in state and the notification permission carry over rather than being set up again. What such a window can and cannot control is listed under Features, and the build steps are shown with screenshots in the Guide.
This is worth doing when the desktop application is not an option, which covers Macs below the macOS floor, machines where installing applications is restricted by policy, and setups where several workspaces or several accounts need to sit in separate windows at once. Where the desktop application installs cleanly and one workspace is enough, it already solves the same problem.
What to change first
Pick the browser before anything else, because huddles narrow the choice to Chrome or Firefox and everything downstream gets rebuilt if that decision changes later. Then check that the browser is set to update itself, since the published cut-off dates block sign-in rather than degrading it. If the tab still has to be hunted for after that, give it a Dock icon of its own with Kagemusha.
Frequently asked questions
Is anything actually missing from Slack in a browser?
Messages, search, threads, files and canvases work the same as in the desktop application. Huddles are the real gap, and only in Safari and Edge, since Slack lists Chrome and Firefox as the only browsers that support them. The other gap is a defined set of keyboard shortcuts that Slack marks as desktop-only, including opening preferences and uploading a file.
Why do browser notifications arrive for one workspace but not another?
Because Slack only sends notifications for workspaces open in the browser. A workspace whose tab was closed stops notifying immediately, even though the account is still signed in and switching to it still works. Keeping one pinned tab per workspace that needs to reach you is the only arrangement that behaves consistently.
Will an old browser keep working with Slack?
Not indefinitely. The current floors are Chrome 137, Firefox 139, Safari 26 and Edge 136, and Slack raises them twice a year in May and November. Past the cut-off the browser is blocked from using Slack and from signing in, so a browser with automatic updates disabled is worth checking before it becomes urgent.
Can the browser version be opened from the Dock like an app?
Yes, using a tool that turns a website into a standalone Mac app. It wraps the Slack URL in its own window with a Dock icon and its own slot in the application switcher, while running on the browser already installed, so the session and notification permission carry across. On a Mac that meets the macOS 13 requirement, installing the desktop application achieves the same result more directly.