What Is nsurlsessiond on Mac? Its Log Names the Real Sender

The most-viewed Ask Different question about this process is How to know what nsurlsessiond is downloading. It has 148,888 views and 10 answers. The answers suggest lsof, fs_usage, Activity Monitor, nettop, and turning iCloud off. None of them reads the unified log, and the log is the place where nsurlsessiond records which app each download is for. I read everything the log still held on my Mac mini, about 23 hours. In that time it finished 26 background tasks for five different requesters, and the name in its own "client" field was the real requester for only 9 of the 26.

The rig is a headless Mac16,10 (M4) on macOS 26.4.1 (25E253), booted 2026-09-28, measured on 2026-10-17 without sudo. Nobody uses it as a desktop, so whatever nsurlsessiond does here, macOS asked for it, plus one copy of Chrome.

What nsurlsessiond is

nsurlsessiond is the macOS daemon that runs background downloads and uploads for other programs. When an app creates a URLSession with a background configuration, the transfer doesn't happen in the app's process. It is handed to nsurlsessiond, which keeps going if the app quits and gives the file back when the app next asks. Apple's guide to downloading files in the background describes the developer side. iCloud Drive, Photos, the App Store, software updates and many third-party apps all go through it. That is why it shows up in Activity Monitor's Network tab with large byte counts: it is a courier, and the traffic belongs to whoever sent it.

There are two copies, and launchd defines both:

$ ps -axo pid,user,etime,time,rss,command | grep [n]surlsessiond
  677 _nsurlsessiond 19-06:12:42  0:58.45 13072 /usr/libexec/nsurlsessiond --privileged
  872 sg-mini        19-06:12:40  1:23.11 11968 /usr/libexec/nsurlsessiond

$ plutil -p /System/Library/LaunchDaemons/com.apple.nsurlsessiond.plist
  "Label" => "com.apple.nsurlsessiond_privileged"
  "UserName" => "_nsurlsessiond"
  "ProgramArguments" => [ "/usr/libexec/nsurlsessiond", "--privileged" ]
  "EnablePressuredExit" => true

The privileged copy is a LaunchDaemon running as the _nsurlsessiond system account, not root. It serves system daemons. The second copy is a LaunchAgent in /System/Library/LaunchAgents and runs as you. It serves your apps and your per-user daemons. (The difference between the two kinds of job is covered in LaunchAgent vs LaunchDaemon.) The system account even has its own preferences daemon, which is why _nsurlsessiond appears among the 15 copies of cfprefsd on this machine.

Between them the two copies used 141.6 seconds of CPU in 19 days and 6 hours, about 7.4 seconds a day, with 12 to 13 MB resident each. For comparison, trustd used 981 minutes on the same boot. On a quiet Mac, nsurlsessiond costs almost nothing. When it is busy, the work being done belongs to the app that sent the transfer.

Who it downloaded for in one day

I saved the log for both processes with --last 24h. Retention cut it shorter: the oldest line was from 18:41 the previous evening, so the capture covers about 23 hours (see the log show command for why it has to be /usr/bin/log in zsh):

/usr/bin/log show --last 24h --predicate 'process == "nsurlsessiond"' --style compact > nsd-24h.txt

That gave 4,654 lines. The ones that matter are the task lifecycle lines (will begin, status code: 200, completed with error (null), which means it succeeded) and the network connection lines. 26 tasks completed. Every request URL is redacted as <private>, but two other fields aren't:

• for client com.apple.cloudd on task lines: the process that handed the task to nsurlsessiond.
• bundle id: com.apple.triald on connection lines: the process the network connection is attributed to.

Those are often different. Here is what the two fields said, matched up by session and time:

Time (KST)	Copy	Tasks	"client" field	Connection bundle id
every ~3 h 1 min	privileged	8	com.apple.trustd	com.apple.trustd
00:34	privileged	3	com.apple.cloudd	com.apple.triald.system
00:40–00:41	user	8	com.apple.cloudd	com.apple.triald
04:51	user	1	com.apple.geoanalyticsd	com.apple.geoanalyticsd
13:35	user	6	com.apple.cloudd	com.apple.businessservicesd

17 of the 26 tasks name cloudd, the CloudKit daemon, as the client. cloudd doesn't want those files. It fetches CloudKit assets for other daemons and passes the request on to nsurlsessiond, so the client field only gets you one step back. The connection line names the daemon cloudd was fetching for: triald (Apple's experiment and feature-rollout daemon) and businessservicesd (business names and logos shown in Messages and Maps). If you stop at the client field on a Mac with iCloud enabled, "cloudd" is the answer for most things, and that doesn't tell you much.

A few other details from the same log:

