Why Slack Uses So Much Bandwidth on Mac (And How to See It)

You glance at your menu bar and Slack is pulling 2 MB/s while you're not even typing. Activity Monitor shows four different "Slack Helper" entries with different totals, none of which add up to what you see in your network monitor. If you've ever wondered why Slack bandwidth usage feels disproportionate to the work it's doing, the answer is in its architecture — Electron, websockets, helper processes, and a default A/V stack that's heavier than people realize.

This isn't a Slack hit piece. Slack is genuinely useful and the way it uses the network mostly makes sense. But the per-process numbers can be confusing on macOS, and a few settings are worth knowing about.

Why Slack bandwidth usage runs high (the architectural answer)

Slack on Mac is an Electron app. That means it bundles Chromium under the hood, and like Chrome it splits work across multiple processes:

• Slack — main process, UI, coordination.
• Slack Helper — utility renderers and background work.
• Slack Helper (GPU) — GPU process for compositing.
• Slack Helper (Renderer) — one or more renderer processes for the UI.
• Slack Helper (Plugin) — plugin host (rare in current versions).

Each helper has its own PID. Each can have its own network sockets. When you ask "how much bandwidth is Slack using on Mac", you have to sum across the parent and all the helpers — or use a tool that folds them for you.

What's actually on the wire

A few categories of traffic, roughly in order of how much they contribute:

1. The websocket

Slack keeps a persistent websocket open to Slack's servers. This carries presence updates, new messages, typing indicators, reactions, file upload notifications, channel state changes, and pings. Idle, the websocket is small — a few KB/s — but each event you'd expect to feel "instant" in the UI is one or more frames over this connection.

If you have many busy channels, the websocket alone can sit at 50-150 KB/s during business hours.

2. HTTP fetches

UI loads, avatar images, channel history, search results, link previews, emoji. These are short bursts — opening a channel for the first time today fetches several MB; opening it the second time hits cache.

3. File transfers

Drag a 30 MB image into a channel and you'll see a clean spike on your uplink. Slack uploads to its file storage, then pings the websocket to tell the channel about the file. Your client, in turn, downloads previews of files others share. A team that shares lots of design files can move hundreds of MB a day just on previews.

4. Audio and video calls

This is the big one. A Slack huddle (audio only) is a few hundred Kbps per direction. Video huddles are several Mbps. Screen share on top of video can push 5+ Mbps. Multiply by the number of participants whose video you're decoding.

5. Background updates and analytics

The Slack auto-updater runs in the background and pulls new versions periodically. Plus telemetry — feature usage, crash reports — measured in KB/day, mostly negligible.

Real numbers from a typical day

Numbers from a single Mac running Slack with about 25 channels, three or four active during the day, two huddles totaling 45 minutes:

• Idle (app open, not interacting): 5-30 KB/s in steady state. Higher with several busy channels.
• Typing into a busy channel: brief spikes to 50-100 KB/s as presence and read receipts flow.
• Opening a channel cold: 1-5 MB depending on history depth and avatar count.
• 45 minutes of huddle (1:1, video on): ~600-900 MB total.
• A typical full work day, no huddles, moderate activity: 100-300 MB.
• A day with two video huddles: 1-2 GB easily.

These are ballparks. Your team's emoji habits matter more than you'd think.

How to actually see it on your Mac

Three options, increasing in usefulness:

Activity Monitor

Open Activity Monitor → Network tab. Sort by "Sent Bytes" or "Rcvd Bytes". You'll see the parent and helpers as separate rows, with cumulative totals since process start. Useful as a sanity check, less useful for "what is Slack doing right now".

nettop

In Terminal:

nettop -P -m route

Live updating per-process view. Same problem — Slack and its helpers appear as separate rows.

A menu bar monitor with helper folding

ova is built around this exact pattern. It shows a single "Slack" row with the combined rate across all helpers, a sparkline of recent activity, and a scrubable timeline so you can see when the spike happened. Click into "Slack" and you can drill down to per-helper detail if you want it.

