String Escape

This tool escapes and unescapes strings with JavaScript/JSON backslash escapes, in your browser; nothing leaves your machine. Escape turns quotes, backslashes, newlines, tabs and other control characters into \", \\, \n, \t … — output you can paste between double quotes in JSON or JavaScript. Unescape reverses that and also understands the JavaScript-only forms \xHH, \u{…} and \'. The other contexts below (regex, shell, HTML, SQL) are explained for reference; the tool doesn’t apply their rules — for HTML, use HTML encode.

What “escaping” means

A string contains characters; some characters have meaning to the surrounding code or markup. Escaping replaces those problematic characters with a representation that’s safe in the surrounding context.

Original string:   The path is C:\Users\Alice
JavaScript escape: "The path is C:\\Users\\Alice"
JSON escape:       "The path is C:\\Users\\Alice"
Shell escape:      'The path is C:\Users\Alice'
HTML escape:       The path is C:\Users\Alice

Same input, different escape sequences depending on where the string is going.

JavaScript / JSON string escapes

The two are nearly identical; both use the same backslash-escape style.

JavaScript-only additions:

• \xXX (2-hex-digit byte)
• \b (boundary in regex; backspace in string)
• Single-quoted strings allow \' and don’t need to escape ".

JSON is stricter — only the escapes in the table above. No \xXX, no \u{XXXXX} brace form.

// JavaScript:
const path = "C:\\Users\\Alice";
const json = '{"path":"C:\\\\Users\\\\Alice"}';

// JSON itself:
{"path":"C:\\Users\\Alice"}

JavaScript embeds backslash-as-escape twice when the JSON is a string literal: once for JS, once for JSON.

Regex escapes

Regex has its own set of meta-characters that need escaping when literal:

. * + ? ^ $ ( ) [ ] { } | \

Inside a character class [...], only ], \, ^ (when first) need escaping.

const pattern = /\./;          // matches a literal dot
const pattern = /\\/;          // matches a literal backslash
const pattern = new RegExp("\\."); // same as above, but in a string

The double-escape ("\\.") when constructing from a string is the most common regex confusion: the JavaScript string parser eats one backslash, leaving \. for the regex.

Shell escapes

Shell escape rules depend on the quote style:

The single-quote rule is awkward: a literal ' inside single quotes requires closing the quote, escaping with \', and reopening. Or use double quotes.

# Single-quoted: nothing inside is interpreted
echo 'Hello $USER'         # prints: Hello $USER

# Double-quoted: variables and \ have meaning
echo "Hello $USER"         # prints: Hello yourusername

# To include both quote types: alternate
echo 'It'"'"'s a test'      # prints: It's a test

For shell command construction in a programming language, use the language’s argument-array form (subprocess.run(['ls', '-la'], ...)) instead of building shell command strings. Avoids the entire escape problem.

HTML escapes

Five characters need escaping in HTML text content:

For attribute values, the relevant subset (depends on quote style) needs escape. See HTML encode for the full discussion.

SQL escapes

Quote inside single-quoted string: '' (doubled)
'O''Brien'  → represents O'Brien

Standard SQL uses doubled quotes for embedded quotes. Some dialects (MySQL, PostgreSQL with standard_conforming_strings = off) historically allowed \' instead; modern SQL prefers ''.

The right way to handle SQL strings: use parameterized queries / prepared statements. The driver handles escaping correctly. Manual escape construction is the source of SQL injection bugs.

CSV escapes

Cell containing comma:           "value, with comma"
Cell containing quote:           "She said ""hi"""
Cell containing newline:         "line one\nline two"  (literal newline inside the quoted cell)

CSV escape: wrap in double quotes when the cell contains ,, ", \n, or \r. Double internal " to "". See CSV to JSON for parsing.

When to escape, when to use APIs

The escaping table above is for cases where you have to construct a string by hand. Often, you don’t:

• SQL: Use parameterized queries.
• HTML: Use a templating engine with auto-escape.
• Shell: Use argument-array APIs.
• Regex: Use the language’s built-in escape function (RegExp.escape proposal in JavaScript; re.escape in Python).
• JSON: Use JSON.stringify, never concatenate.
• URL: Use encodeURIComponent. See URL encode.

Hand-rolled escape is a common source of injection bugs. Use the API when one exists.

Common pitfalls

• Single-escape vs double-escape confusion. "\\n" in a JavaScript string literal is two characters (\ and n); "\n" is one (the newline). When the string is then embedded in JSON, double again.
• Mismatched escape contexts. A string escaped for JavaScript that’s then used as HTML still needs HTML escape. Escape for the deepest context first, then for each layer it passes through.
• Forgetting to escape on input. Trusting user input that ends up in HTML / SQL / shell is the entire OWASP top 10 in one decision. Auto-escape at the boundary.
• Over-escaping. A backslash that’s escaped through multiple layers becomes \\\\ or worse. Each layer should escape exactly once.
• String concatenation for code generation. Writing code that constructs SQL or HTML by string concatenation is asking for injection bugs. Use the structured APIs.

For specific contexts, see HTML encode, URL encode, JSON formatter, regex tester.