A string can't hand you a writable window onto itself — because a string never changes. This is the window it hands you instead.

You already know one of the oldest rules in .NET: a string is immutable. Once created, its characters never change — every "modification" you've ever performed on a string, from ToUpper() to Replace() to string concatenation, actually produced a brand-new string, leaving the original untouched.

Now recall the previous lesson: a plain Span<T> lets you both read and write through the memory it views. If string.AsSpan() returned a plain, writable Span<char>, you could write straight through it and mutate a string's characters in place — which would break one of the most fundamental guarantees in the entire .NET type system. Something has to give.

In this lesson, you'll meet ReadOnlySpan<T> — the read-only counterpart to Span<T> that makes zero-copy slicing safe even for immutable data like strings, and you'll see the single most common, genuinely important performance pattern it unlocks: parsing text without allocating a new string for every piece you extract.

What Is It?

The Simple Explanation

ReadOnlySpan<T> is exactly what its name says: a Span<T> that only lets you read through the window, never write through it. You get all the same zero-copy slicing and indexing — just with the compiler refusing, at compile time, to let you assign into an element.

The Technical Definition

ReadOnlySpan<T> (in System) is, like Span<T>, a ref struct representing a contiguous region of memory as a reference plus a length. The difference is entirely at the API surface: its indexer returns ref readonly T rather than ref T, so the compiler statically rejects any attempt to write through it. There's no runtime flag, no hidden check — the safety is enforced entirely by the type system, at compile time, with zero runtime cost.

This matters most for exactly the case that motivated this lesson: string.AsSpan() returns a ReadOnlySpan<char>, not a Span<char>. Since string is immutable, the runtime can safely hand out a direct view onto its internal character buffer — as long as that view can never be used to write back into it. ReadOnlySpan<char> is precisely that: read access with zero copying, and a compile-time guarantee that immutability can't be violated through it.

Why Does It Exist?

The Problem — every string operation you've used allocates

string.Substring(start, length) is one of the most commonly called methods in all of .NET — and every single call allocates a brand-new string object and copies characters into it, even when all you needed was to glance at a few characters and immediately discard them. Write a hand-rolled parser — a CSV reader, a log-line parser, a simple protocol parser — using Substring at every step, and you're allocating a fresh string for every field, on every line, of every file. For a large log file or a high-throughput ingestion pipeline, that's an enormous, entirely avoidable amount of garbage for the GC to trace and collect.

The Solution

ReadOnlySpan<char> lets you slice a string's characters the same way you sliced an array in the previous lesson — without allocating anything. You can walk through a line of text, find delimiters, and produce narrower and narrower slices, all pointing back into the exact same original string's memory, and only pay for an actual string allocation at the very end, if and when you truly need one (say, to store a final parsed value in a model object).

Big Picture — before vs. after, parsing a simple CSV line

string line = "42,Widget,19.99";

How It Works

string line = "42,Widget,19.99";
ReadOnlySpan<char> span = line.AsSpan(); // zero allocation, zero copying

int firstComma = span.IndexOf(',');
ReadOnlySpan<char> idField = span[..firstComma]; // "42" — still a view, no allocation

int id = int.Parse(idField); // int.Parse has a ReadOnlySpan<char> overload — no string ever created

string name = nameField.ToString(); // deliberate, one-time allocation — you need a real string to store

Simple Example — a naive parser vs. a span-based parser, side by side

Before — string.Substring at every step

public static (int Id, string Name, decimal Price) ParseLineNaive(string line)
{
    int firstComma = line.IndexOf(',');
    int secondComma = line.IndexOf(',', firstComma + 1);

    string idText = line.Substring(0, firstComma);                              // allocation #1
    string name = line.Substring(firstComma + 1, secondComma - firstComma - 1); // allocation #2
    string priceText = line.Substring(secondComma + 1);                          // allocation #3

    return (int.Parse(idText), name, decimal.Parse(priceText));
}
// 3 throwaway string allocations per line, purely to hand values to int.Parse/decimal.Parse

After — ReadOnlySpan<char> slicing

public static (int Id, string Name, decimal Price) ParseLineFast(string line)
{
    ReadOnlySpan<char> span = line.AsSpan();

    int firstComma = span.IndexOf(',');
    ReadOnlySpan<char> idField = span[..firstComma];

    ReadOnlySpan<char> rest = span[(firstComma + 1)..];
    int secondComma = rest.IndexOf(',');
    ReadOnlySpan<char> nameField = rest[..secondComma];
    ReadOnlySpan<char> priceField = rest[(secondComma + 1)..];

    int id = int.Parse(idField);           // no allocation — Parse reads straight from the span
    decimal price = decimal.Parse(priceField); // same

    // 'name' is the one field we actually need as a real, standalone string
    string name = nameField.ToString();    // exactly 1 allocation, deliberate

    return (id, name, price);
}
// 1 allocation per line, only where a real string is genuinely needed — down from 3

