mediaanalysisd Isn’t a Virus — It’s Visual Look Up (and Sometimes a Runaway Cache)

A process called mediaanalysisd is pinning your CPU, your fans are up, and something named com.apple.mediaanalysisd has quietly eaten tens of gigabytes of disk. Here’s what it actually is, the reported 2025 bug behind the worst cases, whether your photos are leaving the Mac, and how to calm it down safely.

By CoreGuard · Jul 7, 2026 · 14 min read

There are two ways people arrive at this page. Some open Activity Monitor because the Mac is hot and find mediaanalysisd near the top of the CPU list. Others open the Storage settings, or a “what’s eating my disk” tool, and discover a folder called com.apple.mediaanalysisd that has somehow swallowed 40, 80, even a reported 140 GB. Both trails lead to the same daemon, and — in 2025 and into 2026 — often to the same underlying story.

Here’s the whole picture: what mediaanalysisd is for, why it’s usually harmless, the specific reported bug behind the ugly cases, the honest answer to “is it sending my photos to Apple,” and how to calm it down without deleting things you’ll regret.

What is mediaanalysisd?

mediaanalysisd is the part of macOS that analyzes images and video on your Mac to power two features you’ve probably used without thinking about the plumbing:

• Visual Look Up — the little sparkle icon that identifies a landmark, plant, pet, or object in a photo. It arrived in macOS 12 Monterey (2021).
• Live Text — the on-device OCR that lets you select, copy, and translate text inside an image or screenshot.

The important part — and the source of a lot of confusion — is that mediaanalysisd works system-wide, not just inside the Photos app. It’s driven by a framework called VisionKit: open an image in Quick Look, Preview, or Finder and VisionKit fires off an on-demand request that mediaanalysisd services, offloading the heavy math to the Apple Neural Engine. Howard Oakley’s log traces show exactly this — a VCPMADServiceImageProcessingTask kicking off the moment an image is opened.

mediaanalysisd vs. photoanalysisd: what’s the difference?

These two get mixed up constantly, because the names rhyme and they’re often busy at the same time. A useful mental model (it’s not an Apple-published spec, so treat it as a guide, not gospel):

• photoanalysisd is the Photos-library daemon. Per its man page it “handles background processing of photo libraries for Memories, People and scene or object based search.” It walks your library to build the People album, Memories, and search.
• mediaanalysisd is the broader, system-wide engine for Visual Look Up and Live Text on any image you open — a screenshot, a web image in Preview, a video frame — not only your Photos library.

Rule of thumb: if the burn is tied to Photos chewing through your library after an import, suspect photoanalysisd; if it’s tied to Visual Look Up, Live Text, or a runaway cache, suspect mediaanalysisd. On a real machine you’ll often see both.

Why is mediaanalysisd using so much CPU?

Most of the time, the answer is boring and benign: it’s working through a backlog. After a big photo or video import, a macOS upgrade, a restore, or a fresh iCloud sync, there’s a queue of unanalyzed media, and mediaanalysisd grinds through it — usually while the Mac is idle and on power. A single Visual Look Up is genuinely cheap: Howard Oakley measured a reported ~6.9 joules over about 6.5 seconds for one lookup on an M4 Pro (he cautions the measuring tool is uncalibrated). So a brief spike per image is normal, and a backlog spike ends.

Then there’s the case that brought most people here. Since late 2024, there’s a well-documented runaway bug, and the most honest thing anyone can tell you about its cause is what Michael Tsai wrote after collecting the reports: the trigger “is currently unknown … or if it’s just a bug.” What the logs do show is the shape of it. The developer behind zerosleeps captured mediaanalysisd on macOS 15.5 and reported the shape of it: ~1.64 million log lines in three hours, about 993,000 of them errors, while it retried the same 675 files — all figures from that write-up. It was stuck retrying the same handful of tiny, 1×1, or undecodable images (think stray favicons and thumbnails), choking on messages like “Image has invalid or too small dimensions” and “Failed to decode image,” never marking them done, and starting over. Forever.

If that shape — a background process pinning the CPU while nothing you did explains it — feels familiar, it’s the same lesson behind coreduetd’s busy-versus-stuck problem: a spike that fades is work; a spike that’s pinned flat for days is a loop.

The cache that ate your disk

