A regular C# string treats the backslash as an escape character and refuses to span multiple lines. That's fine for short text, but it gets painful the moment you need a Windows file path, a multi-line product description, or an embedded snippet of JSON or SQL. C# offers two cleaner alternatives: verbatim strings (@"..."), which turn escape sequences off, and raw string literals ("""..."""), introduced in C# 11, which turn everything off and let you paste content in unchanged. This lesson walks through both, side by side, with the rules that catch people off guard.

A verbatim string is a regular string with one twist: the compiler ignores backslash escapes. You write @ before the opening quote, and everything between the quotes is taken literally. No \n becoming a newline, no \\ collapsing into one backslash, no \t becoming a tab. The text is whatever you typed.

The classic case is a Windows file path:

Both lines print the same path. The regular string needs every backslash doubled, because \O, \r, \2, and \i would either be interpreted as an escape or rejected by the compiler. The verbatim form just reads what you wrote. For paths, regex patterns, and anything else with frequent backslashes, the verbatim form is much easier to maintain.

Verbatim strings also let newlines in the source code become newlines in the string. If you press Enter inside the quotes, the resulting string contains a \n (or \r\n on Windows, depending on how the file is saved). That makes them handy for short multi-line text:

The text reads exactly the way it appears in source. No \n markers, no string concatenation, no Environment.NewLine calls. Whatever line breaks you put between the quotes end up in the string.

There's one wrinkle. Since the @ form turns off escapes, you can't use \" to put a double quote inside the string. Instead, you double the quote: "" means "a single literal " character."

Two consecutive double quotes inside a verbatim string collapse to one literal ". This rule is the only escape mechanism the verbatim form supports.

Verbatim strings also work with string interpolation. The prefix becomes $@ or @$, both of which are equivalent. Inside, { and } still mark interpolation holes, and {{ / }} still escape to literal braces:

The path keeps single backslashes (verbatim behavior), and {customer} is replaced with the value (interpolation behavior).

Raw string literals, added in C# 11, take the idea of "everything is literal" further. You open with at least three double quotes (""") and close with the same number, and between those delimiters nothing is special. No backslash escapes, no "" quote rule, no surprises. Whatever you paste in is exactly what the string contains.

A small example first:

Three quotes open, three quotes close, and everything in between is the string. No interpretation, no escapes. The single-line form is rarely the point of raw strings, though. They shine for multi-line content.

For multi-line raw strings, the opening """ must be the last token on its line (a newline has to follow it), and the closing """ must be on its own line. The text begins on the line after the opener and ends on the line before the closer:

Notice the indentation. Each line in source code was indented by four spaces, but the output isn't. That's because the closing """ sets the left margin. Whatever column the closing delimiter sits at, the compiler strips that much whitespace from the start of every content line. The closing """ in the example above is indented four spaces, so four spaces are removed from each line, and the resulting string has no leading indent.

This indentation rule is what makes raw strings pleasant to work with. You can keep the content indented to match the surrounding code, and the string itself stays clean.

A diagram helps make the rule concrete:

The left column shows the four source lines as written, each with four leading spaces. The middle box represents the compiler's left-margin calculation based on where the closing """ sits. The right column is the resulting string content.

If a content line is indented less than the closing delimiter, the compiler reports an error (CS9003). Every content line has to start at or to the right of the closing delimiter's column. That rule prevents accidental misalignment from silently producing weird strings.

Embedding Quotes Inside Raw Strings

Three quotes is just the minimum. If your content contains """, you can open with four (or more) and close with the same count. The rule is simple: the opening and closing fences must be longer than any run of quotes inside the content.

Four quotes open, four quotes close, and the three quotes inside are just text. If the content has runs of four quotes, open and close with five, and so on. There's no escape mechanism inside raw strings, you just widen the fence.

Embedding JSON, SQL, and HTML

This is the use case raw strings were designed for. JSON payloads, SQL queries, HTML templates, and regular expressions are full of double quotes, backslashes, and newlines. With a regular string, you'd be escaping every quote and concatenating lines. With a raw string, you paste the content in and it just works.

An order payload as JSON:

Every double quote inside the JSON is a literal ". No \" clutter, no "" doubling. The indentation inside the JSON (the extra four spaces around "orderId" and the items array) is preserved because it's beyond the closing delimiter's column.

The same payoff applies to a SQL query for product search:

The query reads the way it would in any SQL editor. The two-space indent on the AND lines stays, because those lines are indented two more spaces than the closing delimiter.

Raw Strings with Interpolation

You can combine raw strings with interpolation by adding $ in front. The $"""...""" form interprets { and } as interpolation holes, exactly like regular interpolated strings:

That works fine until your content contains literal { or } characters, which is common in JSON. The regular {{ and }} escape trick still works, but for JSON-heavy strings it gets ugly fast. The cleaner option is to use multiple $ signs. Each extra $ tells the compiler how many braces in a row count as the interpolation marker.

With $$"""...""", a single { is literal text. Only {{ opens an interpolation hole, and only }} closes it. Three dollar signs means you need {{{ to interpolate, and so on.

The single { and } around "customer", "total", and "currency" are literal braces in the JSON. The {{customer}} and {{total}} are interpolation holes, because two braces match the $$ prefix.

The three forms differ in how they treat backslashes, newlines, and quote characters. The table sums it up:

A few observations about choosing between them:

A small program that puts each form to use. A receipt folder path (verbatim), a multi-line product description (raw), an order payload as JSON (raw with $$ interpolation), and a SQL search query (raw).

Four strings, four different jobs. The path keeps its single backslashes. The product blurb keeps its line breaks but loses the source indentation. The JSON keeps its literal braces while still letting {{orderId}} and friends interpolate. The SQL keeps its two-space AND indent, because those lines are two columns further right than the closing delimiter.