If you use more than one JetBrains IDE — IntelliJ IDEA for backend work, WebStorm for a frontend project, PyCharm for a data pipeline — you are not sharing a single cache between them, even though they're built on the same platform. Each product maintains its own complete, independent index, and each one can independently grow into several gigabytes without any of them telling the others.
Where each product's cache lives
JetBrains IDEs store their caches at ~/Library/Caches/JetBrains/, with one subfolder per product and version, like IntelliJIdea2026.2, PyCharm2026.1, WebStorm2026.2. The version number in the folder name matters: upgrading to a new major IDE version does not migrate or delete the previous version's cache folder automatically, so it is common to find two or three years' worth of version-specific cache folders sitting side by side, most of them for IDE versions you no longer even have installed.
du -sh ~/Library/Caches/JetBrains/*
is the fastest way to see the full picture — how many product-version combinations you have, and which ones are actually large.
What's inside a product's cache folder
Each folder contains several categories of derived data:
- Index caches — the searchable index JetBrains builds over your project's source files, dependencies, and libraries, supporting features like Find Usages, code completion, and structural search. This is usually the largest component, and it scales with the size and number of projects you've opened in that IDE.
- Compile server caches — for JVM languages, a separate incremental compilation cache used by the IDE's own build process (distinct from your project's actual build tool output, like a Gradle or Maven build directory).
- Local history — a rolling log of file changes the IDE keeps independent of your version control system, letting you revert recent edits even without a git commit.
- Preview/thumbnail caches for file types the IDE renders inline.
None of this is your actual project data. Every one of these is rebuilt from your source files and configured dependencies the next time the IDE needs it.
Invalidating caches from within the IDE
JetBrains IDEs have a purpose-built menu action for this, and it's generally the better first step compared to deleting files by hand:
File → Invalidate Caches...
This opens a dialog offering to invalidate the current project's caches and restart the IDE, rebuilding indexes from scratch. It's the recommended fix for the classic JetBrains symptom: code that clearly compiles and runs fine, but the editor shows a red squiggly error on a valid import, or autocomplete stops suggesting symbols you know exist. That mismatch between what the IDE's index believes and what's actually true in your code is exactly what a stale index cache produces, and it resolves reliably by rebuilding the index rather than trying to find and fix the specific bad entry.
Deleting old version folders directly
For freeing disk space rather than fixing an editor bug, the more direct approach is removing cache folders for IDE versions you've since upgraded past:
rm -rf ~/Library/Caches/JetBrains/IntelliJIdea2025.1
Confirm first that you're not still running that version — check About in the IDE itself, or simply keep only the folder matching your currently installed version and delete the rest. There's no supported "migrate and clean" command across versions; deleting the older folder is the practical approach.
The related, separate config and plugin data
Cache is not the only JetBrains footprint on disk. ~/Library/Application Support/JetBrains/ holds your actual settings, keymaps, installed plugins, and license state per product version — this is not disposable the way the cache folder is, since deleting it loses your personalisation and plugin installs, not just derived index data. Similarly, ~/Library/Logs/JetBrains/ accumulates log files that are safe to delete but rarely large enough to matter compared to the cache and index data.
Be careful not to conflate the three — Caches (safe, disposable, rebuildable), Application Support (your actual settings and plugins, not disposable), and Logs (safe, disposable, usually small).
A comparison across the three folders
| Folder | Contents | Safe to delete? |
|---|---|---|
~/Library/Caches/JetBrains/<Product><Version> |
Index, compile caches, local history | Yes — IDE rebuilds it |
~/Library/Application Support/JetBrains/<Product><Version> |
Settings, plugins, license state | No — this is your configuration |
~/Library/Logs/JetBrains/<Product><Version> |
Log files | Yes, usually small |
Large projects and remote development add their own overhead
If you work on a particularly large monorepo, or a project with many external library dependencies the IDE has to index (a big Java project pulling in dozens of JARs, or a Python project with a large virtual environment), the index cache for that single project can itself run into multiple gigabytes, disproportionate to everything else in the cache folder. JetBrains IDEs also support excluding specific folders from indexing (right-click a folder in the project tree → Mark Directory as → Excluded), which is worth doing for build output directories, generated code, or large data folders that don't need to be searchable — this both speeds up initial indexing and keeps the resulting cache smaller going forward, rather than something you fix after the fact.
If you use JetBrains' remote development features (running the IDE backend on a remote machine while working from a local thin client), be aware that both ends maintain their own cache — the remote host's cache lives under a similar ~/.cache/JetBrains path on that machine, entirely separate from anything on your Mac, and needs to be managed independently if it's a machine you also have disk pressure on.
A practical routine
du -sh ~/Library/Caches/JetBrains/*to see every product-version combination and its size.- Confirm your currently installed version per product (check About in each IDE).
- Delete cache folders for versions you're no longer running.
- For the current version, use File → Invalidate Caches... from inside the IDE rather than deleting the live cache folder by hand, since the IDE needs to be told to rebuild rather than discovering an empty folder mid-session.
- Repeat this every major IDE upgrade cycle — JetBrains ships new major versions roughly annually, and each one leaves the previous cache behind unless you clean it up.
Where VolumeLens fits in
A developer running IntelliJ, PyCharm, and WebStorm across a few years of version upgrades can easily have half a dozen stale index caches sitting in ~/Library/Caches/JetBrains, each several gigabytes, none of them tied to software still installed. VolumeLens surfaces the whole JetBrains folder and its per-product-version breakdown in a normal scan, so the version you've long since upgraded past doesn't stay invisible. See what else it finds across your Library folder in one pass.