The runaway loop has an expensive side effect: it doesn’t just burn CPU, it writes. Every retry re-caches compiled Neural Engine model bundles, and the cache balloons. This is the com.apple.mediaanalysisd folder people find eating their SSD, and it’s worth knowing exactly where it lives, because two different paths get quoted:

• The container: ~/Library/Containers/com.apple.mediaanalysisd/Data/Library/Caches/com.apple.mediaanalysisd/
• The subfolder where the bloat actually accumulates: …/com.apple.e5rt.e5bundlecache/ — the E5-runtime bundle cache that stores those compiled model bundles.

The numbers people report are genuinely alarming, and they’re all reported, not Apple-confirmed. The owner of the main Apple Community thread watched it grow at a reported ~67.9 MB per hour while the Mac sat idle, reaching ~17 GB in a week; others cite 50, 80, even a reported 143 GB “for a 27 GB photo library.” Just as important for anyone who cares about drive longevity: the loop drives heavy disk writes — users reported hundreds of gigabytes written per day — which is real SSD wear, the same reason we wrote about a local tool quietly spending an SSD’s endurance.

The onset lines up with a specific version: reports say it started with macOS 15.1 (October 28, 2024) and did not happen on 15.0.1; some users say it improved in 15.3, yet it’s still reported on 15.5 and 15.7, with an early mention on macOS 26 Tahoe. There is no official Apple fix note, so treat it as an ongoing, version-variable bug rather than something “fixed in X.”

Is mediaanalysisd a virus?

No. Even when it’s pinning a core and hoarding disk, mediaanalysisd is a legitimate Apple system daemon — the “media analysis daemon” — not malware and not spyware. When the crypto researcher Howard Oakley tested the “is Apple scanning my images” fear back in 2023, he found no evidence that merely viewing local images in the Finder uploads anything to Apple.

As always, the fair version of the question is about impostors, because any file can borrow a trusted name. So verify the path and the signature, not the name. The real binary lives inside a system framework — note PrivateFrameworks, not the public Frameworks folder — at /System/Library/PrivateFrameworks/MediaAnalysis.framework/Versions/A/mediaanalysisd, on the sealed, read-only System volume where it can’t be quietly modified. One command confirms it — codesign -d --requirements - prints the signing requirement, and a genuine Apple binary ends in anchor apple (Apple’s own root, used only for OS code — distinct from the anchor apple generic you’d see on third-party apps):

Does mediaanalysisd send my photos to Apple?

This is the fair, important question, and it deserves an honest answer rather than either a shrug or a scare. Short version: not the images themselves. Classic Visual Look Up does its analysis on-device and only reaches out to Apple when you actually tap a result to fetch, say, the details about a landmark.

The part worth understanding is newer. In macOS 15.1 Sequoia / iOS 18.1 (October 28, 2024) Apple added Enhanced Visual Search, which lets Photos match landmarks even in pictures with no location data. Here’s how Apple describes the mechanism: your device decides a photo probably contains a landmark, computes a low-fidelity “embedding” — a mathematical fingerprint, not the photo — then encrypts it with homomorphic encryption, adds noise for differential privacy, and sends it through an OHTTP relay (run by a third party, reported to be Cloudflare) that hides your IP address. A private match runs against Apple’s landmark index and returns an encrypted result only your device can read. Apple’s own line: it “works without sending your photos or videos to Apple.”

Credit where it’s due: that’s a genuinely privacy-engineered design, and cryptographers who reviewed it said the math is sound. The fair criticism — from developer Jeff Johnson and Johns Hopkins cryptographer Matthew Green — isn’t that it steals your photos; it’s that Apple turned it on by default and barely announced it. If you’d rather it were off, the toggle is Photos → Settings → General → “Enhanced Visual Search” on macOS (on iPhone: Settings → Apps → Photos). One honest catch worth knowing, because most write-ups miss it: turning off Enhanced Visual Search does not turn off ordinary Visual Look Up — those are separate settings.

Can I quit or disable mediaanalysisd?

You can quit it, and it’s safe. Like every system daemon in this family, mediaanalysisd is managed by launchd, so quitting it in Activity Monitor (select it → stop → Quit) or with killall mediaanalysisd just relaunches it the next time a feature needs it. If it was mid-loop, that restart buys you a pause — useful right before you clear the cache, so it isn’t writing while you delete — but it isn’t a cure on its own.

You cannot permanently delete or disable it: the binary is on the sealed, read-only System volume, protected by System Integrity Protection, and it comes back on reboot. Disabling SIP to strip it out would be a real security downgrade to kill a normal system process — not warranted. The productive levers are in the next section.

