Rust clone() vs to_owned(): What’s the Difference?

By the end of this page, you will understand that clone() duplicates a value without changing its type, while to_owned() converts borrowed data into its owned version. In Rust, this difference matters most for types like &str, where clone() returns another &str, but to_owned() returns a String.

clone() and to_owned() are related, but they solve different problems.

clone()

clone() comes from the Clone trait.

Its job is simple:

• make a duplicate of a value
• keep the same type

Examples:

• cloning a String gives another String
• cloning a Vec<T> gives another Vec<T>
• cloning a &str gives another &str

That last one is important: a string slice &str is a borrowed reference, not an owned string buffer. Cloning it does not allocate new string storage. It just copies the reference.

to_owned()

to_owned() is about converting data into an owned form.

Its job is:

Think of borrowed and owned data like reading a book.

• A borrowed value is like borrowing a library book.
• An owned value is like buying your own copy.

Now compare the methods:

• clone() means: make another copy of whatever you currently have.

  • If you currently have a library card pointing to a book (&str), cloning just copies the card.
  • You still do not own the book.

• to_owned() means: get your own personal copy.

  • If you borrowed the book (&str), to_owned() buys a copy (String).
  • If you already owned the book (String), it can make another owned copy.

So for &str:

• clone() -> another borrowed &str
• to_owned() -> an owned String

That is why the types differ.

Core syntax

let a = value.clone();
let b = value.to_owned();

The important question is: what type is value?

Example 1: &str

fn main() {
    let s: &str = "hello";

    let a = s.clone();
    let b = s.to_owned();

    // a: &str
    // b: String

    println!("{}", a);
    println!("{}", b);
}

Explanation:

• s.clone() returns another &str
• s.to_owned() returns a String

Consider this small example:

fn main() {
    let s: &str = "rust";

    let a = s.clone();
    let b = s.to_owned();

    println!("{}", a);
    println!("{}", b);
}

Step by step

1. Create s

let s: &str = "rust";

• s is a string slice
• it points to string data
• it does not own that data

2. Clone s

let a = s.clone();

• clone() preserves the type

When to use clone()

Use clone() when you want another value of the same type.

Common examples:

• duplicate a String you already own
• copy a Vec<T> before modifying one version
• duplicate configuration data stored in an owned struct
• copy an Arc<T> or Rc<T> handle

let name = String::from("Alice");
let backup = name.clone();

When to use to_owned()

Use to_owned() when you have borrowed data but need to own it.

Common examples:

• convert &str input into String for storage
• convert a slice &[T] into

In real projects, developers often use these methods as part of broader ownership patterns.

Pattern: accept borrowed, store owned

This is one of the most common Rust API designs.

struct Config {
    host: String,
}

impl Config {
    fn new(host: &str) -> Self {
        Self {
            host: host.to_owned(),
        }
    }
}

Why this is good:

• callers can pass &str or string literals easily
• the struct owns its data safely

Pattern: clone owned state before mutation

let original = String::from("draft");
let editable = original.clone();

Used when:

• you need a backup
• you want to preserve the original value
• ownership rules prevent moving the original

Pattern: guard clauses with borrowed input

1. Assuming clone() always makes a deep owned copy

Broken assumption:

let s: &str = "hello";
let c = s.clone();

Many beginners expect c to be a String. It is not.

• s is &str
• c is also &str

Fix

Use to_owned() or to_string() when you need ownership.

let s: &str = "hello";
let owned = s.to_owned(); // String

2. Forgetting that to_owned() may change the type

Quick rules

• clone() returns the same type.
• to_owned() returns an owned version.
• For borrowed data, to_owned() often allocates.
• For already owned data, to_owned() often behaves similarly to clone().

Common examples

let s: &str = "abc";
let a = s.clone();    // &str
let b = s.to_owned(); // String

let s = String::from("abc");
let a = s.clone();    // String
let b = s.to_owned(); // String

Why does clone() on &str not create a String?

Because clone() preserves the original type. A &str cloned value is still a &str.

Is to_owned() the same as clone() for String?

In practice, both produce a new String. The conceptual difference is that to_owned() means “give me an owned version,” while clone() means “duplicate this exact type.”

Should I use to_owned() or to_string() for &str?

Both can produce a String. For borrowed-to-owned conversion, to_owned() communicates intent more clearly.

Does to_owned() always allocate memory?

Not always in every possible type, but for common borrowed types like and slices, it creates owned data and therefore allocates.

• Ownership — clone() and to_owned() make sense only when you understand who owns the data.
• Borrowing — to_owned() is especially useful when converting borrowed values into owned ones.
• Clone trait — defines clone() and explains same-type duplication.
• ToOwned trait — defines to_owned() and connects borrowed types to owned counterparts.
• String vs &str — the most common example of owned vs borrowed text in Rust.
• Slices and Vec<T> — another important borrowed-to-owned pair.
• Move semantics — helps explain why Rust sometimes needs duplication or conversion.
• to_string() — often confused with to_owned(), especially for string data.