Bytetallynsurlsessiond — the courier, not the customer
Last updated: 2026-07-30
nsurlsessiond performs background transfers for other applications. When an app queues a download that should keep running after you quit it, the bytes move through nsurlsessiond rather than through the app itself. That makes it one of the few system processes that can legitimately account for gigabytes — and it also means the traffic is not really its own. To act on it, you need to know which app asked for the transfer.
What it is
nsurlsessiond is the daemon behind URLSession's background transfer mode. It is named directly after the API: NSURLSession was the Objective-C class, and this is its supporting daemon.
The design solves a specific problem. An application that wants to download a large file has two choices. It can transfer the file itself, which means the download dies the moment the user quits the app. Or it can hand the request to the system, which will carry it out independently — continuing after the app quits, resuming after a network drop, and waking the app when the result is ready. The second option is a background transfer, and nsurlsessiond is what performs it.
This is why nsurlsessiond appears in network monitoring with volumes that seem wildly out of proportion to a small system daemon. It is not downloading anything for itself. It is a courier.
Why it talks to the network
Because other software asked it to. The requests come from two broad sources.
Apple's own services are the heaviest users on most Macs. iCloud syncing, Photos, software asset fetching and Media Store downloads all schedule work through background sessions rather than holding a connection open in a foreground process.
Third-party applications use exactly the same mechanism. A podcast client downloading new episodes, a cloud storage client syncing a folder, a game fetching an asset pack — anything that should keep going while the app is closed is a candidate.
Because the transfer is attributed to nsurlsessiond rather than to the requesting app, standard per-application accounting shows the courier's name on the package. This is one of the more genuinely confusing attribution problems on macOS, and it is not a bug in whatever tool you are using.
How much traffic is normal
There is no honest single answer, because the volume is entirely determined by what other software queued.
On a quiet Mac with iCloud mostly idle, nsurlsessiond may move a few megabytes a day. On a Mac that just enabled iCloud Photos, or that runs a podcast client with a large subscription list, it can move several gigabytes in an afternoon and be behaving perfectly correctly.
The useful signal is therefore not the absolute number but whether it lines up with something you did. Enabled a sync? Subscribed to something new? Restored from a backup? Large volume is expected. Persistent large volume with no obvious cause is worth tracing, because it usually means some app has queued work that keeps failing and retrying.
Can you turn it off
No, and blocking it is the wrong lever. This is a keep process, but with an important nuance: it is one of the best candidates on the system for *throttling* rather than blocking.
Stopping the daemon does not cancel the transfers other apps have requested; it strands them. launchd restarts the service, and the queued work resumes. Blocking it at the network layer produces a similar outcome — apps whose downloads silently never complete, with no error surfaced to you.
The right controls are one level up. If iCloud is the source, adjust what syncs in System Settings. If an app is the source, adjust that app. And if you simply want the transfers to stop competing with your foreground work, limit the rate rather than the access — a background transfer that takes four hours instead of one is still doing its job, which is precisely why the app made it a background transfer.
Seeing what it actually used
nsurlsessiond is the clearest case for keeping history rather than only watching a live meter. A live view tells you it is moving 40 MB/s right now; it does not tell you that this started when you enabled a sync three days ago, or that it has quietly moved 12 GB this week.
Bytetally records per-process upload and download over time, so you can line up a spike against the day it began and work backwards to whatever queued it. And because throttling — not blocking — is the right response here, being able to cap its rate while leaving the transfer running is the control that actually fits the problem.
Related processes
Common questions
Why is nsurlsessiond using so much data?
Because it is moving that data for something else. It is the system's background transfer service, so a large number here usually means an app queued a big download or upload — iCloud content, a podcast batch, an app's own asset update — and handed it off rather than transferring it in-process.
Can I stop nsurlsessiond?
Not usefully. It is a system service that launchd restarts, and stopping it would only strand the transfers other apps have queued rather than cancel them. If you want less background transfer, the effective controls are in the apps and in the iCloud settings that are queueing work in the first place.
Is nsurlsessiond related to iCloud?
Frequently, yes, but not exclusively. iCloud services are heavy users of background transfer, so on many Macs the bulk of nsurlsessiond's volume is iCloud-related. Third-party apps use the same mechanism whenever they schedule downloads that should survive being quit.
Should I throttle nsurlsessiond?
It is a reasonable target, because by definition it carries work that is not urgent — that is why the app made it a background transfer. Slowing it down keeps those transfers running while leaving bandwidth for whatever you are doing right now, which is usually preferable to blocking it outright.
See exactly how much it used
Bytetally tracks every process on your Mac separately — upload and download, live and historical. All on-device.
Download Free on the Mac App StoremacOS 14 Sonoma or later · 100% on-device · No account