Why your Rust target folder is so big and how to clean it safely

Q: Does cargo clean delete Cargo.lock or my source code?

No. cargo clean removes only the target directory, or part of it if you pass --release or -p .

Q: Should I commit the target folder to git?

No. cargo new adds /target to .gitignore for this reason.

Updated 15 October 2026

A Rust project's target folder often ends up bigger than everything else in the repository combined. Everything in it can be rebuilt by Cargo, so it is safe to clean. Here is what fills it, how to measure it and how to shrink it.

What is in the target folder

target is Cargo's build output. It holds every dependency compiled for your project, your own binaries and libraries, test binaries, build script output, generated docs and incremental compilation data.

It gets large for a few reasons:

Debug info. The default dev profile includes full debug information, which makes debug builds much larger than release builds of the same code.
One copy per profile and target. target/debug and target/release each hold a full set of compiled dependencies, and cross-compiling adds a folder per target triple.
Incremental data. target/debug/incremental keeps compiler state between builds so small changes rebuild quickly.
Nothing is removed. When you update a dependency, the old compiled version stays next to the new one. Cargo doesn't clean up target on its own.
Different commands, different artifacts. cargo check, cargo clippy, cargo test and your editor's background checks each add their own output.

Sizes vary a lot with the dependency tree. As one real example, the target folder of the SymbolSweep app (a Tauri app) measured 4.3 GB when this guide was written: 2.8 GB in debug and 1.5 GB in release.

Where it lives

Next to the project's Cargo.toml. In a workspace, all members share one target folder at the workspace root.

It can be moved with the CARGO_TARGET_DIR environment variable or build.target-dir in a .cargo/config.toml. To see where a project's output actually goes, run this inside the project:

cargo metadata --format-version 1 --no-deps | grep -o '"target_directory":"[^"]*"'

How to check its size

Inside a project:

du -sh target
du -sh target/* | sort -hr

Cargo can also tell you what cargo clean would remove, without removing anything (supported by recent Cargo versions):

cargo clean --dry-run

Its total is in GiB and counts file sizes, so it won't match du exactly.

To find every Rust target folder under your projects folder, with its size:

find ~/Projects -type d -name target -prune -exec test -f '{}/../Cargo.toml' \; -exec du -sh {} \; 2>/dev/null

The test step keeps only target folders that sit next to a Cargo.toml. Other tools, such as Maven, also use a folder called target, and some projects use the name for something else entirely.

How to clean it safely

Stop any running cargo build, cargo watch or similar first. Then pick how much to remove:

cargo clean                 # the whole target folder
cargo clean --release       # only target/release
cargo clean -p some-crate   # only one package's artifacts

Each of these accepts --dry-run so you can see the size first. Deleting the folder by hand with rm -rf target does the same as cargo clean.

For a lighter clean, delete only the incremental data. The next build is slower, but dependencies don't recompile:

rm -rf target/debug/incremental

What not to delete

Cargo.toml, Cargo.lock and src. cargo clean never touches them.
~/.cargo/bin, which holds the tools you installed with cargo install and, with rustup, the cargo and rustc commands themselves.
~/.rustup, which holds your installed toolchains.

Keeping it smaller

Less debug info makes debug builds smaller, at the cost of less detail in the debugger. In Cargo.toml:

[profile.dev]
debug = "line-tables-only"

The third-party tool cargo-sweep removes old artifacts while keeping recent ones. After cargo install cargo-sweep, cargo sweep --time 30 removes artifacts not used in 30 days.

What happens after

The next cargo build compiles every dependency again, which can take several minutes on a large project. Crate sources come from ~/.cargo/registry, so the rebuild works offline as long as you haven't also cleared that cache. If you have, Cargo downloads the crates again and needs a network connection.

Your editor's rust-analyzer will also re-check the project, so expect it to be busy for a while.

Or let SymbolSweep find it

The free scan in SymbolSweep finds every target folder that sits next to a Cargo.toml in your project folders and lists it in the REBUILD tier, with the project name and how long the project has been idle.

A target folder is held back while cargo or rustc runs in that project, or if Cargo.lock or target/.rustc_info.json changed in the last five minutes. rust-analyzer's background checks don't count as a build.
Deleting a REBUILD row moves it to the Trash, so you can put it back.
~/.cargo/registry is listed separately as a SAFE cache.
A target folder moved elsewhere with CARGO_TARGET_DIR isn't recognized.

Download SymbolSweep for Mac

Scanning is free and never deletes anything. Deleting needs a one-time $12 license for one Mac. Requires macOS 13 or later on Apple silicon. See how it works.

FAQ

Is it safe to delete the target folder in Rust?

Yes. Everything in it is build output that Cargo recreates on the next build. The only cost is the time it takes to recompile.

Does cargo clean delete Cargo.lock or my source code?

No. cargo clean removes only the target directory, or part of it if you pass --release or -p.

Why does my target folder grow back so fast?

Every build, check, test and editor check adds output, and old compiled dependencies are never removed. Reducing debug info in the dev profile helps.

Should I commit the target folder to git?

No. cargo new adds /target to .gitignore for this reason.