Why this matters: both functions return the exact same result. The only difference is that the naive version manufactures three throwaway strings per call purely as a vehicle to get characters to int.Parse/decimal.Parse, while the span-based version reads directly out of the original line string's own memory and allocates only for the one field that genuinely needs to be a standalone string afterward. Run this across a million-line file, and the difference between roughly 3 million and 1 million short-lived allocations is a real, measurable amount of GC work saved.

Real-World Example

This exact pattern — repeated slicing of a ReadOnlySpan<char> instead of repeated Substring calls — shows up constantly in real, high-volume text processing:

• Log ingestion pipelines parsing timestamp, severity, and message fields out of millions of log lines per hour.
• CSV or TSV import tools processing large exported data files, field by field, row by row.
• Simple protocol parsers — HTTP header parsing, custom text-based wire protocols — where a server may parse thousands of messages per second.
• In fact, .NET's own int.Parse, double.Parse, Guid.Parse, and many string methods themselves gained ReadOnlySpan<char> overloads specifically so that framework and application code alike could stop allocating intermediate strings just to call them.

The core lesson generalizes well beyond CSV: any time you find yourself calling Substring purely to hand a piece of a string to another method that only needs to read those characters, check whether that method (or an overload of it) accepts a ReadOnlySpan<char> instead — increasingly, in modern .NET, it does.

Analogy

Under the Hood

Span<int> writable = someArray.AsSpan();
ReadOnlySpan<int> readOnly = writable; // implicit conversion — no cast needed

Common Confusion

1. "Slicing a ReadOnlySpan<char> still allocates, just like Substring"

No — this is precisely the misunderstanding this lesson corrects. span[0..2] and span.Slice(0, 2) never allocate; they compute a new starting reference and length within the exact same string memory. Only .ToString() — called explicitly, when you actually need a standalone string — allocates.

2. "ReadOnlySpan<T> only exists for strings"

Strings are its single most common use case, but ReadOnlySpan<T> works over any kind of memory, exactly like Span<T> — including read-only views over arrays you don't want a method to accidentally mutate, even when the underlying array itself happens to be writable.

3. "I should just cast a ReadOnlySpan<char> back to Span<char> when I need to write"

There's no plain cast that does this, and that's deliberate — as covered in Under the Hood, it would undermine the immutability guarantee a ReadOnlySpan<char> from a string relies on. If you need writable character data, start from a genuinely writable source (a char[], or a Span<char> you allocated yourself), not from a string's read-only view.

Common Mistakes

Mistake 1 — Calling .ToString() too early, defeating the whole point

Slicing with spans correctly, then immediately calling .ToString() on every slice "just to be safe" before doing anything else with it — silently reintroducing every allocation the span-based approach was meant to eliminate.

int id = int.Parse(idField.ToString()); //  allocates a string just to immediately discard it

Pass the span directly to any method that accepts ReadOnlySpan<char>: int.Parse(idField). Reserve .ToString() for the one moment you truly need a standalone string to keep.

Mistake 2 — Assuming every string method has a span overload

Assuming any arbitrary method that accepts a string parameter can be handed a ReadOnlySpan<char> directly, without checking.

Many modern parsing and comparison APIs do accept ReadOnlySpan<char>, but plenty of older or higher-level APIs still only accept string — in those cases, a .ToString() call is genuinely necessary, and that's fine; the goal is avoiding unnecessary allocations, not eliminating every allocation at any cost.

Mistake 3 — Trying to store a ReadOnlySpan<char> for later use

Trying to keep a parsed field's ReadOnlySpan<char> around in a field or a collection for use after the current method returns.

Like Span<T>, ReadOnlySpan<T> is also a ref struct, with exactly the same restrictions covered in the previous lesson. If a slice needs to outlive the current synchronous stretch of code, either materialize it with .ToString() now, or reach for ReadOnlyMemory<T> — covered in the next lesson.

When Should I Use It?

Mental Model

Key Takeaway

Check Your Understanding

You've seen why strings need a read-only view and how it kills allocation-heavy parsing. Let's confirm it stuck.

You can now write allocation-free text parsing with ReadOnlySpan<char> — and you understand exactly why the widening conversion only goes one direction. Next: what to do when span-like data needs to survive past one synchronous method call.

dotnetmadeeasy.com — Learn C# and .NET, the right way.