What Is nsurlsessiond on Mac? The Background Download Daemon Explained

nsurlsessiond is a system daemon that ships with macOS and is code-signed by Apple. It is the background transfer agent for NSURLSession, the standard networking API that applications on Apple platforms use to talk to servers.

The name breaks down cleanly once you know that. NSURLSession is the API, and the trailing d is the Unix convention for a daemon, a background process with no window and no dock icon. It is started by the system rather than by you, and it runs whenever there is work queued for it.

The part that matters is the word background. When a developer uses NSURLSession, they can mark a download or upload as a background transfer, which tells the system it should survive circumstances the app itself would not: the user quits the app, the app is suspended, the app crashes, or the machine is left alone. macOS honours that by handing the transfer to nsurlsessiond, which carries it out and notifies the app later, relaunching it if necessary to deliver the result. That is why a large App Store download keeps progressing after you close the App Store window, and why a podcast episode finishes arriving even though you never reopened the podcast app.

You will often see nsurlstoraged listed nearby. It is a closely related Apple daemon that handles storage for URL session data such as cached responses and cookies, and it is equally normal. It typically shows far less network activity, since its job sits on the storage side rather than the wire.

This is the single most important thing to understand about nsurlsessiond, and it is the reason so many people end up suspicious of it. The traffic attributed to nsurlsessiond usually belongs to some other app. It is a shared courier, carrying packages for anyone who asks, and the packages are not addressed to it.

When Photos uploads a batch of images to iCloud, the bytes travel through nsurlsessiond. When the App Store pulls down a multi-gigabyte update, the same. When a third-party client syncs files or pre-caches media, very often the same again. All of that traffic is opened by one process, attributed to one process, and shows up under one name.

Activity Monitor, and any tool that identifies traffic purely by the process owning the socket, has no way to unpick that. It reports what is true at the operating system level: the connections belong to nsurlsessiond. What it cannot show is the requesting app behind each transfer, because that relationship lives a layer above the socket. The result is a single row that looks like one process consuming enormous bandwidth, when it is really several apps' worth of work under one label.

So a large share of nsurlsessiond alarms are misattribution, not misbehaviour. If you are wondering why an Apple daemon would need forty gigabytes of downloads, the answer is that it did not. Something on your Mac asked for them.

This also explains why the daemon appears to run constantly. It is not holding a permanent connection of its own. It wakes when a transfer is queued, does the work, and goes quiet, and on a machine syncing photos, documents, mail attachments and app updates, there is nearly always something queued.

nsurlsessiond is not malware. It is a first-party component of macOS, present on every current Mac, and it does not need to be removed, disabled, or cleaned up by any utility.

The reasonable caution behind the question is that malware sometimes adopts names resembling system processes, hoping a quick glance at a process list will let it pass. Two checks in Terminal defeat that, and they are worth knowing for any process, not just this one.

The first check is location. Ask the system where the running binary lives using the pgrep command with the -lf flags and nsurlsessiond as the pattern. The genuine daemon lives inside a system framework path, deep in the CFNetwork framework. Anything claiming that name from your Downloads folder, your home directory, or an unfamiliar application bundle is not the Apple daemon.

The second check is the code signature, and it is the stronger of the two, because a path can be imitated while a valid Apple signature cannot. Run codesign with the -dv and verbose flags against the binary path you found. The genuine daemon reports an authority chain belonging to Apple, naming Software Signing and the Apple Code Signing Certification Authority. An unsigned binary, or one signed by an unknown developer, would justify concern.

If both checks pass, the process is what it claims to be, and any surprise about its behaviour is a question about the apps queueing work through it.

Because nsurlsessiond only ever works on behalf of something else, unusual activity from it is a symptom, and the useful diagnosis is upstream. A small set of causes accounts for the large majority of cases.

The most common is iCloud. A freshly enabled iCloud Photos library, a restored Mac, or a large batch of new imports produces sustained traffic that can run for hours or days depending on library size and connection speed. iCloud Drive behaves the same way after a big folder change. Next comes the App Store, including large app updates and system updates staged in the background. Third is media apps pre-caching content, such as podcast clients pulling several episodes ahead.

An ordered way to check, from cheapest to most involved. Start with the foreground candidates: open the App Store updates view and System Settings to see whether an update is downloading. Then open Photos and read the status line at the bottom of the Library view, which reports sync progress and item counts, and check iCloud Drive in Finder for pending items. Next consider anything installed or reconfigured recently, since a newly added sync client is a frequent trigger. Finally, let it run, because transfers with a defined end do finish.

High CPU usually tracks the same causes, since sustained transfers mean continuous work rather than idle waiting. Persistent high CPU with no meaningful throughput is less typical, and it often clears with a restart, which resets the daemon and its queue with no lasting effect.

What is worth avoiding is blocking it. You can deny nsurlsessiond network access with a firewall, and the result is that background transfers across the entire system stop working, usually with no error to explain it. Downloads never complete, iCloud-related syncing stalls, and apps that expect their transfers to have finished find that they have not. Because the failure is silent and system-wide, it is a poor trade. The right lever is the app queueing the work, not the courier carrying it.

That leaves the question the built-in tools cannot answer: which application actually asked for all this. Activity Monitor stops at the process boundary, so the row says nsurlsessiond and the trail ends there.

A sharper approach is to stop relying on process names and look at destinations instead. The connections still go somewhere, and those endpoints identify the service behind a transfer even when the process name does not. Apple content delivery and iCloud endpoints look distinctly different from a third-party sync service or a media CDN, and once you can see the domains, attribution stops being guesswork.

This is the gap NetMute is built around. It shows real-time per-app and per-process traffic rather than a single aggregate figure, and pairs it with domain-level logging so you can see which endpoints a transfer is reaching. That turns an anonymous row into a clear picture: this much going to iCloud, this much to an app you installed last week.

Once you know the source, NetMute gives you proportionate ways to act on it, aimed at the responsible app rather than the system daemon. You can block an app's network access with one click, or use a self-expiring temporary rule when you only want quiet for the next hour. A per-app data limit blocks automatically at the cap, which suits an app that behaves well until it decides to pre-cache a season of something. Network profiles let those rules change with context, so a laptop on a metered hotspot enforces limits it does not need at home.

None of that requires touching nsurlsessiond. The daemon keeps doing its job, background downloads and iCloud transfers keep completing, and the app generating the traffic is the one that gets constrained.