c# verbatim string: How to Use @ in C#

In C#, a verbatim string is declared by prefixing the string literal with the @ symbol. The c# verbatim string syntax tells the compiler to treat the string content literally, meaning backslash characters (\) are no longer escape sequences, and whitespace is preserved as written.

string path = @"C:\Users\Downloads\file.txt";
Console.WriteLine(path);

The output is C:\Users\Downloads\file.txt, not a string with tab or line feed characters. Without the verbatim prefix, you would need double backslashes ("C:\\Users\\Downloads\\file.txt") to get the same result.

This feature is especially useful for Windows file paths, UNC paths, and regular expression patterns where backslashes are common. But it also introduces one new escape rule: to include a double quote inside a verbatim string, you double it ("").

Verbatim Escaping Rules

In a normal C# string, a backslash starts an escape sequence such as \n (newline), \t (tab), or \" (quote). In a verbatim string, the compiler ignores that behavior. The only escape sequence recognized is "", which represents a single double-quote character.

string quote = @"He said ""hello"" to me.";
Console.WriteLine(quote);

This prints:

He said "hello" to me.

The doubled quote rule is symmetrical: every pair of "" collapses to one ". If you need three consecutive quotes, you write six (""""""). This can become hard to read if the string contains many quotes, so decide based on context whether verbatim or a normal string is clearer.

Multiline Text and Whitespace

Verbatim strings can span multiple lines in the source code. The line breaks and any leading spaces are part of the string.

string multiline = @"Line one
    Line two
Line three";

The resulting string contains a newline after "Line one", four spaces before "Line two", and no trailing newline at the end. This makes verbatim strings handy for embedding SQL scripts, JSON templates, or any structured text that should be indented exactly.

Be careful when aligning code. If you intend to have a leading indent, you must write it explicitly, and the indentation will be preserved in the string. That can lead to unexpected spaces in logs or error messages.

Using Verbatim Strings for File Paths

File paths on Windows use backslashes, which are the most common reason to reach for a verbatim string.

string configPath = @"C:\Program Files\MyApp\config.json";

Without the @, this path would fail because \P, \M, and \c are not valid escape sequences. The compiler would produce an error. Using a verbatim string avoids that entire class of mistakes.

For cross-platform code, you might use Path.Combine or the / character instead, but the verbatim form remains available when you need a literal representation.

Verbatim Strings vs Regular Strings

A regular string literal requires escaping backslashes. A verbatim string does not. This distinction affects both readability and correctness. If a path or a regular expression appears frequently, the verbatim form is usually easier to review and maintain.

string regexVerbose = @"\d{4}-\d{2}-\d{2}";
string regexEscaped = "\\d{4}-\\d{2}-\\d{2}";

Both strings are identical at runtime. The escaped version uses double backslashes because the backslash has to be escaped in a normal string. The verbatim version keeps the pattern as written. For beginners especially, the verbatim version reduces confusion between source-code representation and runtime value.

However, a regular string may be preferable when there are many double quotes and few backslashes. Escape sequences can still be useful in a non-verbatim string.

The Verbatim Identifier @ in Variable Names

C# also allows the @ character in front of an identifier, such as @class or @event. This is not the same as a verbatim string literal, though it uses the same prefix. The verbatim identifier lets you use a reserved keyword as a variable name.

string @class = "second period";
Console.WriteLine(@class);

The variable is named class, but the @ tells the compiler to treat it as an identifier. This is rarely needed, but it appears in generated code or when consuming APIs that use keyword names.

Do not confuse the two uses. The @ before a string literal makes the string verbatim. The @ before an identifier makes the identifier legal. They operate independently.

Compatibility and Performance Considerations

Verbatim strings are a compile-time feature. The compiler builds the same runtime string as an escaped equivalent. There is no runtime penalty for using @"..." over "..."; the emitted IL contains identical string data.

One practical concern is that verbatim strings with many embedded newlines can make source control diffs noisy, because changing indentation inside the literal changes the string value. That can frustrate code reviews.

Also note the interplay with C# 11 raw string literals ("""..."""). Raw strings provide an alternative that handles quotes more naturally and avoids the doubled quote rule. When you need many quotes or backslashes inside a literal, raw strings may be a better choice. But verbatim strings remain widely used in existing codebases and are fully supported in every C# version.

For most modern code, prefer raw string literals when the content contains both backslashes and multiple double quotes. For simple paths or concise patterns, @"..." is clear and idiomatic.

Where Verbatim Strings Fall Short

The doubled-quote syntax is the main readability trap. A string containing a lot of quotes becomes hard to read and error-prone.

string contrived = @"Key ""value"" in ""section""";

Counting pairs is tedious. In such cases, a normal string with \" can be just as readable. The decision should be based on which escaping style is less confusing for the specific content.

Another limitation is that verbatim strings do not support interpolation in the same way as raw strings, though $"" strings can still be verbatim ($"""...""" in C# 11, or $"@"...""" in earlier versions). That combination is legal, but the syntax can get visually dense.

Keep the verbatim feature in your toolbox for paths, regexes, and multiline text. When the content starts to fight the escaping rules, consider a different literal form.