How String Escaper works
Every text format has characters that mean something structural, and putting text into that format means neutralising them first. A quote inside a SQL literal ends the literal early, a comma inside a CSV field starts a new column, and an unescaped dot in a regular expression matches any character rather than a full stop. This tool applies the correct escaping rules for seven common targets and reverses them, and explains what each transformation did — because the useful part is usually understanding why a particular character needed handling, not just getting the escaped string.
How to use it
- 1
Choose the format you are escaping for — JSON, JavaScript, SQL, CSV, shell, regex or an HTML attribute.
- 2
Pick whether you are escaping or unescaping.
- 3
Paste your text and read the result along with the note explaining the transformation.
- 4
Copy the output, quotes included or excluded as you prefer.
Common uses
Embedding text in a JSON payload
Newlines, tabs and quotes all need escaping before a string can be placed inside a JSON document by hand.
Writing a one-off SQL query
A name such as O'Brien breaks a naive query; doubling the quote is the standard-SQL fix for a hand-written statement.
Passing awkward text to a shell command
Text containing spaces, dollar signs or quotes needs quoting before a shell will treat it as a single literal argument.
Searching for a literal string with a regex
Escaping the special characters turns a search pattern into an exact-match search rather than a wildcard.
Escaping is not a security strategy
This is worth being blunt about, because escaping is often reached for as an injection defence and it is a poor one. Manual escaping is fragile: it depends on the exact dialect, on the connection's character set, and on the developer remembering to apply it at every single insertion point. Miss one and the protection is gone entirely. The robust answer for SQL is parameterised queries, where the statement and the data travel separately so the database never parses user input as SQL — there is nothing to escape because the data is never part of the command text. The same principle applies elsewhere: pass arguments to a subprocess as an array rather than building a shell command string, and construct JSON with a serialiser rather than string concatenation. Use this tool for hand-writing a query you are about to run once, for understanding what a format requires, or for debugging an escaping problem you have already got — not as a layer in application code.
The escaping conventions differ more than you would expect
There is no shared convention, which is exactly why mixing them up is so common. JSON and JavaScript use a backslash before the character being escaped, and represent control characters with letter sequences such as \n and \t. SQL does not use backslashes at all in the standard: a single quote is escaped by doubling it, so O'Brien becomes O''Brien. CSV follows the same doubling rule but with double quotes, and additionally requires the whole field to be wrapped in quotes whenever it contains a comma, a quote or a line break. Shell single-quoting is the strangest of the group, because there is no escape mechanism at all inside single quotes — a literal quote has to be produced by closing the quoted section, emitting an escaped quote, and reopening it, which is why correct shell escaping looks so wrong. Regular expressions use a backslash but against a much larger set of characters, since anything with a special meaning in a pattern must be neutralised to match literally.
A few pointers
- Use parameterised queries in application code; hand-escaping SQL is for one-off queries you write and run yourself.
- A CSV field only needs quoting when it contains a comma, a double quote or a line break — but quoting it anyway is always safe.
- When escaping for HTML, escape the ampersand first, otherwise you will double-encode every other entity you produce.