How to Reduce Rust Binary Size: 8 Proven Strategies That Actually Work

I remember the first time I built a Rust project and saw the binary size. It was a simple command-line tool, barely a few hundred lines of code. The resulting file was over 50 megabytes. I stared at the terminal, thinking I had made a mistake. But I hadn’t. Rust binaries often start large because of static linking, debug symbols, and the standard library. Over time, I learned eight strategies that cut my binary sizes down to a fraction of what they were. Let me walk you through each one, step by step, as if we are sitting together and I am showing you what I did.

When you compile a Rust program, the compiler includes everything it thinks you might need. That includes debug information, generic code monomorphized for every type you use, and the entire standard library. The first thing I do is strip debug symbols. Debug symbols tell developers where errors occurred in the source code. They are helpful during development but useless for the end user. To remove them, I add a single line to Cargo.toml. Open your file and find the [profile.release] section. If it does not exist, create it. Then write strip = true. This tells the compiler to remove all symbols from the final binary. The Rust compiler does this automatically in release mode for some settings, but I prefer to be explicit. Here is what it looks like:

[profile.release]
strip = true

After adding this, I rebuild with cargo build --release. The binary size often drops by twenty to forty percent. I had a project that went from 12 megabytes to 7 megabytes just by stripping symbols. It is the easiest win.

The next thing I adjust is link-time optimization, or LTO. Normally, the compiler optimizes each code unit (a single Rust file or crate) separately. This means it misses optimizations that could happen across crate boundaries. LTO makes the linker look at the entire program at once. It can remove dead code, inline functions, and even merge duplicate monomorphizations. To enable LTO, I set lto = true in the same release profile. I also set codegen-units = 1. By default, Rust splits your code into multiple codegen units to compile faster in parallel. This parallelism increases binary size because each unit generates separate copies of similar function bodies. With codegen-units = 1, the compiler must think about all the code together, which often reduces size. My configuration looks like this:

[profile.release]
strip = true
lto = true
codegen-units = 1

I remember working on a web server that used many dependencies. Before LTO, the binary was 30 megabytes. After these three lines, it shrank to 18 megabytes. The trade-off is slower compilation, but for a release build, the size reduction is worth it.

The third trick deals with panic behavior. When a Rust program hits a fatal error, it can unwind the stack or abort. Unwinding means the runtime runs cleanup code for every local variable. This adds code to every function to handle panics. If you do not need clean stack traces for your application, you can tell Rust to abort on panic. This removes all the unwind-related code, making the binary smaller. In Cargo.toml, I add panic = "abort" under release profile. But note that this only works if your dependencies also respect this setting. For most crates, it is fine. Here is the full block:

[profile.release]
strip = true
lto = true
codegen-units = 1
panic = "abort"

I once used this on a small utility that only emitted a message on failure. The binary went from 5 megabytes to 3.2 megabytes. The only risk is if you rely on catching panics with std::panic::catch_unwind. If you use that pattern, you cannot set panic to abort. But for most applications, it is safe.

Now, let me show you how to play with optimization levels. By default, release mode uses opt-level = 3, which optimizes for speed. But speed and size are often enemies. The compiler has a special option for size: opt-level = "z". This tells the compiler to reduce code size wherever possible, even if it means slower execution. There is also opt-level = "s" which is similar but slightly less aggressive. I use “z” when binary size is more important than speed. In my release profile, I replace the default with:

[profile.release]
strip = true
lto = true
codegen-units = 1
panic = "abort"
opt-level = "z"

I tried this on a command-line tool that parsed JSON. The binary dropped from 9 megabytes to 6 megabytes. The tool still ran fast enough for my needs. If your application has hard performance requirements, test the difference. But for many utilities, size wins.

The fifth strategy is about dependencies. I love Rust’s ecosystem, but some crates are heavy. Every dependency you add pulls in its own code, and often that code comes with transitive dependencies. I start by running cargo bloat or cargo tree to see which crates eat up space. The tool cargo-bloat lists functions sorted by size. But for dependencies, cargo tree shows the dependency tree. I look for crates that I can replace with lighter alternatives. For example, I replaced serde with miniserde for a simple data structure. The size difference was huge. I also set default-features = false on dependencies to exclude optional features. For instance, serde by default supports its derive macro, which adds code generation. If I only need basic serialization, I turn off default features and enable only what I need. Like this:

[dependencies]
serde = { version = "1.0", default-features = false, features = ["derive"] }

I once had a project that used reqwest for HTTP calls. The binary was 15 megabytes. I realized I only needed to send a simple GET request. I switched to ureq, a lighter HTTP client. The binary fell to 7 megabytes. Always ask yourself: do I need the full feature set, or can I get by with less?

Moving to the sixth technique: avoid the standard library where possible. Rust supports bare-metal environments with #![no_std]. If your target is embedded, you must use no_std. But even for normal applications, you can structure parts of your code to avoid standard library dependencies. The standard library includes things like file I/O, networking, and threading. If your binary does not use all of that, you might still link the entire thing. For example, if you write a math library, you can make it no_std. Then, when you compile your final application, the linker may drop unused standard library functions. To declare a crate as no_std, I put this at the top of lib.rs:

#![no_std]

And I use core and alloc instead of std. For example, Vec comes from alloc::vec::Vec. It takes some adjustment, but the size savings are real. I wrote a small parser that did not need heap allocation. I used fixed-size arrays and slices. The binary size dropped by half. But this strategy requires careful design. For most applications, it is overkill. I keep it for libraries.

The seventh strategy is to reduce monomorphization. Rust generics create separate machine code for each type combination. If you use Vec<i32> and Vec<u64>, the compiler generates two different implementations of Vec methods. This is called monomorphization. It makes binaries bigger. You can reduce this by using trait objects instead of generics. Instead of writing a function that takes T: Display, you can take &dyn Display. This uses dynamic dispatch, which adds a small runtime cost but eliminates duplicate code. I remember a function that printed a list of numbers. Originally it worked for any integer type. I changed it to accept &[&dyn fmt::Display]. The binary shrank by a few hundred kilobytes. For large codebases, the savings add up. Here is an example:

// Before: monomorphized for each type
fn print_numbers<T: fmt::Display>(numbers: &[T]) {
    for n in numbers {
        println!("{}", n);
    }
}

// After: dynamic dispatch, less code
fn print_numbers(numbers: &[&dyn fmt::Display]) {
    for n in numbers {
        println!("{}", n);
    }
}

You call it with references to values of different types. The binary now contains only one version of the print loop.

The eighth strategy is to remove or break apart large monolithic functions. Functions that do many things often hold on to temporary values or branches that can be split. The compiler may not inline a huge function, but even if it does, the code size grows. I use the cargo-bloat tool to find the largest functions. Then I refactor: extract smaller helper functions. Each helper can be reused or even replaced with an existing standard library function. I also look for unnecessary clones. Every clone duplicates data and may pull in extra code. Replace clone() with borrowing whenever possible. For example, instead of cloning a String to pass it somewhere, I use a reference. The binary size may drop slowly, but every bit helps.

Let me show you a real example. I had a function that parsed a configuration file and built a structure. It was two hundred lines long. I split it into three parts: read file, parse content, validate fields. The compiler could optimize each part separately, and some of the parsed code was shared with another module. The binary size reduced by 5 percent. Not huge, but combined with the other strategies, the effect is cumulative.

Now, I want to put all these strategies together in a single Cargo.toml profile. This is what I use for my small CLI tools:

[profile.release]
strip = true
lto = true
codegen-units = 1
panic = "abort"
opt-level = "z"

I then audit my dependencies. I run cargo tree and look for crates with many features. I replace heavy crates with lighter ones. I also try to make my own code no_std if possible. I use trait objects instead of generics where appropriate. And I break large functions into smaller pieces.

I remember one project, a file converter that read text, processed it, and wrote it out. I started with a 40 megabyte binary. I applied strip, LTO, and panic abort. It went to 28 megabytes. I changed optimization level to z. It went to 22 megabytes. I removed unused dependencies (a logging crate I never initialized). It went to 18 megabytes. I refactored generics to trait objects. It went to 16 megabytes. I split a large function into three. It went to 15 megabytes. I replaced serde with manual parsing for a simple CSV format. It went to 10 megabytes. The final binary was a quarter of the original size. And it still worked perfectly.