• trustd runs like a timer. Its eight tasks finished at 19:36, 22:38, 01:39, 04:40, 07:41, 10:43, 13:44 and 16:45, roughly 3 hours 1 minute 20 seconds apart. The task counter went from 147 to 154, which works out to about 8 a day over 19 days. The URL is redacted, so I can't tell you which file it fetches.
• Everything was discretionary. All three requesters' tasks logged current discretionary status ... is discretionary. A discretionary task lets the system choose when to run it based on power and network conditions, which is why big iCloud transfers tend to start when the Mac is idle and plugged in.
• The bytes were small. 18 TCP connections reported 230,102 bytes in and 32,108 out. Eleven more connections used QUIC and didn't print a byte summary, so that total is a minimum. Even allowing for that, this Mac moved kilobytes, not the gigabytes people complain about.
• A fifth of the log is bookkeeping. 938 of the 4,654 lines (20.2%) are Triggering periodic update to powerlog for client .... Most give the client as <private>. Two clients are named, each every two hours: com.apple.bird (iCloud Drive) and com.google.Chrome. Chrome has a background session registered and a staging folder dated May 15, but sent no tasks during the capture.

The staging area is ~/Library/Caches/com.apple.nsurlsessiond/Downloads. Here it has six per-client folders (amsengagementd, bird, cloudd, geoanalyticsd, parsecd and Chrome), all empty, 0 bytes in total. The geoanalyticsd folder's timestamp is 04:51, the same minute as its one task. Files are staged there during the transfer and handed back when it finishes. If this folder is large on your Mac, something has a transfer that hasn't finished yet.

How to find what nsurlsessiond is downloading on your Mac

The community answers mostly identify the culprit by switching services off one at a time. The accepted answer on "100s GB in a month" found WhatsApp re-downloading a multi-gigabyte iCloud backup that way. That works, but the log can tell you the name first. Two commands, no sudo:

# 1. Who handed tasks to nsurlsessiond (one step back)
/usr/bin/log show --last 6h --predicate 'process == "nsurlsessiond" AND eventMessage CONTAINS "for client"' \
  | grep -oE 'for client [A-Za-z0-9._-]+' | sort | uniq -c | sort -rn

# 2. Who each connection is for (the real owner when the client is cloudd)
/usr/bin/log show --last 6h --predicate 'process == "nsurlsessiond" AND eventMessage CONTAINS "bundle id:"' \
  | grep -oE 'bundle id: [A-Za-z0-9._-]+' | sort | uniq -c | sort -rn

Count connections in the second command, not lines, if you want accurate numbers: each connection logs its bundle id several times. On my machine, 59 lines came from 20 unique connections. For a transfer that's happening right now, run log stream with the same predicate, and run nettop -P next to it to see the bytes. One 2024 answer shows nettop crediting 2,628 MiB to nsurlsessiond during an Xcode update from the App Store. nettop shows the size, and the log shows who asked for it.

Once you have the owner, fix it in that app or service: iCloud Drive, Photos, the App Store's automatic updates, or the third-party app that backs up to iCloud. Killing nsurlsessiond doesn't help. launchd restarts it the next time a client calls its Mach service, and the queued tasks pick up where they left off. That is the purpose of a background session.

FAQ

What is nsurlsessiond on Mac?

nsurlsessiond is the macOS system daemon that performs background downloads and uploads for other apps and services, such as iCloud Drive, Photos, the App Store and software updates. Apps hand it a transfer through URLSession, and it keeps the transfer running even if the app quits. One copy runs as the _nsurlsessiond system account and one runs per logged-in user. It is part of macOS and is safe.

Why is nsurlsessiond using so much bandwidth?

Because some other app or service gave it a large transfer, most often an iCloud Drive or Photos sync, an App Store update, or an app that backs up to iCloud. nsurlsessiond is only the courier. The unified log records the requesting app on each task ("for client ...") and on each network connection ("bundle id: ..."), and that tells you which app to change.

Can I stop or disable nsurlsessiond?

Not usefully. If you kill it, launchd starts it again the next time an app asks, and background tasks resume. Disabling it would break iCloud sync and software downloads. Turn off or reconfigure the app or service that owns the transfer instead.

The same log-first approach works for the Photos daemons. photoanalysisd records every scheduled task it starts and how long each one took, and that turned up a daily 18.67-second Apple Intelligence run on a Mac with no photos. See what is photoanalysisd on Mac.

Measured on 2026-10-17 on one headless Mac mini (Mac16,10, M4, macOS 26.4.1 build 25E253, booted 2026-09-28), without sudo. CPU time is from ps. Task and connection counts come from one /usr/bin/log show --last 24h capture of both nsurlsessiond processes (4,654 lines; retention limited it to 2026-10-16 18:41 through 2026-10-17 17:49), matched by session ID and timestamp. Request URLs are redacted in the log, so I name requesters but not the files they fetched. Byte totals cover TCP connections only. Community figures (13 Ask Different questions with nsurlsessiond in the title, 11 answers read) come from the Stack Exchange API on 2026-10-17. Launchd details are from the two plists in /System/Library.