Rust: error[E0433]: failed to resolve: use of undeclared crate or module

The exact error string

use serde::Serialize;

// error[E0433]: failed to resolve: use of undeclared crate or module `serde`
//  --> src/main.rs:1:5
//   |
// 1 | use serde::Serialize;
//   |     ^^^^^ use of undeclared crate or module `serde`

// a close relative you'll also see, for a type rather than a crate/module:
// error[E0433]: failed to resolve: use of undeclared type `Foo`

// and the sibling error code for the same underlying problem, reported
// specifically on a `use` statement:
// error[E0432]: unresolved import `serde::Serialize`
//   |
//   = help: no external crate `serde`

All three point at the same class of problem — a path segment the compiler can't locate — from slightly different code shapes. See the comparison table below for exactly which one you'll get where.

Cause 1: the crate isn't in Cargo.toml

By far the most common cause. Using an external crate requires it to be listed as a dependency — the 2018 edition removed the old extern crate foo; requirement, but the crate still has to be declared somewhere, and that somewhere is now Cargo.toml:

# Cargo.toml
[dependencies]
# serde = "1"   ← ❌ missing entirely, or commented out

# Cargo.toml — ✅
[dependencies]
serde = { version = "1", features = ["derive"] }

After editing Cargo.toml, run cargo build — Cargo resolves and fetches the new dependency automatically; you don't run a separate "install" step the way npm or pip require.

Cause 2: a local module never declared with mod

Rust does not auto-discover module files from the filesystem. Creating src/utils.rs does nothing on its own — every module has to be declared explicitly with mod name; somewhere in its parent (usually main.rs or lib.rs for a top-level module):

// src/main.rs
// mod utils;   ← ❌ missing — src/utils.rs exists but was never declared

fn main() {
    utils::greet();
    // error[E0433]: failed to resolve: use of undeclared crate or module `utils`
}

// src/main.rs
mod utils;   // ✅ tells the compiler src/utils.rs (or src/utils/mod.rs) is part of the crate

fn main() {
    utils::greet();
}

This is the case that surprises people most, because the file genuinely exists on disk and compiles on its own with no complaint — it's simply not part of the crate's module tree until something declares it with mod. The same rule applies one level deeper: a submodule inside utils/ needs its own mod declaration inside utils.rs (or utils/mod.rs).

Cause 3: wrong path form (2018+ edition rules)

Since the 2018 edition, paths inside a module are resolved relative to that module by default, which changes how you reference sibling items compared to the old 2015-edition rules:

// src/foo.rs
mod bar;

fn run() {
    // bar::Thing   ← ✅ this resolves fine, `bar` is a direct child module

    // crate::foo::bar::Thing   ← ✅ also fine, `crate::` is an explicit absolute path
}

If you're porting old 2015-edition code (which needed extern crate and different relative-path defaults) or copying a path from a different module's context, the segment that resolved there may not resolve here. When a relative path doesn't work, an absolute one starting with crate:: almost always does — it's unambiguous and worth reaching for first when debugging a stubborn E0433.

Cause 4: gated behind a disabled #[cfg(...)] or optional dependency

An optional crate dependency, or a module behind a feature flag, doesn't exist in a build where that feature isn't enabled — referencing it unconditionally fails only in the configurations without it:

# Cargo.toml
[dependencies]
tokio = { version = "1", optional = true }

[features]
async = ["tokio"]

use tokio::runtime::Runtime;
// error[E0433]: failed to resolve: use of undeclared crate or module `tokio`
// (only when built WITHOUT --features async)

The fix is either to build with the feature enabled (cargo build --features async), or — if the code should compile either way — gate the use and its call sites with the matching #[cfg(feature = "async")] so they're consistent with the dependency's own gate.

E0433 vs E0432 vs E0425

Debugging checklist

• ✓ External crate? Confirm it's listed under [dependencies] in Cargo.toml, not just imagined
• ✓ Local module? Confirm a mod name; declaration exists in its parent file
• ✓ Double-check spelling and case — crate names on crates.io are case-sensitive in Cargo.toml
• ✓ Try an absolute path starting with crate:: to rule out a relative-path mistake
• ✓ Optional dependency? Check whether the required feature is enabled for this build
• ✓ Path has no :: at all? Wrong page — that's E0425
• ✓ Still stuck? cargo tree confirms whether the dependency actually resolved into your build at all