How to Remove Leftover App Files on Mac

If you've used a Mac for more than a couple of years, there's a good chance it's quietly holding onto files from apps you don't even remember installing — let alone uninstalled properly. On macOS, removing an app by dragging it to the Trash only deletes the app bundle itself. It typically leaves behind supporting files in ~/Library/Preferences/, ~/Library/Caches/, ~/Library/Application Support/, and sometimes ~/Library/Containers/. Once the app is gone, those files have nothing left to belong to — they're orphaned, sitting there indefinitely unless something removes them.

This guide is specifically about that second problem: apps you already removed, sometimes a long time ago, that left files behind. If you're about to uninstall an app right now and want to do it cleanly the first time, our companion guide on how to completely uninstall apps on Mac covers that instead. Here, we're cleaning up after the fact.

What counts as a leftover app file

A leftover, in this context, is any file or folder that was created by an app to store its settings, cached data, or support files, and that has survived the app's removal. The four places they're most commonly found:

• ~/Library/Preferences/ — small .plist files storing an app's settings. These are usually tiny individually, but they never expire on their own.
• ~/Library/Caches/ — temporary data an app generated to speed itself up. Safe to remove in general, but for an already-uninstalled app it's pure dead weight.
• ~/Library/Application Support/ — this is where things get larger. Apps store databases, downloaded assets, plugins, and user data here. Application Support leftovers are often the biggest single category by disk space, because this is where an app keeps everything that isn't a simple preference.
• ~/Library/Containers/ — used by sandboxed apps (including most Mac App Store apps), each with its own self-contained folder that can include a full private copy of an app's data.

None of this is a bug or a sign of a poorly built app — it's simply how macOS has always worked. The operating system doesn't track which app created which file well enough to clean up automatically when you drag something to the Trash, so the responsibility falls on whatever uninstalled it (or on you). There's nothing inherently harmful about leftover files sitting there; they're not a security risk, and macOS won't misbehave because of them. They're simply clutter — storage spent on apps you can no longer even open to decide whether you still need them.

Why leftover files pile up over the years

A single leftover folder from one app is a non-issue. The problem is cumulative. Over years of normal Mac use, a few patterns compound:

• Trial software. You try a video editor, a menu bar utility, or a photo tool for a week, decide against it, and drag it to the Trash. The preferences and cache it created during that week stay behind indefinitely.
• One-off utilities. A tool you needed for a single task — converting a file format, recovering a document, testing something for work — gets removed once the job is done, but its support files don't go with it.
• Apps replaced by newer alternatives. You switch note-taking apps, or password managers, or image viewers, and the old one's data sits untouched in Application Support because nothing prompted you to go back and clean it up.
• Apps updated through a different installer. Some apps get replaced rather than updated in place — a new major version ships as a fresh install under a slightly different bundle identifier, or you move from a direct-download version to a Mac App Store version (or vice versa). The old installer's files don't get touched by the new one, so you end up with two sets of leftovers for what feels like one app.

None of these are unusual habits — they're just normal Mac usage. But add them up across five or ten years and it's easy to have leftover files from dozens of apps that no longer exist anywhere on the machine.

How to find leftovers manually

You can absolutely do this by hand, and it costs nothing but time. The process is the same for each of the four folders mentioned above:

• In Finder, use the Go menu → Go to Folder (or press Cmd+Shift+G), and enter the path — for example ~/Library/Application Support.
• Sort the contents by name and scan through the folder list. Compare what you see against the list of apps currently in your /Applications folder.
• Any folder that clearly references an app you no longer have installed is a candidate for removal. Repeat for ~/Library/Preferences, ~/Library/Caches, and ~/Library/Containers.

This works well when a folder is named plainly after the app — a folder called "OldVideoConverter" is easy to recognize. The complication is that many folders, particularly in Preferences and Containers, are named after a developer's bundle identifier rather than the app's display name — something like com.developername.appname.plist. If you don't already know that a given developer made a particular app, that file gives you almost nothing to go on, and you're left guessing or searching the name online before you can decide whether it's safe to remove.

The ~/Library/Containers folder is usually the least readable of the four for exactly this reason — sandboxed apps almost always show up by bundle identifier rather than display name, and each container can hold a surprisingly complete copy of an app's data. It's also where App Store apps in particular tend to leave the largest leftovers, since sandboxing keeps everything for one app self-contained in a single folder rather than scattered thinly across the other three locations.

Why this is easy to get wrong by hand

It's worth being direct about this: manually cross-referencing four folders against your installed apps is genuinely tedious, and it's easy to make a mistake in either direction. Bundle-identifier naming means some leftovers are hard to recognize as leftovers at all. At the same time, ~/Library also contains files that are still actively used — by apps you do have installed, by system frameworks, or by macOS itself — and some of those folders have equally unfamiliar or unhelpful names.

The safe rule is simple: only delete what you can confidently identify as belonging to an app you no longer have installed. If a folder name is ambiguous, or you're not sure whether something is still in use, leave it alone. A few kilobytes of orphaned preferences sitting untouched costs you nothing. Deleting the wrong support file for an app you still use can mean losing settings, license activation, or saved data you'd rather not recreate.

A faster way to find app leftovers

Because the manual process is really a matching problem — files on one side, currently installed apps on the other — it's exactly the kind of thing that's much faster to automate correctly than to do by eye. CleanMyApple's leftover finder scans ~/Library/Preferences, ~/Library/Caches, ~/Library/Application Support, and ~/Library/Containers for files associated with apps that are no longer present in your Applications folder, and lists them out for you to review.

It doesn't delete anything on its own. You see exactly what it found and why it believes each item belongs to an app that's no longer installed, and nothing moves to the Trash until you confirm it. That's the main thing it removes from the manual process — not the decision of what to delete, but the slow, error-prone work of matching cryptic folder names in ~/Library against apps you may not have thought about in years.

Uninstalling an app right now instead?

If you're actually in the middle of removing an app rather than cleaning up after past removals, it's worth doing it properly the first time so you don't end up back here in a year. Our guide on how to completely uninstall apps on Mac walks through removing an app and its associated files together. And if you've run into an app that resists being removed at all — one that won't drag to the Trash, or throws an error when you try — see how to uninstall apps that won't delete on Mac.

Whether you're clearing out years of accumulated leftover files or making sure a fresh uninstall doesn't leave any behind, the underlying goal is the same: keeping ~/Library as a record of what you actually use, not an archive of everything you've ever tried.