Empty folders don't take up meaningful disk space — an empty directory entry is a few bytes of metadata, not gigabytes — so cleaning them up is not really a storage exercise. It's a clarity exercise. A home folder scattered with dozens of empty leftovers from uninstalled apps, abandoned Xcode projects, and half-finished organisational schemes makes it harder to trust what you're looking at when you do need to find real space to recover. This is about tidiness with a specific, low-risk method, not a space-recovery technique.

Where empty folders actually come from

They're rarely created deliberately; they're residue from other processes:

  • App uninstalls that remove the application bundle but leave behind an empty Application Support or Caches subfolder structure
  • Xcode project templates that scaffold a folder tree for resources, tests, or assets you never ended up using
  • Downloads and extractions where a zip expands into a folder, you move the useful file out, and the now-empty container stays behind
  • Sync tools (cloud storage clients in particular) that recreate an empty folder structure locally even after the actual files have been removed or moved elsewhere
  • Manual organisation attempts — folders created for a filing system that never got used

None of these are urgent to clean up, but they accumulate over years the same way any other unattended clutter does.

Folders that look empty but aren't

Before removing anything, it's worth knowing that Finder can be misleading here. A folder can appear empty in Finder's icon or list view while still containing:

  • Hidden files — anything starting with a dot, like a stray .DS_Store (Finder's own per-folder metadata file, harmless and regenerated automatically) or a hidden config file
  • Extended attributes on the folder itself — Finder tags, comments, or a com.apple.quarantine flag, none of which show as file contents but do mean the folder isn't purely empty at the filesystem level

Show hidden files in Finder with Cmd+Shift+. before trusting that a folder is truly empty, since a folder containing only a .DS_Store file is, for practical purposes, empty — but one containing a hidden config file you set up deliberately might not be.

Finding empty folders from the command line

The find command can locate genuinely empty directories recursively, which is more reliable than checking folders one at a time in Finder:

find ~/Projects -type d -empty

This lists every truly empty directory under ~/Projects without deleting anything — a safe first step to see the scope before acting. Note that a directory containing only other empty subdirectories will not itself show as empty until those subdirectories are removed first, so you may need to run this more than once as nested empty folders clear out from the bottom up.

Removing them safely

Once you've reviewed the list find produced and you're confident none of them are hiding something you'd want (check a few manually with ls -la first, which shows hidden files), you can remove empty directories recursively:

find ~/Projects -type d -empty -delete

This only removes directories that find confirms are empty at the moment it deletes them — it will not touch a folder containing files, hidden or otherwise. Still, treat any recursive delete command with the caution it deserves: run the non-destructive find ... -empty version first, read the output, and only add -delete once you trust the list.

Avoid running this against your entire home directory in one pass. Scope it to a specific subtree — a Projects folder, an old backup structure, a folder you know is mostly cruft — rather than ~ itself, where an empty-looking folder might be a placeholder some application expects to exist.

Xcode-specific leftovers

Xcode in particular leaves behind empty scaffolding more than most tools. Deleted projects sometimes leave empty parent folders in whatever directory you organise projects under, and old workspace configurations can leave empty .xcworkspace wrapper folders after you've removed the project they belonged to. These are safe to clean with the same find -empty approach, scoped to wherever you keep Xcode projects.

When to leave a folder alone even if it's empty

A small number of empty folders exist deliberately as placeholders — a .git hooks directory structure, an app's expected-but-currently-unused cache location, or a folder your build tooling checks for before creating files in it at runtime. If a folder sits inside an active project's structure (rather than a top-level organisational folder you created), check what the project actually expects before removing it. This is a case where "it looks empty and unused" and "it is actually unused" aren't quite the same claim.

Empty folders inside version-controlled projects

Git specifically does not track empty directories at all — it only tracks files, which means an empty folder inside a git repository either isn't actually tracked (and removing it has no effect on the repository's history) or is being kept empty deliberately via a placeholder file like .gitkeep, a convention some teams use to force a folder to exist in fresh checkouts. Before removing an empty folder inside a repository, check for a .gitkeep or similarly named placeholder file first — if you see hidden files with ls -la and one of them looks like a deliberate placeholder, the folder is empty on purpose, not accidentally.

A gentler alternative to bulk deletion

If you're not confident enough to run a recursive delete across a folder tree, an equally valid approach is simply noticing and removing empty folders one at a time as you encounter them during normal use — while organising a Projects directory, say, or tidying up after finishing a piece of work. This is slower than a find -empty -delete pass, but it removes any risk of catching a folder you didn't mean to review, since you're looking at each one in its actual context rather than trusting a blanket rule.

Where VolumeLens comes in

Empty folders won't show up as meaningful space in a storage map, since a map sizes containers by the data inside them — which is itself a useful confirmation that a folder truly is empty rather than just small. VolumeLens is built for the actual space question this article's cousin problems raise — the gigabytes hiding in Docker images, build caches, and forgotten project folders — while a targeted find -empty pass handles the tidiness question this specific article covers.