How to Find Hidden Bandwidth Hogs on macOS

You quit every app. You closed every browser tab. The Wi-Fi icon is the only thing on your menu bar that should be moving. And yet your router is showing a sustained 8 Mbps of upload, hour after hour. Somewhere on your Mac, something is talking — and none of the usual suspects are open. Hunting bandwidth hogs macos hides under the hood is a different kind of debugging than tracking down obvious offenders.

The visible apps in your Dock are rarely the real problem. The hidden ones are: helper processes, system daemons, background-only utilities, and login-launched agents that have no UI at all. This post walks through how to find them, name them, and decide what to do about them.

Why the worst bandwidth hogs macos surfaces are hidden

When people say a Mac has hidden bandwidth hogs, they usually mean one of four categories:

1. Helper processes — Chrome Helper, Slack Helper, etc. They have parent apps you recognize, but the traffic shows up under unfamiliar PIDs.
2. System daemons — cloudd, mediaanalysisd, nsurlsessiond, mDNSResponder, apsd. They are part of macOS and they do real work, but their names are inscrutable.
3. Background-only apps — backup agents, antivirus, RGB lighting daemons, cloud sync clients with no Dock icon.
4. LaunchAgents and LaunchDaemons — small persistent programs registered with launchd that auto-start and never appear in the Cmd+Tab switcher.

Each of these is invisible in a different way, and each requires a slightly different approach to attribute traffic correctly.

Finding helper processes and folding them under their parent

This is the most common source of confusion. Open Activity Monitor → Network and you will see something like:

Google Chrome Helper (Renderer)   45.2 MB sent
Google Chrome Helper (GPU)         0.8 MB sent
Google Chrome Helper (Plugin)      2.1 MB sent
Google Chrome Helper              18.4 MB sent
Google Chrome Helper              22.7 MB sent
Google Chrome Helper               9.0 MB sent
Google Chrome                      0.3 MB sent

Seven rows, none individually scary, totaling about 100 MB. Slack, Discord, Telegram, Teams, VS Code, Notion, and most Electron-based apps follow the same pattern.

To attribute helper traffic correctly you need to either add the rows by hand or use a tool that does it for you.

ova does this folding automatically. So do a few other tools. The point is: any per-app view that does not fold helpers will undersell how much your big Electron apps are actually using.

Decoding the most common system daemons

These are the ones you will see in any process list that includes background work. A short field guide:

cloudd

Apple's cloud daemon. Handles iCloud Drive, iCloud Photos uploads, and CloudKit traffic for any app that uses iCloud as a sync backend. Big spikes here usually mean Photos is shipping originals or a third-party app (a notes app, a bookmark sync) is reconciling.

nsurlsessiond

A system service that runs background URL sessions on behalf of other apps — especially when the Mac is on power and Wi-Fi. App Store updates, podcasts downloading in the background, and iCloud uploads can all show up here. The originating app is often hidden one layer down.

mediaanalysisd

Local media analysis (face/object recognition for Photos, scene analysis). Mostly CPU and disk, but it triggers cloudd when results need to sync to other devices. If mediaanalysisd is busy and cloudd is uploading, those two are usually working together.

softwareupdated

System update downloader. If this is busy, macOS is pulling an update — which can be 4 to 15 GB.

mDNSResponder

Bonjour / multicast DNS. Should be near zero on the WAN side. Heavy mDNSResponder traffic on the LAN usually means a misconfigured app is broadcasting too aggressively, but it should not eat your internet plan.

apsd

Apple Push Notification daemon. Maintains a persistent connection to Apple's servers for push notifications. Always-on, very low bandwidth, basically free.

bird

iCloud Drive's file provider daemon. Big spikes mean iCloud Drive is moving data.

assetsd

Photos library asset management. Often chained with cloudd and photoanalysisd.

Background-only apps you forgot about

A different class of hidden process: full applications that intentionally hide from your Dock. Common ones:

• Backup clients — Backblaze, Arq, Carbonite, iDrive
• Antivirus and EDR — Sophos, CrowdStrike, SentinelOne, Malwarebytes
• Cloud storage — Dropbox, Google Drive, OneDrive, Box, Sync.com
• Hardware utilities — Logitech G Hub, Razer Synapse, OWC software, monitor calibration tools
• Productivity utilities — Bartender, Hazel, Alfred (low traffic but they exist)
• Developer tooling — Docker Desktop, Colima, JetBrains Toolbox, Tailscale, ngrok

