Skip to content
ToolBoxGeniehome

String Escaper

Developer Tools · Added

Six formats, six different sets of rules, and no two of them agree. JSON has no single-quoted strings; a shell has no escape character at all inside single quotes; CSV doubles its quote rather than prefixing it. Paste your text, pick where it is going, and get back something that will survive the journey.

Direction

Backslash, double quote and the control characters become escapes. JSON has no single-quoted string and no literal newline inside one, so a line break must be written as an escape.

How to use the string escaper

  1. 1Choose whether you are escaping text or reversing an escape.
  2. 2Pick the target — the box below the selector explains what that target's rules actually are.
  3. 3Paste your text.
  4. 4Copy the result, and check the length change if the value has to fit a column limit.

Examples

A quoted phrase into JSON

Input
He said "hello" then left
Result
"He said \"hello\" then left"

An awkward filename into a shell command

Input
Bob's file; rm -rf /
Result
'Bob'\''s file; rm -rf /'

Single quotes stop the shell expanding anything, so the semicolon and the command after it are inert text.

About the string escaper

Escaping is about the destination, not the text

The same string needs different treatment depending on where it lands. A newline becomes \n in JSON, stays a literal newline inside CSV quotes, and needs no attention at all in a shell single-quoted string. A double quote is critical in JSON and irrelevant in SQL. There is no such thing as a generally escaped string.

That is why this asks for the target first. Picking the wrong one produces output that looks escaped and breaks anyway — which is worse than not escaping at all, because it looks handled.

Round-tripping is not always possible

Escaping is a function; unescaping is not always its inverse. In JavaScript a backslash before a character with no defined escape simply yields that character, so \q and q both unescape to the same thing and the original cannot be recovered. In CSV, a field that needed no quoting and one that was quoted unnecessarily decode identically.

Where an escape is ambiguous this tool takes the conventional reading rather than guessing at intent, and it reports a genuinely malformed input — a string ending in a lone backslash, a \u with three hex digits — instead of silently producing something plausible.

Frequently asked questions

Does the SQL option protect against injection?
No, and the page says so where you will see it. Doubling the single quote is what the SQL standard says a string literal does, which makes it genuinely useful for hand-writing a query or repairing a data file. It is not a sanitiser: it does not know whether your server treats a backslash as an escape character, and a value that is safe inside quotes is not safe interpolated into a table name or a LIMIT clause. Parameterised queries are the answer in application code, and nothing else is.
Why does the shell option produce that odd sequence of quotes?
Inside single quotes a POSIX shell expands nothing at all — no variables, no command substitution, no globbing — which is what makes the result safe whatever the string contains. The price is that a single quote cannot appear inside single quotes, so it has to close the quoting, appear as an escaped character, and reopen it. That is what the run of punctuation is doing.
When would I want the ASCII-only option?
When the file's encoding is not under your control. Turning every character above U+007F into a \u escape produces a string that survives a pipeline which mangles or re-encodes bytes. In a file you know to be UTF-8 it only makes the text harder to read, so it is off by default.
Why is HTML not one of the targets?
Because entity encoding is a large enough job to deserve its own page, and this site already has one. The HTML entity encoder handles named entities, numeric references and the decoding direction properly.

Related tools