How to Match a String in Rust: String vs &str in match Expressions

By the end of this page, you will understand why String and &str are different types in Rust, why string literals work differently in match, and how to correctly match a String by converting or borrowing it as &str. You will also see common patterns used in real Rust code.

In Rust, String and &str are related but different types.

• String is an owned, growable string stored on the heap.
• &str is a borrowed string slice, which is a view into string data.
• String literals like "hello" have type &'static str.

This matters in match because match patterns must match the type of the value being matched.

When you write:

match stringthing {
    "a" => println!("0"),
    // ...
}

Rust expects each pattern to match a String, because stringthing is a String. But "a" is a &str, not a String, so the types do not match.

Your second attempt fails for a different reason: patterns in match are not general expressions. creates a value at runtime, but match patterns must follow pattern syntax, not arbitrary function calls.

Think of String as a full book you own, and &str as a page reference pointing to text inside that book.

• A String owns the text.
• A &str borrows access to some or all of that text.
• A string literal like "a" is already a borrowed piece of text.

match wants the thing on the left and the patterns on the right to speak the same language.

If you try to compare:

• owned book (String)
• page reference (&str)

Rust says: these are not the same type.

So the fix is simple: borrow the String as &str, then match it against string literals, which are also &str.

The most common way to match a String against literals is to convert it to &str first.

Recommended syntax

fn main() {
    let stringthing = String::from("c");

    match stringthing.as_str() {
        "a" => println!("0"),
        "b" => println!("1"),
        "c" => println!("2"),
        _ => println!("other"),
    }
}

Why this works

• stringthing.as_str() gives a &str
• "a", "b", and "c" are also &str
• Now the matched value and the patterns have compatible types

Another valid form

Consider this example:

fn main() {
    let stringthing = String::from("b");

    match stringthing.as_str() {
        "a" => println!("0"),
        "b" => println!("1"),
        "c" => println!("2"),
        _ => println!("other"),
    }
}

Here is what happens step by step:

1. String::from("b") creates an owned String containing b.
2. stringthing.as_str() creates a borrowed &str view into that string.
3. match compares that &str against each pattern in order.
4. "a" does not match.
5. "b" matches.

Matching strings is common in Rust programs whenever text input determines behavior.

Command-line tools

fn handle_command(command: String) {
    match command.as_str() {
        "start" => println!("Starting..."),
        "stop" => println!("Stopping..."),
        "status" => println!("Checking status..."),
        _ => println!("Unknown command"),
    }
}

Parsing user input

A menu selection entered as text can be matched against known options.

API routing or action selection

A small internal service might use string-based action names like "create", "update", or "delete".

Configuration values

fn set_mode(mode: String) {
    match mode.as_str() {
        "debug" => (),
         => (),
        _ => (),
    }
}

In real Rust projects, developers usually avoid taking ownership unless needed. That means they often work with &str for matching.

Common pattern: accept &str in functions

fn handle_status(status: &str) {
    match status {
        "ok" => println!("All good"),
        "error" => println!("Something went wrong"),
        _ => println!("Unknown status"),
    }
}

Then you can call it with either a string literal or a String:

fn main() {
    let s = String::from("ok");
    handle_status(&s);
    handle_status("error");
}

Guard clauses and validation

fn parse_role(role: &str) {
     role {
         => (),
         => (),
         => (),
        _ => (),
    }
}

1. Matching a String directly against string literals

This does not work:

let value = String::from("a");

match value {
    "a" => println!("A"),
    _ => println!("Other"),
}

Why

• value is a String
• "a" is a &str
• match patterns require compatible types

Fix

match value.as_str() {
    "a" => println!("A"),
    _ => println!("Other"),
}

2. Using function calls as patterns

This is invalid:

 value {
    ::() => (),
    _ => (),
}

String vs &str

match vs if/else for strings

Quick rules

• String is owned text
• &str is a borrowed string slice
• String literals like "abc" are &str
• In match, patterns must match the value's type
• To match a String against literals, convert it to &str

Most common solution

match my_string.as_str() {
    "a" => println!("A"),
    "b" => println!("B"),
    _ => println!("Other"),
}

Alternative

match &my_string[..] {
    "a" => println!("A"),
    _ => println!("Other"),
}

Not valid

match my_string {
     => (),
    _ => (),
}

Why can't I match a String directly with "text" in Rust?

Because String and &str are different types. A string literal like "text" is a &str, so you need to borrow the String as &str first.

What is the easiest way to convert String to &str?

Use .as_str():

my_string.as_str()

Why does String::from("a") not work in a match arm?

Because match arms use patterns, not arbitrary expressions. String::from("a") is a function call expression.

Should I use match or if for strings in Rust?

Use match for multiple exact cases. Use if for one simple comparison or more complex boolean conditions.

• String — the owned string type you store and modify.
• &str — the borrowed string slice type used by string literals and many APIs.
• Borrowing — explains how Rust lets you read data without taking ownership.
• Ownership — helps explain why String behaves differently from &str.
• Pattern matching — the core feature behind match expressions.
• Enums — a safer alternative when matching a fixed set of known values.
• if and if let — useful alternatives when full pattern matching is unnecessary.
• String slices — important for understanding as_str() and &string[..].
• Exhaustive matching — explains why match often needs a _ arm.