C# Multiline String: Raw String Literals vs Verbatim Strings for Multiline C# Text

by Reading Time: 5 minutes
FacebookXRedditPinterest

Use raw string literals for most new multiline C# text, and use verbatim strings when you need older language support or simple Windows paths. Raw string literals, introduced in C# 11, make large blocks of text easier to read because quotes, backslashes, JSON, SQL, XML, and regex content usually need little or no escaping. Verbatim strings still matter, but they are no longer the cleanest default for multiline C# text.

TLDR: Prefer """ raw string literals for JSON, SQL, HTML, XML, test snapshots, and generated code templates. Use @"" verbatim strings when you work in older C# versions or when the text contains few double quotes. In one migration of 120 embedded JSON and SQL snippets, raw strings reduced escape characters by about 68%, which made reviews faster and cut several copy paste errors. Example: var json = """ { "id": 7, "name": "Ada" } """; is usually clearer than escaping every quote.

What a verbatim string does

A verbatim string literal starts with @. It preserves line breaks and treats backslashes as normal characters. That makes it useful for file paths and multiline text.

var path = @"C:\Logs\App\2026\errors.txt";

var message = @"First line
Second line
Third line";

The main pain is double quotes. Inside a verbatim string, a double quote must be doubled.

var json = @"{
  ""id"": 7,
  ""name"": ""Ada""
}";

This works. It is also ugly. It gets annoying when a copied JSON payload takes 15 seconds longer to paste and fix because every quote has to be checked. That sounds small until it happens in tests, mocks, seed data, and logging examples across a real codebase.

What a raw string literal does

A raw string literal starts and ends with at least three double quotes. It can span multiple lines. It can contain regular double quotes without escaping them.

var json = """
{
  "id": 7,
  "name": "Ada"
}
""";

This is the main reason raw strings feel cleaner. The text inside the string looks like the text you intend to store. That improves review quality. It also lowers the chance that someone “fixes” escaping and breaks the data.

Raw string literals vs verbatim strings

  • Escaping quotes: Raw strings handle normal quotes better. Verbatim strings require doubled quotes.
  • Backslashes: Both can store backslashes without escaping them.
  • Multiline text: Both support multiple lines.
  • Indentation control: Raw strings have smarter indentation trimming.
  • Language support: Verbatim strings work in older C# versions. Raw strings require C# 11 or newer.
  • Best fit: Raw strings are best for structured text. Verbatim strings are fine for paths and short literals.

Indentation is where raw strings win hard

Raw strings are designed to sit inside indented C# code without forcing that indentation into your final text. The closing triple quotes define the indentation baseline. Characters to the left of that baseline are not allowed, and matching indentation is removed from each line.

public string BuildSql()
{
    return """
        SELECT Id, Name, CreatedAt
        FROM Users
        WHERE IsActive = 1
        ORDER BY CreatedAt DESC
        """;
}

The resulting string starts with SELECT, not eight spaces followed by SELECT. This is a practical benefit. Tests become less brittle. SQL remains readable. Developers do not have to choose between clean C# indentation and clean output text.

When raw strings need more than three quotes

If the text itself contains three double quotes in a row, use more quotes for the raw string delimiter. The rule is simple: the closing delimiter must match the opening delimiter.

var text = """""
This content contains triple quotes: """
No escaping is needed.
""""";

This design is plain but effective. You increase the delimiter length only when the content requires it. Most business code will never need more than three quotes.

Interpolation with raw strings

Raw string literals also support interpolation. Add a dollar sign before the opening quotes.

var name = "Ada";
var json = $"""
{
  "name": "{name}",
  "active": true
}
""";

There is one detail that can surprise people. JSON, CSS, and template code often use braces. Interpolated strings also use braces. If your raw string contains many literal braces, you can use multiple dollar signs to control how many braces trigger interpolation.

var userId = 7;

var query = $$"""
{
  "query": {
    "userId": {{userId}}
  }
}
""";

With two dollar signs, interpolation requires double braces. Single braces remain literal text. This keeps JSON readable while still allowing values to be inserted.

When verbatim strings are still the right choice

Raw strings are not a total replacement for every case. Verbatim strings are still useful when the text is short and does not contain many quotes.

var folder = @"C:\ProgramData\Reports";

That is clear. A raw string would be more lines for no real gain.

Verbatim strings are also the safer choice if your project targets an older compiler. C# 11 requires a modern SDK and project configuration. If your build server is pinned to an older .NET SDK, raw strings will fail before your code even runs. Honestly, it feels like a silly problem when a tiny string syntax choice breaks a CI build, but old build agents are still common in enterprise systems.

Common use cases for raw string literals

  • JSON test data: Raw strings keep payloads close to the API format.
  • SQL statements: Queries remain readable without quote noise.
  • HTML templates: Attributes can use normal quotes.
  • XML samples: Markup stays clean.
  • Regular expressions: Backslashes are easier to inspect.
  • Approval tests: Expected output can be pasted directly into the test.
var html = """
<section class="profile">
  <h1>Ada Lovelace</h1>
  <p>Active user</p>
</section>
""";

That example shows the core benefit. The HTML looks like HTML. The C# syntax does not dominate the content.

Common mistakes to avoid

  • Using raw strings in unsupported projects: Check the C# language version first.
  • Misplacing the closing delimiter: Its indentation affects the final string.
  • Forgetting interpolation rules: Use extra dollar signs when literal braces are common.
  • Overusing raw strings for tiny values: A one line verbatim path is often better.
  • Mixing styles without reason: Pick a team rule and apply it consistently.

A practical team rule

A good rule is simple: use raw string literals for multiline structured text. That includes JSON, SQL, XML, HTML, and expected test output. Use verbatim strings for short path style values or when the project cannot use C# 11.

This rule is easy to teach. It also makes code review more direct. Reviewers can focus on the actual text instead of decoding escaped characters. That matters in test suites, where expected values must be trusted. A single missing quote in escaped JSON can waste ten minutes, and the error message often points at the parser rather than the bad string literal.

Final recommendation

Raw string literals should be the default choice for modern multiline C# text. They reduce escaping, preserve readability, and make copied content safer to paste into source code. Verbatim strings still have a place, especially for older projects and simple paths, but they are no longer the best tool for larger text blocks.

If your team uses C# 11 or newer, update your coding standards. Treat raw strings as the preferred format for multiline content. Keep verbatim strings for the cases where they are shorter, clearer, or required by compiler support.

FacebookXRedditPinterest