See what Slack actually uses

ova folds Slack Helper PIDs under the parent app and shows live + historical per-app bandwidth. Local, signed, ~3 MB.

Download for macOS

Reducing Slack bandwidth usage — the settings that actually matter

Most "save bandwidth in Slack" advice is recycled and wrong. Here's what actually works:

1. Animate emoji: off

Slack → Preferences → Animation & Image Previews → Animate emoji as I scroll. Off. Reduces both bandwidth (animated GIFs are large) and CPU.

2. Display media inline: as needed

Same preferences pane. Setting "show images and files" to manual means you click to expand, which avoids auto-download of every shared image. Trade-off is a slightly less rich UI; for a bandwidth-constrained connection, easy win.

3. Voice and video defaults

In a huddle, you can:

• Turn off your video — drops your upload by ~80% for that segment.
• Hide other participants' video (gallery → speaker view) — reduces decoding load.
• Lower video quality if Slack exposes it.

For long meetings on a hotspot, video off is the right default.

4. Quit Slack when you don't need it

Sounds obvious. Slack has a hard time closing its websocket when minimized — closing the window doesn't quit the app on macOS. Cmd-Q does. If you're on a metered connection and don't need real-time messaging, quit it.

5. Limit which workspaces auto-launch

Each workspace runs roughly one set of helpers and one websocket. Three workspaces means three of everything. Removing a workspace you don't actively use removes its bandwidth share.

Why the numbers don't match between tools

A frequent confusion: Activity Monitor says Slack used 240 MB today, your menu bar monitor says 380 MB, nettop shows yet another number. Reasons:

• Different measurement windows. Activity Monitor counts since process start. A menu bar monitor might count today, this week, or rolling.
• Helper inclusion. If the parent process row in one tool excludes helpers, you'll see less than a tool that folds them.
• Sampling vs. total counters. nettop polls; Activity Monitor reads kernel counters; a good monitor does the same. The numbers should agree closely if measured over the same window with the same scope.

The fix is to pick one tool and use it consistently for comparisons. ova's per-app row is one number — combined across all Slack helpers, over a window you choose — which makes apples-to-apples comparison easier.

Slack on a hotspot or capped connection

If you tether to your phone or work from a place with a data cap, Slack adds up fast. Practical rules:

1. No video huddles on cellular. Audio-only huddles are tolerable. Video isn't.
2. Auto-download of media: off. Saves you from someone sharing a 200 MB design file in a channel you skim.
3. Don't open old channels. Cold opens fetch history. If you don't need to scroll, don't.
4. Quit Slack between focused sessions. Instead of leaving it running for "presence", rely on email or DMs and check Slack at the start and end of your block.
5. Use the web client briefly. The browser version, in a single tab, can be lighter than the Electron app — fewer helpers, no auto-update background work.

Comparing Slack to alternatives

Bandwidth-wise, the rough order:

• iMessage / Mail — push-based, near-zero idle.
• Telegram, WhatsApp — small idle footprint, modest message traffic.
• Discord — Electron, similar architecture to Slack, similar idle profile.
• Microsoft Teams — heavier than Slack at idle, similar in calls.
• Slack — moderate-heavy at idle, heavy in calls.
• Zoom — light at idle, heavy in calls (see notes elsewhere).

This isn't a recommendation to switch — Slack's bandwidth profile is reasonable for what it does. But if you've been blaming "the network" and it's actually a 4 GB-a-day messaging client, that's worth knowing.

Wrapping up

Slack bandwidth usage on Mac is high because it's an Electron app with a persistent websocket, multiple helper processes, and a feature set that includes inline media and video calls. Most of what you see is normal. Some of it is configurable. All of it is easier to reason about when your monitor folds the helpers under one "Slack" row.

Run ova for a day, watch Slack's contribution to your total, and decide whether the cost matches the value you get. For most people, Slack is worth it; for people on metered connections, a few setting tweaks save a lot.