String Escaper & Unescaper

What is string escaping?

A string literal in source code is delimited by quotes. That creates an immediate problem: what happens when the text itself contains a quote?

const message = "He said "stop" and left";
                          ↑ the string ended here

Escaping solves it by marking a character as data rather than syntax. In most C-derived languages the marker is a backslash:

const message = "He said \"stop\" and left";

The backslash is not stored. It tells the parser "the next character is content", and the value in memory is exactly He said "stop" and left.

Escaping is not encoding

The two words get used interchangeably, but they solve different problems.

The practical consequence: there is no such thing as a universally "escaped string". A value escaped for SQL is wrong for JSON, and a value escaped for JSON is wrong for a shell command. That is why this page asks you to pick a target instead of guessing.

How to escape a string

1. Choose the target syntax JSON, JavaScript with single quotes, Java/C#/C++, Python, ANSI SQL, POSIX shell, a CSV field, or literal text inside a regular expression.
2. Paste the raw text Include the real quotes, backslashes and line breaks. Do not pre-escape anything — that is what causes doubled backslashes.
3. Decide about the surrounding quotes Keep them on when you want a complete literal to paste. Turn them off when you are inserting into an existing quoted string.
4. Or reverse it Switch to Unescape to recover the original text from a literal you found in a log file, a stack trace, or a database column.

Examples: one input, eight targets

The same raw value, escaped for each supported syntax. Input:

It's a "test" — C:\temp
Second line

Three things are worth noticing in that table.

SQL does not use backslashes. The standard doubles the quote: ''. A backslash in SQL is ordinary text in PostgreSQL and standard-mode MySQL, so escaping it would corrupt the value.

Java escapes the em dash but JSON does not. JSON files are UTF-8 by definition, so — can sit there literally. Java source files historically could not rely on that, hence \u2014.

Shell does not escape the newline at all. Inside single quotes a literal newline is fine; only the quote character needs special handling.

The shell quoting trick, explained

POSIX shells have no escape character inside single quotes. Not even the backslash works — '\'' does not produce a quote. So embedding one requires leaving the quoted section entirely:

'It'\''s'
 │  │└┬┘└─┬┘
 │  │ │   └── reopen single quoting: 's'
 │  │ └────── an escaped quote, outside any quoting: \'
 │  └──────── close the first quoted section
 └─────────── open single quoting: 'It'

The shell concatenates adjacent tokens, so those three pieces become one argument: It's. It looks bizarre but it is completely reliable, which is why it is what printf %q and most shell-escaping libraries produce.

This is also why shell escaping is the one target here that cannot be reversed automatically. The meaning depends on the surrounding command line, not on the string alone.

Common mistakes

• Double escaping. Escaping an already-escaped string turns \n into \\n. In the output that means a literal backslash followed by the letter n, not a newline. If your log files are full of \\n, an escape ran twice.
• Escaping a Windows path once. C:\temp\new in a JSON string must be C:\\temp\\new. Written with single backslashes, \t becomes a tab and \n becomes a newline — the path silently changes to C: + tab + emp + newline + ew.
• Using backslash escapes in SQL. Writing 'O\'Brien' works in MySQL's default mode and fails in PostgreSQL, SQLite and standard-compliant MySQL. 'O''Brien' works everywhere.
• Forgetting the CSV wrapping rule. Doubling the quotes is only half the job. A field containing a comma, a quote or a line break must also be wrapped in quotes, otherwise the doubled quotes are meaningless.
• Escaping instead of parameterising. For SQL specifically, escaping is for generating fixtures, seed data and migration scripts. Application queries should use bound parameters, which remove the escaping question entirely.
• Escaping - or / in a regex by habit. Both are only special in specific positions — - inside a character class, / in a JavaScript regex literal. Escaping them elsewhere is harmless but noisy.

Use cases

• Putting a JSON payload into a test fixture. Turn a formatted API response into a single-line escaped literal for a unit test.
• Reading an escaped value from a log. Stack traces and structured logs print strings escaped. Unescaping restores the newlines and shows the real message.
• Writing seed data. Names with apostrophes break naive INSERT statements. The SQL target doubles them correctly.
• Building a safe shell command. Any filename or argument coming from data needs quoting before it goes into a script.
• Matching text literally in a regex. Searching for price ($) requires price \(\$\), since ( and $ are metacharacters. The regex target does this mechanically — test the result in the Regex Tester.
• Repairing a broken CSV export. Compare a problem field against correctly escaped output to see whether quoting or doubling was missed.

Privacy

All escaping and unescaping happens in your browser using JavaScript string operations. The text is not uploaded to be transformed, which matters when the string you are escaping is a connection string, a token, or production data.