How to find and remove app leftover files on a Mac

Leftover files from an app you deleted months or years ago on a Mac live in a short, predictable list of ~/Library subfolders — Application Support, Caches, Preferences, Containers, Saved Application State, LaunchAgents, Logs, WebKit, and HTTPStorages — each one named after the app's bundle identifier, not the name you saw in Launchpad. Once the app itself is gone, hunting by name gets unreliable fast. Matching by bundle ID against the apps you still have installed is what actually separates an orphan from a folder you're still using.

If you're uninstalling an app right now, our guide to completely uninstalling a Mac app covers doing it properly the first time, bundle ID and all, while the app is still there to check. This one is for the apps that are already gone — sometimes years gone — where there's no Info.plist left to read and often no memory of what the app was even called.

Where a deleted app's files actually end up

All of the locations below sit under your user Library, which Finder hides by default. Fastest way in: open Finder, press Shift-Command-G (⇧⌘G), and paste the path.

How to tell an orphan from a folder you still need

Every folder above is named after the app's bundle identifier — a reverse-DNS string like com.adobe.acc or com.postmates.PostmatesMac — not the friendly name from Launchpad. That's true whether the app is installed or not, and it's the thing that makes this solvable once the app is gone: you don't need to remember its name correctly, you need to know which bundle IDs on your Mac are still in active use. Apple documents the mechanism here: Get the bundle ID for a Mac app.

Step 1 — list what's currently installed. Open Terminal and run:

for a in /Applications/*.app; do echo "$(mdls -name kMDItemCFBundleIdentifier -raw "$a") $a"; done | sort

That prints every bundle ID currently in use, next to the app it belongs to. If you keep apps in /Applications/Utilities too, run the same loop against that path. This list is your reference — anything on it is off-limits.

Step 2 — list what's actually sitting in Library. A quick pass through the folders that matter most:

ls ~/Library/Application\ Support

ls ~/Library/Caches

ls ~/Library/Containers

Step 3 — compare. Any reverse-DNS-shaped name from step 2 that doesn't appear anywhere in your step 1 list is a candidate orphan. You can usually tell which vendor it belonged to just by reading the string backward: com.adobe.something is Adobe, com.docker.something is Docker. If it's genuinely unfamiliar, search the exact string — bundle identifiers are globally unique, so the first result almost always names the app.

Two exceptions worth knowing before you delete anything. A helper process sometimes ships its own bundle ID that doesn't exactly match the main app's — an updater or background agent with .helper or .agent appended. Read the vendor prefix, not just the exact string, before ruling something out. And never treat "not on my installed list" as automatic permission for anything with a com.apple prefix: plenty of those folders belong to system frameworks and built-in apps that never show up as their own .app in /Applications. Our guide on what's actually safe to delete on a Mac covers that boundary in more depth.

Three traps that turn a cleanup into a broken app

• The com.apple.* namespace. System components, Messages, Photos, and Notes all keep state under this prefix in Caches, Preferences, and Containers. None of it is a leftover from an app you removed — it's live state for macOS itself or a built-in app you're still using.
• Folders that are actually iCloud or Dropbox sync points. A folder under Application Support named after a cloud service, or one that syncs on its own, isn't a static leftover. It's an active sync endpoint. Deleting it doesn't just free space locally — depending on the service, it can propagate.
• One developer's shared Application Support folder. Some vendors put several of their apps' data under a single parent folder — a generic developer name rather than a per-app bundle ID. Deleting the whole thing to clean up one orphan can take a still-installed sibling app down with it. If a folder's name is a company, not a bundle ID, open it first and check what's inside before deleting the parent.

Login items and launch agents that outlive the app

Delete every file above and macOS can still list the app in System Settings > General > Login Items & Extensions — check there first; it needs no bundle ID and no Terminal. A dead login item shows a warning triangle next to it, meaning the thing it points to no longer exists, and it's a one-click Remove from that screen. An "Allow in the Background" toggle can also linger for a while after the app's files are gone; it's inert with nothing left to apply to, but it's a one-click removal too if it bothers you. Apple's own walkthrough for this screen: Change Login Items & Extensions settings on Mac.

If you found a suspicious .plist in ~/Library/LaunchAgents or /Library/LaunchDaemons during that check, confirm it's actually running before you touch it: launchctl list | grep bundle-id. Something running needs to be unloaded before the file is removed, or it keeps going until the next login.

Is the hunt actually worth it?

For most single-purpose apps, no. Preferences, Saved Application State, Logs, and Cookies together typically add up to a few hundred KB to a couple of MB per app — not worth the research time on something you don't remember installing. The honest exceptions are Application Support and Caches, because those are the two locations that can hold real size: a backup tool, a video editor, or anything that cached documents or media locally can leave behind hundreds of MB, occasionally more.

The decision rule that actually works: if you don't recognize the folder and it's small, leave it. A stray plist can't run code and costs you nothing. If it's identifiable and it's one of the two big locations, it's worth the ten seconds to check Get Info and decide for real.

The faster path: SwoopByte Uninstaller's Leftover Finder

Everything above is the manual version — a Terminal loop, a handful of ls commands, and a judgment call on every reverse-DNS string you don't recognize. SwoopByte Uninstaller's free tier handles single-app removal today: installed-apps list, full plain-language leftover preview, bundle-ID-first matching. That assumes the app is still on your Mac to select, though — it doesn't cover an app you already removed by hand or with something else months ago.

That specific case — orphans from apps that are already gone — is what the Pro tier's Leftover Finder is built for: the same bundle-ID cross-check from this guide, run automatically across every Library location above. The safety rules stay identical and are never paywalled: iCloud, Dropbox, and com.apple.* folders stay protected, and everything found moves to Trash, never straight to permanent deletion. Pro is a one-time $12.99. No subscription, no separate scanning fee.

FAQ

How do I find leftover files from an app I deleted a long time ago?

Check ~/Library/Application Support, Caches, Preferences, Containers, and LaunchAgents for a folder or file named after the app's bundle identifier — a reverse-DNS string like com.developer.appname. Cross-reference that name against the bundle IDs of apps you currently have installed; anything that doesn't match is a candidate orphan.

The app is gone — how do I even know its bundle ID?

You usually don't need to know it ahead of time. Build a reference list of the bundle IDs for every app you currently have installed with a short Terminal loop, then anything in your Library folders that isn't on that list is the orphan — the reverse-DNS string itself tells you which vendor it belonged to.

Is it safe to delete a com.apple.something folder if I don't recognize the app?

Not automatically. Many com.apple.* folders belong to built-in macOS frameworks and system apps that never appear as a separate .app in /Applications, so not recognizing one doesn't mean it's orphaned. Leave anything with that prefix alone unless you can confirm exactly what it belongs to.

Why does System Settings still list an app I deleted months ago?

Login Items & Extensions, under System Settings > General, can keep a stale entry after an app is gone — a dead login item with a warning triangle, or a leftover background-activity toggle. It's inert; remove it from that screen if you want it off the list.

Is it worth hunting down every single leftover file?

For most apps, no — Preferences, Saved Application State, Logs, and Cookies combined are usually a few hundred KB to a couple of MB, which isn't worth the time on an app you barely remember. Application Support and Caches are the two locations worth checking specifically, since those are where real size actually accumulates.

Related guides