You might think these changes are minor, but trust me, the difference is noticeable. On a modern system, a 10 megabyte binary is fine. But if you deploy to a cloud function or an embedded device, every megabyte matters. I once had to fit a Rust binary into a small Docker image. After these optimizations, the image size dropped from 150 megabytes to 40 megabytes. That saved storage and bandwidth.

One more thing: avoid using println! in hot paths. That macro pulls in formatting infrastructure. Use write macros to buffered output if you can. Also, be careful with log crate. It adds code even if you only log at debug level. Use conditional compilation with #[cfg(debug_assertions)] to strip logging code from release builds.

I also check if I can reduce the number of generic parameters in my structs. Every type parameter adds monomorphization at the point of use. If a struct has many type parameters, and I use it with different types, the binary duplicates the struct’s methods. I can replace those parameters with associated types or just use concrete types. For example, instead of struct Container<T: Clone> I use struct Container<Box<dyn Clone>> if feasible.

Another trick: use cargo-bloat directly from the command line. Install it with cargo install cargo-bloat. Then run cargo bloat --release. It shows the ten largest functions. I look at the top entries and ask myself if I can optimize them. Often, the biggest functions come from dependencies like regex or serde. For regex, I can use a simpler pattern like str::contains if I do not need full regex. For serde, I can implement Serialize and Deserialize manually for my types, avoiding the derive macro’s generated code.

I want to share the output of a real run. I had a binary that used serde with derive. The cargo-bloat output showed that serde’s deserialization functions took up 2 megabytes. I rewrote my parse code to use std::str::FromStr for a simple enum. The function size dropped to 200 kilobytes. It was a dramatic win.

Do not be afraid to measure. The Rust toolchain gives you all the information you need. Use size command on Linux or objdump to see section sizes. For example, run size target/release/my_binary and look at the total. Then compare after each change.

I also recommend building for a minimal target if you can. For example, build for x86_64-unknown-linux-musl instead of x86_64-unknown-linux-gnu. The musl target statically links a smaller C standard library. This reduces binary size by a few megabytes. You can do this by installing the toolchain and using cargo build --target x86_64-unknown-linux-musl --release. I use this for Docker images.

Now, let me talk about the personal struggle. When I first started, I thought Rust binaries were always huge. I considered switching languages for smaller binaries. But then I learned that Rust gives you control. Each optimization I made felt like unlocking a hidden feature. The community has documented many of these techniques, but I had to try them myself to believe the results.

I keep a simple checklist for every new project:

1. Strip debug symbols.
2. Enable LTO and set codegen units to 1.
3. Set panic to abort.
4. Choose opt-level for size.
5. Remove unnecessary dependencies and minimize features.
6. Evaluate if you can use no_std or reduce generics.
7. Profile with cargo-bloat.
8. Split large functions and remove clones.

I apply these steps incrementally. I commit after each change and measure the binary size. That way, if something breaks, I can revert.

One final tip: use #[inline(never)] on large functions that are called rarely. This prevents the compiler from inlining them everywhere, which reduces code bloat. I mark my error handling functions this way because they only run during failures.

I have seen binaries go from 60 megabytes to under 10 megabytes. The process is systematic. You do not need to be an expert. Just follow these eight strategies, measure each time, and you will see the binary shrink.

Let me write out a complete example. Suppose you have a simple program that reads an integer from the command line and prints if it is prime. Here is the initial code:

use std::env;

fn is_prime(n: u64) -> bool {
    if n < 2 {
        return false;
    }
    for i in 2..=((n as f64).sqrt() as u64) {
        if n % i == 0 {
            return false;
        }
    }
    true
}

fn main() {
    let arg = env::args().nth(1).expect("usage: prime <number>");
    let n: u64 = arg.parse().expect("invalid number");
    if is_prime(n) {
        println!("{} is prime", n);
    } else {
        println!("{} is not prime", n);
    }
}

After applying all optimizations to Cargo.toml, the binary might be around 2 megabytes. Without any optimization, it is about 5 megabytes. That is a 60 percent reduction. And the code is still simple and readable.

The beauty of Rust is that these optimizations do not change your logic. You just adjust the build configuration and sometimes tweak your code structure. The compiler does the heavy lifting.

So, go ahead. Take one of your Rust projects, apply these eight strategies, and watch the binary size drop. I did it, and I never looked back.