Rust String vs str: Differences, Uses, and When to Choose Each

By the end of this page, you will understand how Rust represents text with both String and str, why they are different types, and how ownership and borrowing affect string handling. You will also learn when to use String, when to use &str, and why neither type is being deprecated.

Rust has multiple string-related types because they serve different purposes in Rust's ownership system.

• String is an owned, growable UTF-8 text buffer.
• str is a string slice type, usually used as &str, which is a borrowed view into UTF-8 text.

Why Rust needs both

In Rust, ownership matters. Sometimes your code needs to own text so it can store it, modify it, or return it from a function. Other times, your code only needs to read some text temporarily without taking ownership.

Having separate types makes these cases explicit:

• Use String when your code owns the text.
• Use &str when your code just borrows text.

This helps Rust prevent memory errors and unnecessary copying.

String

String stores text on the heap and owns that memory. Because it owns the data, it can:

• grow or shrink
• be modified
• be moved between variables
• be returned from functions as owned data

Example:

let mut name = String::from("Rust");
name.push_str(" language");

Think of String as a book you own, and &str as a page reference or excerpt from a book.

• If you own the whole book and can add or remove pages, that is like String.
• If you are only pointing to some text inside a book owned elsewhere, that is like &str.

Another way to see it:

• String = the actual storage container
• &str = a window looking into text

The window does not own the text. It only lets you read it while the original text still exists.

Core syntax

let owned: String = String::from("hello");
let borrowed: &str = "hello";

Create a String

let a = String::from("hello");
let b = "hello".to_string();

Both create owned strings.

Use a string slice

let name: &str = "Ada";

This borrows a string literal.

Borrow a String as &str

let message = ::();
 : & = &message;

Consider this example:

fn print_length(text: &str) {
    println!("{} has length {}", text, text.len());
}

fn main() {
    let s = String::from("hello");
    let slice = &s;
    print_length(slice);
}

Step by step:

1. String::from("hello") creates an owned String on the heap.
2. s owns that string data.
3. let slice = &s; borrows s as &str.
4. slice does not copy the text. It only points to the same text.
5. print_length(slice) passes that borrowed view into the function.
6. Inside print_length, the function can read the text but does not own it.
7. When the function ends, slice is still valid because still exists.

Accepting user input

When reading input from a user, you often store it in a String because the program owns that text and may modify it.

let mut input = String::new();

API and function parameters

Functions that only read text commonly accept &str:

fn is_valid_email(email: &str) -> bool {
    email.contains('@')
}

This works with both literals and String values.

Building output text

When constructing messages, file contents, SQL queries, or JSON snippets, you usually return or build a String.

Parsing and processing text

Parsers often receive &str because they inspect text without needing to own it.

Configuration values

A config loader may temporarily borrow text as &str while validating, then store selected values as if they must live independently.

In real Rust codebases, developers follow a few common patterns.

Prefer &str for read-only parameters

fn log_message(message: &str) {
    println!("LOG: {}", message);
}

This avoids unnecessary allocations and makes the function easier to call.

Use String for stored data

Struct fields often use String when the struct must own the text:

struct User {
    username: String,
    email: String,
}

Convert at boundaries

A common pattern is:

• accept &str
• validate or inspect it
• convert to String only if ownership is needed

fn create_user(username: &str) -> User {
    User {
        username: username.to_string(),
        email: ::(),
    }
}

Mistake 1: Thinking str and &str are the same thing

str is the slice type itself, but you almost always work with it through a reference: &str.

Broken idea:

let text: str = "hello";

Correct:

let text: &str = "hello";

Mistake 2: Using String for every function parameter

Broken:

fn greet(name: String) {
    println!("Hello, {}", name);
}

This forces callers to give ownership.

Better:

fn greet(name: &str) {
    println!(, name);
}

String vs &str in function design

Quick rules

• String = owned, growable UTF-8 text
• str = string slice type
• &str = borrowed view into UTF-8 text
• String literals are usually &'static str
• Neither String nor str is deprecated

Most common choices

fn read_only(text: &str) {}
fn creates_text() -> String { String::from("hi") }

Convert between them

let s: String = String::from("hello");
let slice: &str = &s;

let owned: String = slice.to_string();

Why does Rust have both String and str?

Because Rust separates owned data from borrowed data. String owns text, while &str borrows text.

Should I use String or &str for function parameters?

Usually &str, unless the function must take ownership of the text.

Is str ever used without &?

Rarely in everyday Rust code. Most of the time you use &str.

Are string literals String values?

No. String literals are &'static str.

Is String just a wrapper around str?

You can think of String as owned string storage that can be borrowed as &str, but they are distinct types with different roles.

Is either or deprecated in Rust?

• Ownership — String and &str make the ownership model visible.
• Borrowing — &str is one of the most common borrowed types in Rust.
• References — understanding &T helps explain why &str is so common.
• Slices — str is a slice type, similar in idea to array slices.
• Lifetimes — borrowed string data must not outlive what it points to.
• UTF-8 — Rust strings store UTF-8 text, which affects slicing and length.
• String literals — literals have type &'static str and are a common source of confusion.
• Ownership vs cloning — borrowing &str often avoids unnecessary String clones.