The first four categories are the ones that move real bandwidth. Backup and antivirus in particular can move tens of gigabytes per day if they are doing initial syncs or scanning a large drive.

How to enumerate them

Three places to look:

1. System Settings → General → Login Items & Extensions. Lists everything that auto-launches. Some run in the background without a UI.
2. Activity Monitor → All Processes (View menu). This shows the full list, not just user-facing apps.
3. Terminal: launchctl list | grep -v com.apple — shows third-party launchd jobs.

Anything in those lists you do not recognize is worth a five-minute investigation.

Pinning traffic to a hidden process

Once you have a per-app or per-process view of bandwidth, the workflow for attribution is:

1. Spot the spike. Either live (the menu bar shows 30 Mbps right now) or historical (yesterday at 2 PM, something used 5 GB).
2. Find the top process during the spike. A monitor with history makes this trivial; without one, you need to be looking at the moment it happens.
3. Look up the process name. If it is a helper, find the parent. If it is a daemon, use the table above.
4. Confirm by quitting or pausing. If pausing the suspect makes the traffic stop, you have your answer.

See ova in action

A glance-able menu bar bandwidth monitor — local, signed, ~3 MB.

Download for macOS

What to do when the culprit is a system daemon

This is the trickier case. You cannot quit cloudd or nsurlsessiond — they will just respawn, and disabling them breaks parts of macOS. The right move is to find the originating app and pause that.

A worked example: cloudd is uploading 200 Mbps for an hour after you import a phone full of 4K video. The cause is iCloud Photos pushing originals. The fix is either:

• Pause iCloud Photos sync (open Photos, scroll to the bottom, click pause)
• Switch to Low Data Mode on the current network temporarily
• Wait it out — the upload finishes once the new originals are in iCloud

For nsurlsessiond, the steps are similar: figure out which app scheduled the background session. Common originators are App Store / Mac App Store, Music (downloading purchased music), Podcasts, and third-party apps using URLSession with the background configuration.

Building a baseline

Hidden bandwidth hogs are easiest to spot when you know what "normal" looks like. After a fresh boot, while idle:

• Total throughput should be a trickle — kilobits per second, not megabits
• apsd, mDNSResponder, and a few small system processes will tick gently
• Anything sustained above 1 Mbps idle is worth investigating

Run a per-app monitor like ova for a few days during normal use and you will quickly recognize your Mac's resting heart rate. Anything outside that pattern is a candidate for the bandwidth hogs macos shortlist.

A practical hidden-hog audit

Run through this once and you will have a sharper view of your Mac than most people ever bother to develop:

1. Reboot. Wait two minutes.
2. Open ova (or your per-app monitor). Note the idle baseline — which processes have non-zero traffic?
3. Open System Settings → General → Login Items & Extensions. Cross-reference with what you saw running.
4. Activity Monitor → View → All Processes → Network tab. Sort by Bytes Sent. Identify anything you do not recognize and look it up.
5. For each unfamiliar daemon, decide: known-good (apsd, mDNSResponder, cloudd if you use iCloud) or worth investigating.
6. For each background-only app: decide if you still want it. Uninstall the ones you do not.

Most users find one or two surprises in this audit — a backup client they forgot about, a hardware utility from a peripheral they returned, a cloud sync they meant to turn off months ago.

What to do next

If you are not running a per-app bandwidth monitor at all, that is the change with the biggest payoff. Without one, the hidden hogs stay hidden — Activity Monitor's Network tab is too cumbersome to live in.

Concrete next steps:

1. Install ova or another per-app bandwidth monitor.
2. Run the audit above.
3. Bookmark this page or screenshot the daemon table — it is annoying to re-look-up nsurlsessiond every time.
4. Check back monthly. Things change; new login items get added.

Hidden processes on macOS are not malicious by default. They are doing work you (or some app) asked for. The skill of finding bandwidth hogs macos exposes is being able to see them, name them, and decide whether you still want that work happening.