Text escaping
Quotes, line breaks, angle brackets — the usual trouble spots when building strings. Escape them here first.
SQL escaping only doubles single quotes,Does not replace parameterized queries. Concatenated SQL always carries injection risk; this is only for generating literals for debugging.
When to use it
- You are writing a JSON request body by hand and need to place one user-supplied string inside a value: JSON mode returns exactly the escaped contents for the space between the quotes, backslashes, newlines and tabs included.
- A log line or API field shows " and you want to know how many layers deep the encoding goes: decode the fragment once in HTML mode, and if an entity such as " is still there, it was escaped at least twice.
When not to
- You are about to concatenate untrusted input into a SQL statement. SQL mode only doubles single quotes; MySQL still treats backslash as an escape by default, and numbers, ORDER BY column names and LIKE wildcards are outside its reach. Use a parameterized query (? or $1) instead.
- You need to sanitise user-submitted HTML before rendering it. This escapes five characters only: on* handlers, javascript: URLs and unquoted attributes pass straight through. Use a whitelist sanitiser such as DOMPurify.
Escaping runs entirely in your browser: nothing is uploaded or logged. Limits: JSON mode handles a single string value, not whole documents; SQL mode only doubles single quotes and is no protection under MySQL backslash mode or in numeric and identifier positions, and cannot replace parameterized queries; HTML mode covers five characters and is not an XSS sanitiser; escaping is not idempotent.
Frequently asked
Does SQL escaping prevent SQL injection?
Not on its own. SQL mode doubles the single quote, which is how standard SQL quotes a literal, but MySQL treats backslash as an escape character by default, so \' still breaks out, and wide-byte charsets such as GBK have a long history of dedicated bypasses. Numeric parameters, ORDER BY column names and the % and _ in LIKE cannot be fixed by quoting at all. It is fine for making a one-off manual query run; in application code use prepared statements. Escaping is a fallback, never the defence.
Why is there no surrounding double quote in the JSON output?
Because the tool returns the inside of the string, ready to drop into an existing "..." pair; add the outer quotes yourself when you need a complete JSON literal. On the way back it parses the whole input as one JSON string, so an unescaped quote inside it produces an error rather than a half-decoded result — do not use it to guess what a broken escaped string meant. If the output goes inside an HTML <script> block, also neutralise </script>, U+2028 and U+2029, or the script closes early or fails to parse.
Escaping twice turns & into &amp; — is that a bug?
No. Escaping is not idempotent: & becomes &, then the & inside that becomes & again, giving &amp;. This is exactly why a page sometimes shows the text &: the value was escaped twice and decoded once. Escape once, at the moment the value enters its target context. When you receive a field someone else escaped, work out how many layers it has and undo them in one pass instead of clicking decode on reflex every time you see an ampersand.