What is com.apple.WebKit.Networking on Mac?

Last updated: 2026-08-05

What it is

com.apple.WebKit.Networking is the network helper in WebKit’s modern multi-process architecture. It performs web resource requests for Safari and for other apps that display web content through WKWebView. It also manages the caches and website storage associated with those requests. Although it handles browser-related work, it is not a standalone browser.

The process is not exclusive to Safari. Mail, the App Store, and many other first-party and third-party apps can use WebKit to embed web content. Some macOS or Safari versions may show a friendlier host-related label such as “Safari Networking,” but the verified bundle and executable name is com.apple.WebKit.Networking.

It is also not a single shared service with exactly one instance for the entire Mac. Multiple WebContent processes in the same browsing session can share one network process. Different apps or separate sessions may create multiple processes with the same name. Seeing several instances therefore does not, by itself, identify a problem or tell you which app owns every connection.

Why it talks to the network

com.apple.WebKit.Networking connects when its host app opens, refreshes, or preloads a remote page. A page can require HTML, scripts, style sheets, images, fonts, and media. Requests started by page scripts, long-lived connections, streaming activity, and downloads can also pass through this process.

The destinations depend on the host app and the page being displayed. Connections may go to the current website, a content delivery network, an API called by the site, a media server, or a server supplying a third-party embedded resource. There is no fixed list of domains that applies to every instance because the page content determines much of the work.

Traffic can continue when Safari is not the frontmost app. A background page may still be active, a host app may preload content, or a page feature may keep a connection open. Conversely, the process may be running without transferring anything externally when the content is local or the required resources are already available from cache. Its presence and its current network activity are therefore two different questions.

How much traffic is normal

Apple and WebKit do not publish a single normal traffic range for com.apple.WebKit.Networking, so there is no reliable fixed number of megabytes that separates ordinary use from a problem. The expected amount depends on what the host app and its web content are doing.

At one end, an idle page or a cache hit can produce almost no network traffic. At the other, a media-rich page, continuous audio or video playback, or a large web download can produce sustained high traffic comparable to the content being loaded. A mostly static document will usually transfer much less than continuous media or a download, but that comparison is not precise enough to establish a universal threshold. A high total needs context: the time period, destination, host process, and page activity all matter.

Can you turn it off

Apple does not provide a System Settings switch for disabling com.apple.WebKit.Networking. There is therefore no settings path to follow.

You can force an individual instance to quit, but doing so may interrupt or reload pages in Safari or another WKWebView host. It can also disrupt downloads, streaming media, sign-in flows, and real-time connections. The host app may create the process again as soon as it needs WebKit networking.

Blocking or deleting the component is not a supported way to reduce traffic. WebKit-based network content depends on it, so preventing it from running would break that content rather than selectively remove unnecessary transfers. If data use is the concern, identifying the responsible app, page, and destination is more useful than repeatedly terminating the helper.

What people get wrong

1. “Seeing com.apple.WebKit.Networking means the Mac has malware.” That conclusion is incorrect. The Apple component located at /System/Library/Frameworks/WebKit.framework/Versions/A/XPCServices/com.apple.WebKit.Networking.xpc/Contents/MacOS/com.apple.WebKit.Networking is a normal part of WebKit. If an executable with the same name appears in another writable directory, its path and signature should be verified separately; the name alone is not proof either way.

2. “It belongs only to Safari.” WebKit is also used by Mail, the App Store, and many other first-party and third-party apps that embed WKWebView. A process with this name may therefore be serving an app other than Safari. Multiple host apps or sessions can also explain why several same-named instances appear.

3. “All of its traffic is macOS uploading data in the background.” There is no basis for that claim. The name identifies WebKit’s network execution process, not the purpose of each connection. Traffic usually originates from a host app or its web content and may include third-party resources loaded by the page. The process name alone cannot reveal the exact website, purpose, or responsible app.

4. “High traffic means the process is out of control or secretly downloading something.” High use can come from ordinary activity such as video, audio, a web download, autoplay, a real-time connection, or an active background page. The amount alone cannot distinguish these cases. You need the connection destination and host-process context before drawing a conclusion.

5. “Force-quitting or deleting it is a good long-term way to save data.” Force-quitting only ends the current instance and may disrupt whichever apps are using it. WebKit can recreate the process when another request arrives. Deleting a system component is not an Apple-supported optimization and would prevent dependent web content from working.

Seeing what it actually used

The next step is to inspect com.apple.WebKit.Networking over the time period in question instead of judging it from one moment in Activity Monitor. Bytetally’s per-process statistics can show how much traffic was attributed to the process; connection destinations and the active host app or page then provide the context needed to interpret that total. Remember that preloading, background pages, and third-party resources may be included even when you did not directly click anything.

Related processes

Common questions