What is com.apple.WebKit.WebContent on my Mac?

It's the helper process that draws and runs web pages. Safari is built on an engine called WebKit, and macOS gives each website you have open its own WebContent process so a broken page can't crash the rest of the browser. Apps that show web pages inside themselves, like the App Store and Mail, use the same process name. Several of them in Activity Monitor is completely normal.

Is WebKitWebContent a virus?

No — it's a standard part of macOS. To verify you're looking at the genuine system file, run “ps aux | grep WebContent” in Terminal and check the path on its line: the real one lives inside /System/Library/Frameworks/WebKit.framework. Malware occasionally disguises itself with similar-looking names, but a process running from that exact system location is Apple's own.

Why is WebKitWebContent using so much memory?

Because it's holding the web pages you have open — every site keeps its images, code, and scroll position in RAM so switching back is instant. A few hundred megabytes per process is normal. A single process in the multi-gigabyte range means one heavy page (video, ads, a web app) or a stuck process; quit Safari with Cmd-Q and if it's still there a minute later, force-quit that one process.

Can I quit or force-quit WebKitWebContent?

Yes, and it's safe. The process holds web page content only — never your files or system settings. Force-quitting it in Activity Monitor ends that page; Safari shows a “webpage was reloaded” message and carries on. The only cost is unsaved text in that page's forms, like a half-written post.

Why does WebKitWebContent show over 100% CPU?

Activity Monitor measures CPU per core. 100% means one full core; 200% means two cores. A stuck web process at 204% on a ten-core Mac is using two entire cores — which is why one browser process can make the whole machine hot and loud.

WebKitWebContent High CPU or Memory on Your Mac? The Fix (2026)

Fans roaring, memory gone, and when you open Activity Monitor there's a process called com.apple.WebKit.WebContent sitting at the top — maybe at 143% or 200% CPU, which sounds impossible. It has a long, technical name, so it looks like malware. It isn't. It's Safari's page engine, and high usage is one specific page or process misbehaving.

First, split the problem. If it only climbs while you browse, it's a page or extension. If it stays high after you quit Safari — or with Safari closed entirely — it's a stuck process or another app. The checks below cover both, in the order worth trying. Or let Noah find the exact process and deal with it on your approval (more at the end).

What WebContent actually is

WebKit is Apple's engine for drawing web pages — the code that turns HTML into the page you see. Safari is built on it, and so is any app that shows a web page inside its own window: the App Store, News, Mail loading a message's images, an app's sign-in page. com.apple.WebKit.WebContent is the helper process where that page-running actually happens.

macOS runs one WebContent process per website you have open, so a broken page can't take the whole browser down with it. That's why you'll see several of them in Activity Monitor — on a normal Mac, each sits around a few hundred megabytes and near-zero CPU. It also explains the scary number: CPU above 100% means the process is using more than one core — 204% is two full cores of a ten-core machine.

NoahThis process was the single biggest memory user in 30 of the diagnoses Noah has run on real Macs — from 0.3 GB to 8.9 GB for one process. It's the most common memory hog there is, because it's the thing running your tabs.

First, find which one it is

Open Activity Monitor (⌘ Space, type Activity Monitor), click the % CPU column, then the Memory column. You're not looking at whether WebContent exists — you're looking for one process far above the others. From Terminal, the same list with process IDs:

zsh — Terminal

% ps aux | grep "WebKit.WebContent" | grep -v grep

One line per open site — several is normal. The columns after the ID are CPU% and memory%; the line that towers over the rest is your culprit. Note its number in the second column.

One heavy page

CPU and memory climb while you browse, and Safari feels heavy — scrolling stutters, the beachball appears. Quit Safari and everything is instantly fine again.

A single page can pin a whole core: autoplaying video, ad networks, a page left running a live dashboard or a web app that never sleeps. Because each site gets its own process, one bad page shows up as exactly one hot WebContent line.

Fixclose tabs until the hot line drops — the last tab you closed was the culprit. If Safari is too wedged to cooperate, quit it fully with ⌘Q. Safari offers to reopen your windows on the next launch, so you lose nothing but the bad page.

A stuck process

One WebContent process stays at high CPU for hours — with its tab closed, Safari idle, or after the Mac slept and woke. It doesn't respond to anything you close.

Sometimes a page's process just wedges — most often around sleep/wake — and keeps spinning at full tilt while doing nothing. Noah has watched one hold 204% CPU (two cores of a ten-core Mac) and another at 143% for hours after the tab that started them was long gone.

Fixquit Safari with ⌘Q. If the process is still there a minute later, force-quit it: select it in Activity Monitor, click the Stop button (top-left, an octagon with an ✕), choose Force Quit. This is safe — the process only holds web page content, never your files. Safari just reloads the page if it needs it back.

NoahOn one Mac, quitting Safari and cleaning up the stuck WebContent process dropped swap from 10.2 GB to 1.4 GB within minutes — the whole Mac felt new, not just Safari.

An extension running on every page

Any browsing makes WebContent climb — every site, not one. An ad blocker, a coupon finder, a VPN extension, a “shopping companion.”

Safari extensions run their code inside pages as they load. A heavy one taxes every site you visit, which reads in Activity Monitor as WebContent being busy everywhere — the extension's cost is billed to the page, not to Safari.

FixSafari > Settings > Extensions. Turn everything off, browse a little, and if the Mac calms down, turn them back on one at a time until the culprit shows itself. Anything you don't actively recognize is the first to go.

Not Safari at all

A WebContent process runs hot with Safari quit — maybe even Safari never open.

Apps that show web pages inside themselves use the same engine, and their pages run under the same WebKit.WebContent name. The App Store, News, Mail, and plenty of third-party apps do this. One of their embedded pages is misbehaving exactly the way a bad tab would.

Fixlook at what else is running. Quit apps one at a time — the App Store, Mail, anything with a sign-in or news pane — and watch the process vanish when its host quits. Updating or reopening that app usually leaves the bad page behind.

The short version

Activity Monitor > % CPU, then Memory — find the one WebContent line that towers.
Still browsing? Close tabs until it drops; ⌘Q Safari if it's wedged.
Survives Safari quitting? Force-quit that one process — it's safe.
Comes back while browsing? Audit Safari > Settings > Extensions.
Safari was never open? It's another app's embedded page — quit apps one at a time.

Commands in this guide are standard, read-only macOS diagnostics unless noted; anything that changes your system is called out. When in doubt, back up first with Time Machine.

com.apple.WebKit.WebContent is eating your Mac. Here's what it actually is