.NET (C#) String Unescape

C# unescape: decode .NET string literals

The C# unescape tool interprets the escape sequences of C# regular string literals and returns the resulting text. Paste strings copied from source code, debugger watch windows or log files that show \r\n instead of real line breaks.

Sequences the decoder understands

• Simple escapes: \' \" \\ \0 \a \b \f \n \r \t \v. The \e escape added in C# 13 is not decoded and stays as written.
• \uXXXX — exactly four hex digits.
• \UXXXXXXXX — eight hex digits, for any code point including emoji (\U0001F680 → 🚀).
• \x followed by one to four hex digits.

Example

Input:

Tab:\tBell:\a \x41BC vs \x0041BC \U0001F680

Output:

Tab:	Bell: 䆼 vs ABC 🚀

Look closely at the two \x sequences. \x41BC is greedy: it consumes all four hex digits and produces the single CJK character U+41BC. \x0041BC consumes 0041 (an “A”) and leaves “BC” as text. The decoder applies the same rule as the C# compiler, so what you see here is what the compiler produces — a quick way to debug a string that came out garbled.

Where escaped C# strings appear

• The Visual Studio and Rider debuggers show string values in escaped form in tooltips, the Watch window and Locals, so a multi-line value appears on one line full of \r\n.
• Unit test failure messages and snapshot files frequently print expected and actual values as escaped literals.
• Source generators, T4 templates and decompiled assemblies emit escaped strings, often with \u escapes for any non-ASCII character.

Pasting such a value here shows the text as the program really sees it, which makes invisible differences — a stray tab, a carriage return, a non-breaking space — easy to spot.

Common mistakes when unescaping C# strings

• Double-escaped text. Strings taken from JSON logs or serialized exceptions are often escaped twice, so a line break appears as \\r\\n. One pass turns it into \r\n; copy the result back into the escaped box to decode it a second time.
• Surrogate pairs. Tools that only know \u write emoji as two escapes, such as \uD83D\uDE80. That is valid C# too and decodes to the same 🚀 as \U0001F680.
• Regex patterns without @. Sequences like \d or \s are not C# escapes, and the compiler rejects them with error CS1009. In source code they belong in a verbatim string (@"\d+") or need doubled backslashes.
• Raw string literals. C# 11 """…""" strings contain no escapes at all, so there is nothing to decode.

Regular vs. verbatim strings

This tool decodes regular literals. In verbatim strings (@"…") backslashes are not escapes at all, and the only special sequence is "". If you paste verbatim content here, its backslashes will be interpreted and may change the text. For regular expressions, note that Regex.Unescape() in .NET decodes regex escapes, which is a different set.

To go the other direction, use .NET Escape. For Java strings, which use octal escapes instead of \x, see Java Unescape. Decoding runs locally in your browser.