How to calm mediaanalysisd down (safely)

Match the fix to which case you’re in:

1. If it’s a backlog (it’s fading), just let it finish. After an import, upgrade, or big iCloud sync, plug in, leave the Mac awake and idle for a while, and let it complete. The spike is expected and ends.
2. Confirm which case you’re in. Check the cache size with du -sh ~/Library/Containers/com.apple.mediaanalysisd. A few hundred megabytes is normal; tens of gigabytes, plus days of pinned CPU, is the runaway bug.
3. For the runaway bug: quit, then stop the trigger. Quit mediaanalysisd first (above). The lever that actually broke the loop for several people — per the zerosleeps write-up — was excluding the offending media folder from Spotlight indexing in System Settings → Spotlight → Search Privacy, which stops it from re-scanning the files it chokes on.
4. Clear the cache only after you’ve stopped the loop — and know the caveat. Clearing the cache inside ~/Library/Containers/com.apple.mediaanalysisd (the e5bundlecache folder) reclaims the space, but it’s a cache: macOS rebuilds what it needs, and if the loop is still running it just grows back (one user cleared ~50 GB and watched ~20 GB return). So it treats the symptom; the Spotlight exclusion cuts off the files the loop keeps choking on. (The bug’s root trigger is still officially unknown, so this is a reported lever, not a certified fix.)
5. Optionally, turn off Enhanced Visual Search in Photos → Settings → General if you don’t use landmark search and prefer nothing leaving the device. This turns off only the Photos landmark-matching path — ordinary Visual Look Up is separate and stays on — and there’s no evidence it stops the runaway-cache bug, so don’t treat it as the fix.

And a reported curiosity worth a mention, because it’s odd and free: some users found that simply keeping the Photos app open stops mediaanalysisd from running its background pass. File that under “workaround,” not “explanation.” What doesn’t help: a “cleaner” or “antivirus” app — it can’t touch a sealed Apple system daemon, and the pages promising to “fix mediaanalysisd” are a marketing hook, not a fix.

When is mediaanalysisd actually a problem?

When the runaway picture holds all at once:

• CPU pinned for days, not a fading backlog.
• The com.apple.mediaanalysisd cache is tens of gigabytes and still growing.
• You’re seeing heavy disk writes with the machine otherwise idle.

That combination is the reported bug, and it’s worth the steps above — and worth reporting to Apple through Feedback Assistant, since the trigger is officially unknown and more reports are how it gets fixed. Everything short of that — a spike that fades after you imported photos or updated macOS — is the system doing its job, and the right move is to let it finish.

What CoreGuard shows during a mediaanalysisd spike

This is exactly the kind of moment I’m building CoreGuard for, so let me be concrete — and honest about the limits.

The hard part here is seeing the whole shape: the scary process, whether it’s fading or stuck, and the cache quietly growing in the background. CoreGuard names the top process in plain English — “mediaanalysisd — Visual Look Up & Live Text,” not a cryptic string — so you know it isn’t malware. It shows live temperatures, fan RPM, and CPU/load with a history, so you can tell a fading backlog from a flat, pinned loop. And in its read-only disk inventory, it surfaces a ballooning directory like com.apple.mediaanalysisd so you can actually see the bloat instead of hunting for it — the process naming, the live readings, and every danger warning are free, forever; the detailed disk inventory and per-app energy history are part of Pro.

The honest limits: CoreGuard does not clean, delete, throttle, or “fix” mediaanalysisd, it doesn’t empty that cache for you, and it is not an antivirus. It observes and explains, then hands you Apple’s own real settings — the Spotlight exclusion, the Enhanced Visual Search toggle — and lets you decide. It’s local-only, too: zero network connections, no account, no telemetry, which you can verify yourself with lsof -i -nP | grep CoreGuard and watch nothing happen.

CoreGuard isn’t out yet — the download and checkout go live shortly. Free covers the live readings, the “what’s eating your Mac” process naming, the history, and every danger warning, forever; Pro is a one-time $29 (Family $49), perpetual, not a subscription, with a 30-day money-back guarantee. So the honest ask: get notified and grab it free at launch, or see what Pro adds. Either way — next time a process runs your Mac hot and your disk keeps shrinking, check the name, the trend, and the cache before you touch anything.

Frequently asked questions