String Escaper & Unescaper

Frequently asked questions

Which format should I pick?

The one the text is going into, not the one it came from. There is no such thing as a generally escaped string: the same apostrophe is nothing at all in JSON, ' in an HTML attribute, ' in XML, two apostrophes in SQL and a four-character dance in a shell command. Pick JSON for an API payload or config file, JavaScript for a string literal you are pasting into code, HTML for anything a browser will render, XML for a SOAP body or feed, CSV for a spreadsheet column, SQL for a literal in a hand-written query, Regular expression to match text literally, and Shell for one argument on a command line.

Why does the JSON output escape characters that were not special?

Only if you asked it to. By default the tool escapes exactly what RFC 8259 requires — the double quote, the backslash and every control character — plus any unpaired surrogate, which has no UTF-8 encoding and so cannot legally be written literally. That output is byte for byte what JavaScript's own JSON.stringify produces. The three switches add more: pure-ASCII output for a pipeline that mangles UTF-8, an escaped forward slash, and hiding <, > and & so the JSON can sit inside an HTML page without the parser finding a stray </script> in it.

Is escaping enough to stop SQL injection?

No, and it is worth being blunt about that. Escaping only protects a value that is already inside quotes, so it does nothing for a number, a table or column name, or an ORDER BY direction pasted into a query. It also has to match the exact dialect and server settings — MySQL reads a backslash as an escape unless NO_BACKSLASH_ESCAPES is on, and standard SQL does not. A parameterised query sends the value to the server separately from the statement, so there is no parsing step to subvert; use one wherever you can. This tool is for the cases where you are genuinely writing a literal by hand, such as a migration or a one-off report.

Why can it not unescape a regular expression or a shell command?

Because the answer would be a guess. In a regex, a backslash before a letter usually does not mean that letter: \d is any digit, \b is a word boundary and \w is a word character, so there is no way to tell an escaped literal from a metasequence without knowing what the author meant. Shell quoting has the opposite problem — the same argument can be written a dozen equally valid ways, and undoing it properly means running the shell's own word-splitting and expansion rules. Every other format here reverses cleanly, so those six offer both directions.

What happens to characters XML cannot hold?

They are reported rather than quietly emitted. XML 1.0 allows only three control characters — tab, line feed and carriage return — and there is no escape for the rest: &#1; is itself a parse error, not a way of writing character one. A tool that just swaps the five entities hands you a document that will not parse and does not say so. This one names the code points it found and offers to remove them, which is the only way to get a parseable XML 1.0 document out of that text. It also writes a carriage return as &#13; even in ordinary text, because a parser normalises a literal CR to a line feed before your program ever sees it.

Is my text uploaded anywhere?

No. Every rule runs in JavaScript inside your browser tab, so a connection string, an API key, a customer record or a password you are quoting for a command line never leaves your device. The page keeps working with the network switched off.