The cargo target folder size of a large Rust project can reach many gigabytes on a Mac. Every Rust project gets a folder called target, where Cargo, Rust's build tool, writes everything it compiles. It's build output, so it's safe to remove: Cargo builds it again, and the only cost is a slower next build.
Two other places add to it. Cargo keeps the crates it downloads in ~/, shared by all your projects, and since Rust 1.88 it trims that cache by itself. rustup keeps every Rust toolchain you install in ~/, and those stay until you uninstall them.
Rust's tools are command-line tools with no app of their own. Target folders and Cargo's download caches are plain folders you can move to the Trash in Finder. Toolchains are the exception: rustup manages them, and it has no button for removing one.
This post goes through each folder, why target folders grow so large, what Cargo's own cleanup removes, and how to keep the space from coming back.
Where Rust keeps its files on a Mac
A standard Rust installation, made with rustup, uses two hidden folders in your home folder and one folder inside each project.
| What | Where it is | What it holds | Level |
|---|---|---|---|
| Target folders | target in each project | Everything Cargo built for that project | Safe |
| Registry cache | ~/.cargo/registry | Crates downloaded from crates.io, packed and unpacked | Safe |
| Git dependencies | ~/.cargo/git | Repositories cloned for crates that come from Git | Safe |
| Toolchains | ~/.rustup/toolchains | Compilers, Cargo and standard libraries, one folder per version | Review first |
| Commands and programs | ~/.cargo/bin | Rust's own commands and programs installed with Cargo | Leave alone |
| Settings | ~/.cargo/config.toml and credentials.toml | Cargo's settings and your registry logins | Leave alone |
A crate is Rust's word for a package. Cargo downloads crates from crates.io, the public registry, or from Git repositories, and builds them together with your own code.
How do you open these folders in Finder?
Folders whose names start with a dot are hidden in Finder, so you won't see ~/ or ~/ in your home folder. You can still open them directly.
- In Finder, choose Go › Go to Folder.
- Type
~/or.cargo ~/. The tilde stands for your home folder..rustup - Press Return.
Target folders aren't hidden. Each one sits next to its project's Cargo.toml file, wherever you keep your code.
To see a folder's size, select it and choose File › Get Info. For a folder full of projects, choose View › as List, then View › Show View Options, and select Calculate all sizes, so each project's size appears in the Size column.
Where does Rust show up in Storage settings?
Not by name. System Settings › General › Storage has no category for developer tools. Apple describes Documents as the files in your home folder that aren't in another category, and that's where project folders, target folders included, are usually counted.
Hidden folders such as ~/ and ~/ usually land in System Data instead, with everything else Storage settings can't name. The System Data guide explains what else ends up there. Storage settings and the Finder steps here are the same in macOS 26 Tahoe and macOS 27.
How much space does Rust use?
It depends on how many projects you build and how long you've been building them. The research behind the app's catalog puts Rust's total at 5 to 100 GB on Macs that use it, and more on some.
Toolchains are easier to pin down, because every copy of a release is the same. Here's what one toolchain's files add up to, for the current stable release on a Mac with Apple silicon.
- Documentation (rust-docs)740 MB · Review first
- Compiler (rustc)280 MB · Review first
- Standard library (rust-std)152 MB · Review first
- Cargo33 MB · Review first
- Clippy14 MB · Review first
- rustfmt6 MB · Review first
The sizes of the files in each component's download for Rust 1.99, released on 1 October 2026, for Apple silicon, added up on 15 October 2026. rustup's default profile installs all six, about 1.2 GB together. The documentation is about 66,000 small files, which take somewhat more on disk.
So a toolchain is roughly 1.2 GB, and most of that is a local copy of Rust's documentation. Every extra toolchain you keep adds about as much again.
Why the cargo target folder size keeps growing
A target folder doesn't hold one build of your project. It holds every build Cargo has made of it, with all its dependencies, in every configuration you've used. Cargo never removes the old ones by itself.
What's inside a target folder?
Cargo's documentation describes the layout. The top level is sorted by how you built:
| Folder | What Cargo puts there |
|---|---|
debug | Development builds, made when you build, run or test |
release | Optimized builds, made with the release option |
doc | Documentation generated by Cargo's doc command |
package | Packages prepared for publishing to crates.io |
debug/deps | Compiled dependencies and other build files |
debug/incremental | The compiler's incremental cache |
debug/build | Output of build scripts |
| A folder named after a platform | Builds for another platform, with their own debug and release folders |
The release folder is organized the same way, though without an incremental cache unless you turn one on. If you build for Intel Macs as well as Apple silicon, for example, Cargo adds an x86_64-apple-darwin folder with a complete second set of builds.
Cargo's documentation calls the intermediate files internal and says their layout can change between versions. For space, what matters is that all of it is made by Cargo and the compiler, from your code and your dependencies.
Why doesn't Cargo replace old builds?
Cargo names many build files after a hash of how they were built: the compiler version, the profile, the enabled features and more. Builds made with different settings get different names, so they sit side by side instead of replacing each other.
That's what makes switching back fast: change a feature and change it back, and the first build is still there. It also means the folder only grows:
- Every Rust update starts a fresh set of builds, because the compiler version is part of that hash. The previous set stays.
- Every dependency upgrade adds the new version's build next to the old one.
- Every feature combination and profile you try adds its own copy.
- Tests, benchmarks and examples are built separately from the program itself.
A project you've worked on through a year of Rust releases can carry several complete sets of builds, of which only the newest is used.
How much do debug information and incremental builds add?
By default, Cargo's development profile includes full debug information and keeps an incremental cache, which lets the compiler reuse work after small changes. Both make development faster, and both take space. The release profile turns both off.
In August 2026, the Cargo team measured the target folder of one large project, Cargo itself, in four development configurations:
| Development build of Cargo | Target folder |
|---|---|
| Debug information and incremental cache, Cargo's default | About 3.3 GB |
| Debug information, no incremental cache | About 2.2 GB |
| Incremental cache, no debug information | About 1.5 GB |
| Neither | About 1.0 GB |
The measurements were made on Linux, so a Mac's numbers differ, but the proportions show where the space goes: Cargo's defaults took more than three times the space of a bare build, and debug information alone was over half.
The same post describes a change being tested in nightly Rust that stops storing each library's metadata twice. It made target folders 5 to 33 percent smaller in their tests, but the Cargo team says it isn't currently headed for stable Rust.
Does your editor add to it?
Usually, yes. rust-analyzer, the language server that VS Code, Zed and many other editors use for Rust, runs Cargo's check command each time you save a file, and runs build scripts and procedural macros when it opens a project. All of that writes into the project's target folder.
rust-analyzer can be set to use a target folder of its own, so it doesn't wait for your builds. Its documentation notes the cost: the build files are duplicated. If you've turned that setting on, expect each project to keep two sets.
It also means a target folder can come back the moment you delete it, if the project is open in your editor.
Workspaces keep one target folder
A workspace is a group of crates built together, such as a program and the libraries it's split into. Cargo puts one target folder at the root of the workspace, not one per crate, and building any member uses it.
So a large workspace has one large target folder rather than many small ones, which makes it easy to find and easy to clear.
Is it safe to delete a Rust target folder?
Yes. Everything in it was made by Cargo from your code and your dependencies, and Cargo makes it again the next time you build. Your source files, your Cargo.toml and your Cargo.lock are outside it and aren't touched.
What does deleting it cost?
- Time. The next build of the project is a full build, with every dependency compiled again. For a large project, that can take minutes instead of seconds.
- Programs you built. Anything you run from the project's
debugorreleasefolder is gone until you build it again. If you rely on one, copy it somewhere else first, or install it with Cargo. - Documentation you generated. Cargo's doc command makes it again.
- Usually no downloads. Cargo builds from the crates in its shared cache and downloads only what isn't there.
How do you delete a target folder in Finder?
- Close the project in your editor, and make sure nothing is building.
- In Finder, open the project's folder: the one with the
Cargo.tomlfile in it. - Select the
targetfolder and choose File › Move to Trash. - Empty the Trash when you're sure you don't need it back.
Until you empty the Trash, you can put the folder back if you change your mind. If Time Machine is on, a local snapshot may keep the old files for up to 24 hours, but macOS counts that space as available and removes snapshots sooner when it needs room.
What does cargo clean remove?
Cargo has its own command for this, cargo clean. With no options it does the same as moving the target folder to the Trash, except that it deletes at once, with nothing to put back. It has no app or button. Its options decide how much goes:
| How it's run | What it removes |
|---|---|
| With no options | The whole target folder |
| With the release option | Only the release builds |
| With the doc option | Only the generated documentation |
| With a profile's name | Only the builds of that profile |
| With a package's name | Only that package's builds, such as one dependency |
| With a platform's name | Only the builds for that platform |
| With the dry-run option | Nothing: it shows a summary of what would go |
The release option suits a project whose optimized builds are large while its development builds are in daily use. Clearing one package's builds removes just that package's files and leaves the rest in place.
Two of the options match folders you can see in Finder. Moving the release or doc folder to the Trash does what the release and doc options do, with the Trash to fall back on.
How do you find every target folder on your Mac?
Finder's search can find them by name.
- Open a Finder window.
- Type
target kind:folderin the search field, then press Return. - Select a result and choose File › Get Info to see its size.
- To see the project around it, open the folder and choose Go › Enclosing Folder.
Get Info is the quickest way to compare them. The results include any folder with "target" in its name, which brings up the next point.
A target folder is Rust's only if a Cargo.toml file sits next to it. Maven, the build tool for many Java projects, also puts all its build output in a folder called target, next to a pom.xml file. Other projects use the name for their own files.
Which target folders should go first?
- Projects you no longer work on. Their target folders are pure leftovers, and often large, because they hold builds from older compilers.
- Projects you haven't built since a Rust update. Their next build starts over anyway, so clearing them costs nothing extra.
- Release folders of projects you build in development mode from day to day.
- Projects you work on every day come last, because each one costs you a full build.
Cargo's caches in ~/.cargo
~/ is Cargo's home folder. Part of it is a cache shared by every project you build, and part of it is settings and programs that aren't a cache at all.
What's in the registry folder?
~/ holds what Cargo downloads from crates.io and any other registry you use, in three parts:
index: information about each crate's versions and dependencies, which Cargo uses to choose versions.cache: the downloaded.cratefiles, compressed archives of each crate's source code.src: the same crates unpacked, which is what the compiler reads.
So every crate you've used is stored twice, once packed and once unpacked. Cargo's documentation says it recovers from anything missing here, by unpacking an archive again or downloading the crate again.
What's in the git folder?
Some projects depend on crates straight from a Git repository instead of crates.io. Cargo clones each repository into ~/, then checks out the commits your projects use into ~/, one folder per commit.
Several commits of one repository can be checked out at once, so a dependency that moves often leaves a folder for each commit a project has used.
Does Cargo clean its cache by itself?
Since Rust 1.88, released in June 2025, yes. Cargo removes files it downloaded that haven't been used in three months, and files it got from your own Mac that haven't been used in one month. By default it checks at most once a day.
Two exceptions. The cleanup doesn't run when Cargo works offline. And Cargo 1.78 and later record when each file is used, so if you also build with an older Cargo, the crates only it uses look unused. The Rust team suggests turning automatic cleanup off in that case, with a setting in Cargo's configuration.
With a Rust older than 1.88, Cargo never removes anything from these folders by itself. They grow with every crate version any of your projects has used.
Is it safe to delete ~/.cargo/registry?
Yes. It's a cache, and Cargo downloads or unpacks what each project needs the next time it builds. The cost is time and a network connection, and offline builds fail until the crates are back.
- Make sure nothing is building, and close Rust projects in your editor.
- In Finder, choose Go › Go to Folder, type
~/and press Return..cargo - Move the registry folder to the Trash, and the git folder too if you like.
- Empty the Trash when you're sure.
For a smaller step, open registry and move only its src folder. Cargo unpacks crates again from the archives in cache, without downloading anything.
What should stay in ~/.cargo?
bin: Rust's own commands live here, includingcargo,rustcandrustup, along with any program you installed with Cargo. Remove it and Rust stops working.config.toml: your Cargo settings, if you've made any.credentials.toml: the login tokens for registries, saved when you log in to publish crates..crates.tomland.crates2.json: Cargo's record of the programs it installed. Cargo's documentation says not to edit them by hand.
So never move ~/ to the Trash as a whole. Programs you installed with Cargo are removed with Cargo's own uninstall command, which, like the rest of Cargo, has no button.
Rust toolchains in ~/.rustup
rustup, Rust's installer, keeps every toolchain you install in ~/, one folder each. A toolchain is one version of Rust: the compiler, Cargo, the standard library and their tools.
Why do old toolchains pile up?
- Dated nightlies. Each nightly pinned to a date is a separate toolchain, named after its date.
- Pinned versions. A project can name a Rust version in a
rust-toolchain.tomlfile, and rustup installs that version for it, alongside your usual stable one. - Updates replace, pins don't. Updating the stable toolchain replaces it, but a toolchain named for a version or a date never changes, so it stays until you uninstall it.
rustup doesn't remove a toolchain because you've stopped using it. At about 1.2 GB each, a few forgotten ones add up.
Can you remove a toolchain in Finder?
No. rustup manages that folder, and keeps other files about each toolchain elsewhere in ~/. Its uninstall command is the supported way to remove a toolchain. It's a command-line tool with no app or button, and the app doesn't remove toolchains for you either.
Before you remove one, check your projects. A project with a rust-toolchain.toml file names the toolchain it needs. By default, rustup installs a project's toolchain again when it's missing, so removing one costs a download, but targets and components you added to it by hand aren't restored.
What are targets and components?
A target is the standard library for another platform, such as Intel Macs or iPhones, which you add to build for that platform. A component is an extra part, such as rust-analyzer or the source code of the standard library, which rust-analyzer reads.
Both live inside the toolchain's folder and add to its size. rustup can remove a target or component from a toolchain you keep, again with a command.
Which profile did you install?
rustup installs toolchains with a profile. The minimal profile has the compiler, the standard library and Cargo. The default profile adds the documentation, rustfmt and Clippy.
The chart above shows why that matters: the documentation is about 740 MB of a 1.2 GB toolchain. If you never read Rust's documentation offline, a toolchain installed with the minimal profile, or with the documentation removed, is less than half the size.
What if Rust came from Homebrew?
Homebrew can install Rust in two ways. Its rust formula installs one version of Rust into Homebrew's own folder, where Homebrew upgrades and removes it like any other formula. Its rustup formula installs rustup, which keeps toolchains in ~/ as described here.
Either way, Cargo's caches and your target folders work the same. The post on Homebrew's disk space covers Homebrew's side.
What about removing Rust entirely?
rustup's documentation names its self-uninstall command as the way to remove Rust from your Mac completely. Target folders inside your projects aren't part of it, so move those to the Trash yourself afterwards.
Time Machine, iCloud Drive and Rust's folders
Cargo already keeps its build files out of your backups. On a Mac, it marks each target folder it creates, and its registry and git folders, as excluded from Time Machine. It also writes a small CACHEDIR.TAG file in each, which other backup tools recognize.
Are target folders in Time Machine backups?
Not if Cargo created them. Target folders have been marked this way since 2019, and Cargo's registry and git folders since Rust 1.62, in 2022. Cargo marks the folders themselves, so there's nothing to add in Time Machine's options.
Toolchains in ~/ aren't marked, so Time Machine backs them up like any other folder. rustup can download them again, so if your backup disk is short of space, they're a reasonable thing to exclude in System Settings › General › Time Machine, under Options.
Do local snapshots still include them?
Yes. Apple notes that excluded items still appear in Time Machine's local snapshots on your Mac. The space is still yours to use: macOS counts it as available, and removes snapshots after 24 hours, or sooner when it needs room.
What about projects in iCloud Drive?
If your code is in iCloud Drive, including Desktop and Documents when they sync, iCloud uploads whatever is there. Since Rust 1.96, released in May 2026, Cargo also marks the target folders it creates as excluded from iCloud Drive sync.
Cargo marks a target folder only when it creates it. A target folder made by an older version of Cargo isn't marked and keeps syncing, until you remove it and let Cargo build it again.
Keeping target folders smaller
Removing target folders frees space once. These settings change how much comes back. Each is a line in a project's Cargo.toml or in Cargo's settings file, not something you run, and each has a cost.
Share one target folder between projects
Cargo's build.target-dir setting, in ~/, sends every project's builds to one folder. Projects can then reuse dependencies they've built with the same settings, instead of each building its own copy.
The catch is that one project's builds can't be cleared without the others', since they share files, and builds of different projects wait for each other. Cargo's documentation points to a separate tool, sccache, for sharing compiled code between projects without sharing a folder.
Put the build files somewhere else
Since Rust 1.91, a build.build-dir setting moves the intermediate files, such as compiled dependencies and the incremental cache, to another folder. Your finished programs and documentation stay in each project's target folder.
The setting can name a separate folder for each project, using a hash of the project's path, so projects don't collide. Pointed at one folder outside your projects, it keeps them small and puts the bulk of every build in one place to clear. If you point it at an external drive, keep the drive connected while you build.
Use less debug information
In the Cargo team's measurements above, debug information was more than half of the folder. Setting a profile's debug option to line tables only keeps file names and line numbers in backtraces but drops the rest, at the cost of seeing fewer variables in a debugger.
Cargo can also set this for dependencies alone, through a profile override that applies to every package except your own. Your code keeps full debug information, and the dependencies you rarely step through take less space.
Turn off the incremental cache
The incremental cache speeds up rebuilds after small changes, and the measurements above show it can be a third of the folder. Turning it off in the development profile saves that space and makes each rebuild slower. Whether that's worth it depends on how often you rebuild.
Clear old builds after a Rust update
Builds made by the previous compiler stay in each target folder after you update Rust, and the next build doesn't use them. Clearing target folders right after an update costs nothing extra, because each project rebuilds from scratch anyway.
Other languages have the same pattern of per-project build folders. The post on freeing disk space on a developer's Mac covers the rest of them, from Xcode to Docker.
What to clear first: a decision table
The right order depends on why you're looking. This table starts from the situation.
| Situation | What to clear | What it costs |
|---|---|---|
| The disk is nearly full | Target folders of old projects | A full build if you return to one |
| You just updated Rust | Target folders of every project | Nothing extra: the next build starts over anyway |
| One project's release builds are large | That project's release folder | A slower next release build |
| Many old nightlies or pinned versions | Toolchains no project names, with rustup | A download if a project needs one again |
| Rust older than 1.88, years of use | ~/.cargo/registry and ~/.cargo/git | Crates download again as projects need them |
| You're done with Rust | Everything, with rustup's uninstall, then the target folders | Installing Rust again to build anything |
Target folders nearly always come first. Each one can reach many gigabytes, and removing it costs only build time.
When to leave a target folder alone
Keep the target folder of a project you're about to ship, test or benchmark, so you don't wait for a full build at the wrong moment. And keep any folder you've put files of your own into: everything in a target folder is supposed to be Cargo's, but nothing stops a script from saving there.
How often should you look?
After each Rust update is a natural moment, since old builds become dead weight then. Otherwise, every few months, or when System Data or Documents grows for no clear reason, is enough for most people.
Mistakes to avoid
Rust's folders look like ordinary folders in Finder, and most of the trouble comes from tidying the wrong one.
Don't move ~/.cargo to the Trash as a whole
It holds Rust's commands, your settings and your registry logins as well as the caches. Move only the registry and git folders inside it.
Don't delete a target folder during a build
Cargo and your editor write into it while they work, and removing it partway through can make that build fail. Wait until the build finishes, and close the project in your editor first, or it starts filling the folder again straight away.
Don't remove every folder called target
Other tools use the name, Maven among them, and some projects keep their own files in a folder called target. Check for a Cargo.toml beside it first.
Don't delete toolchain folders in Finder
rustup keeps its own files about each toolchain, outside the toolchain's folder. Uninstall toolchains with rustup, and keep the ones your projects name.
Don't paste cleanup commands from a web page
Cargo's and rustup's cleanups are commands, but a command copied from a web page can do more than it says. The steps that free the most space here, removing target folders and Cargo's download cache, work in Finder, with the Trash to fall back on.
How the app does it
Wombit finds Rust's target folders, Cargo's caches and rustup's toolchains, explains each one, and shows its size, with hard links and APFS clones counted once. A folder called target counts as Rust's when a Cargo.toml file sits beside it. Select one on the map to see what it is and what removing it costs.
Target folders, Cargo's registry cache and its Git dependencies are Safe: they start checked in Cleanup, count toward the safe total, and go to the Trash, where Put Back returns them. Toolchains are Review first, and the app doesn't remove them: it explains what each one is and leaves uninstalling to rustup.
~/
**/ target Build output that Cargo creates in each Rust project, including compiled code, binaries and documentation.
Safe · Moves it to the Trash
~/
.cargo/ registry Crates that Cargo, Rust's package manager, has downloaded from crates.io, with their unpacked source code.
Safe · Moves it to the Trash
~/
.cargo/ git Git repositories that Cargo has cloned for Rust dependencies that come from Git instead of crates.io.
Safe · Moves it to the Trash
~/
.rustup/ toolchains/ * Versions of the Rust compiler, Cargo and the standard library that rustup has installed, one folder for each toolchain.
Review first · Explained only: never removed
Seeing all of this is free. Moving folders to the Trash in Cleanup is PRO: one payment of $4.99 with lifetime access. Every Pro tool's review is free to open, so you see what would go and why before you buy.
Frequently asked questions
How do I check the size of a Rust project's target folder on a Mac?
In Finder, select the target folder next to the project's Cargo.toml file and choose File › Get Info. To compare several projects, open the folder that holds them in List view, choose View › Show View Options and select Calculate all sizes.
Does cargo clean delete my source code?
No. It removes only the target folder, or the part of it you name, such as the release builds. Your source files, Cargo.toml and Cargo.lock are outside the target folder and aren't touched.
Why is my target folder bigger than the rest of my project?
It holds compiled copies of every dependency, with full debug information and an incremental cache by default, and it keeps builds from earlier compilers, features and profiles side by side. Cargo never removes those old builds by itself.
Can I delete the whole ~/.cargo folder?
No. Besides the registry and git caches, it holds Rust's own commands in its bin folder, your Cargo settings and your registry logins. Move only the registry and git folders to the Trash; Cargo downloads what it needs again.
Does Cargo delete old crates automatically?
Since Rust 1.88, yes. Cargo removes downloaded files it hasn't used in three months, and files from your own Mac it hasn't used in one month, checking at most once a day by default. It doesn't clean up while working offline, and it never cleans target folders.
How much disk space does a Rust toolchain take?
About 1.2 GB with rustup's default profile, for Rust 1.99 on Apple silicon. Roughly 740 MB of that is the offline documentation, so a toolchain installed with the minimal profile is less than half the size.
Does Time Machine back up Rust target folders?
Not when Cargo created them. Cargo marks target folders, and its registry and git caches, as excluded from Time Machine, and since Rust 1.96 it also excludes new target folders from iCloud Drive sync. Toolchains in ~/.rustup aren't marked.
Will my next build be slower after deleting the target folder?
Yes, once. The next build compiles the project and all its dependencies again, which can take minutes for a large project. After that, builds are as fast as before.