Why Rust's target directory grows so large

Ten projects, ten target directories, forty gigabytes. Here is what is actually in there and how to keep it bounded without giving up incremental builds.

Updated 2026-08-13

What is in there

target/ is entirely reproducible from your source and your lockfile. Deleting it cannot lose work. The reason it gets big is that Cargo keeps far more than the binary you asked for.

Contents	Why it is large
Every dependency, compiled	A tree of 300 crates compiles to 300 rlibs — for each profile.
Debug symbols	Unstripped debug binaries are routinely 10–50× the size of a release build.
Incremental compilation state	Per-crate fingerprints and cached fragments under target/debug/incremental.
One directory per profile	debug, release, and any custom profile, each a full copy.
One directory per target triple	Cross-compiling doubles or triples the whole thing.
Test and bench binaries	Every integration test is its own linked executable.

None of that is a leak. It is the price of incremental builds, and it is usually a good trade — until you have thirty repositories on disk and twenty-nine of them have not been touched since spring.

Find where it went

$ du -sh target

One project.

$ find ~/dev -maxdepth 3 -type d -name target -prune -exec du -sh {} + | sort -h

Every target directory under ~/dev, smallest to largest. Adjust the path and depth to your layout.

$ cargo clean --dry-run

Shows what would be removed without removing it. Available in recent Cargo versions.

Clean, from gentlest to bluntest

$ cargo clean -p my-crate

Removes artefacts for one package only, keeping every dependency compiled. Usually all you need after a version bump.

$ cargo clean --release

Removes only the release profile. Keeps your fast incremental debug builds intact.

$ rm -rf target/debug/incremental

Removes only the incremental state. Frequently 30–50% of a debug directory, and it rebuilds transparently.

$ cargo clean

Everything. The next build is cold — minutes on a large dependency tree.

Prefer cargo clean over rm -rf target when the project is on disk: Cargo knows about custom target directories set through CARGO_TARGET_DIR or config.toml, and a blind rm will miss them.

Across many projects at once

cargo-sweep understands which artefacts belong to toolchains you no longer use — the safest bulk cleaner:

$ cargo install cargo-sweep

One-off install.

$ cargo sweep --time 30 --recursive ~/dev

Removes artefacts not accessed in 30 days across every project under ~/dev. Keeps recent work fast.

$ cargo sweep --installed --recursive ~/dev

Removes artefacts built by toolchains that are no longer installed. Pure waste, zero downside.

Keeping it bounded

The single most effective change is a shared target directory. One compiled copy of serde instead of thirty.

$ echo -e "[build]\ntarget-dir = \"$HOME/.cargo/shared-target\"" >> ~/.cargo/config.toml

Every project builds into one shared directory. Dependencies compiled once are reused everywhere.

$ rm -rf ~/.cargo/registry/src

Extracted crate sources. Cargo re-extracts from the .crate archives on demand. Safe, and often 1–3 GB.

A shared target directory serialises builds across projects — two cargo build runs in different repositories will now block on the same lock. On a laptop where you build one thing at a time, that is invisible. In CI, keep them separate.

debug = 1 in [profile.dev] halves debug info size with almost no loss in backtrace quality.
split-debuginfo = "unpacked" on macOS keeps symbols out of the binaries themselves.
Adding target/ to .gitignore is standard — but check it is there, because a committed target directory is a special kind of bad day.

Is it safe to delete target/?

Always. It contains no source and no configuration, and it is rebuilt from your source and Cargo.lock. The only cost is one cold build.

Why is my debug build so much bigger than release?

Debug symbols and incremental compilation state. A release build strips most of it and does not keep incremental fragments by default.

Does a shared target directory break anything?

It serialises concurrent builds behind one lock, and it makes 'delete this project's artefacts' harder. For a single developer machine the space saved is usually worth both.

Should I delete ~/.cargo/registry?

The `src` subdirectory, yes — it is extracted from archives you still have. Deleting `cache` means re-downloading every crate, which is slower and less polite to crates.io.

The automated version

Everything above works, costs nothing, and will keep working. Loupe does the same across every project on your disk at once, and shows what each deletion will cost to rebuild before you agree to it.

Coming soonLoupe

Related guides