String Escape & Unescape Tool

The complete guide to string escaping — JSON, HTML, JavaScript, URL, CSV, and SQL

Every string-related security incident I have read in the past decade — Equifax, MOVEit, Log4Shell, every weekend's fresh round of XSS reports — traces back to a string that crossed a context boundary without being re-escaped for the new context. Escaping is not boilerplate; it is the rule that keeps user data inside its data envelope and prevents it from being interpreted as code. This guide covers each escaping context the tool supports — what the escape sequences are, what the parser is actually defending against, and the language-level functions you should reach for instead of writing your own.

Context is everything — the same string needs different escaping in different places

The single biggest concept to internalise is context-specific escaping. A string flowing from a database into an HTML page should be HTML-escaped at the moment it is written into HTML. The same string flowing into a JavaScript string literal needs JS-string escaping. The same string going into a URL parameter needs percent-encoding. None of these escapings substitute for each other:

The two "don't escape" rows in that table are deliberate — they are the two places where ad-hoc escaping is the wrong tool. We will come back to them.

JSON escaping — what RFC 8259 actually requires

RFC 8259 (the current JSON spec) requires escaping just six characters inside string values: ", \, and the U+0000–U+001F control range. Everything else is allowed verbatim, including non-ASCII. Most JSON encoders also escape / defensively (so the string </script> doesn't break out of an inline JSON-in-HTML block), and many escape all non-ASCII to \uXXXX for transport safety:

• \" — double quote
• \\ — backslash
• \/ — forward slash (optional, but recommended for </script> safety)
• \b \f \n \r \t — control whitespace
• \uXXXX — any other control character or non-ASCII

The simple rule in JavaScript: if you can use JSON.stringify(value), do that. It is correct, fast, and tested by every browser vendor. Hand-rolling JSON escaping is how you get parse errors with surrogate pairs and U+2028 (line separator, which used to break JSONP).

HTML escaping — the OWASP rule of five

OWASP's HTML escaping recommendation is to encode five characters in element bodies:

This baseline covers element-body and double-quoted-attribute contexts. It does not cover JavaScript-event attributes (onclick), style attributes, or href/src URLs — those need additional context-specific encoding. The rule of thumb: never put untrusted data inside <script>, <style>, or unquoted attributes, ever.

URL encoding — encodeURIComponent vs encodeURI

This trips up everyone at least once. JavaScript ships two URL-encoding functions and they do different things:

• encodeURI(url) — encodes a full URL but leaves : / ? & = # alone because they are URL syntax characters. Use this on a complete URL you want to make safe for transmission, never on user data.
• encodeURIComponent(value) — encodes everything except A-Z a-z 0-9 - _ . ! ~ * ' ( ). Use this on every individual query parameter value or path segment.

If you ever find yourself reaching for escape() — stop. escape() is deprecated, produces non-standard output for non-ASCII, and is the wrong answer for everything in 2026.

CSV escaping — the RFC 4180 rules

CSV escaping is delightfully short:

1. If the field contains ,, ", \r, or \n, wrap the entire field in double quotes.
2. Inside that wrapping, double up any embedded " (so a single quote becomes "").

That is it. There is no standard backslash escaping in CSV; \n as two characters is treated literally. The other major risk — CSV injection — is when a field starts with =, +, -, or @ and Excel evaluates it as a formula on import. The OWASP fix: prefix any such cell with a single quote (') before saving. The picker handles RFC 4180 escaping; CSV-injection prefixing is a downstream sanitization step.

SQL escaping — why you should not be doing it

SQL "escaping" is the most dangerous category in this list. The historical pattern was to double-up single quotes (O'Brien → O''Brien) and string-concatenate the result into a query. Do not do this. Quoting alone does not defend against:

• Numeric injection — when the field has no quotes around it, escaping quotes does nothing.
• LIKE pattern injection — quoting % and _ requires a separate ESCAPE clause.
• Identifier injection — table/column names can't be parameterised in most drivers.
• Encoding-collision attacks — the classic 0xBF 0x27 bypass on misconfigured MySQL connections.

The correct answer is parameterised queries / prepared statements, where the database driver sends the SQL template and the values separately and the database engine never confuses them. Every modern driver supports this:

await client.query('SELECT * FROM users WHERE email = $1', [userEmail]);

cur.execute('SELECT * FROM users WHERE email = %s', (user_email,))

PreparedStatement ps = conn.prepareStatement(
  "SELECT * FROM users WHERE email = ?");
ps.setString(1, userEmail);

The SQL escape mode in this tool exists for emergency cases (one-off scripts, escaping a literal for a SQL editor pasted by hand). It should never be the layer that protects production code from injection.

JavaScript string escaping — the surprises

JavaScript string literals support a long list of escapes, and a few have non-obvious behavior:

• \xNN — two-digit hex, U+0000 to U+00FF.
• \uNNNN — four-digit hex, U+0000 to U+FFFF (a single UTF-16 code unit, which means surrogates land here).
• \u{NNNNNN} — variable-length, full Unicode 0x0 to 0x10FFFF (ES2015+). Use this for emoji and astral characters; it produces a correct surrogate pair.
• \0 — null, but only when not followed by a digit. \01 is an octal escape and a syntax error in strict mode.
• \v — vertical tab (U+000B), almost never used.
• Line continuation — a backslash at end of line continues the string. Allowed but discouraged.

JavaScript also has two characters that can break inline JSON-in-script blocks: U+2028 (line separator) and U+2029 (paragraph separator). They are valid in JSON but were illegal in JS string literals until 2019. Older code that writes <script>var data = ${JSON.stringify(x)};</script> needs to escape these to 
/
 for safety.

Common escaping mistakes that turn into vulnerabilities

• Double-encoding. Encoding a string twice ("just to be safe") makes & appear in your UI. Encode once, at the boundary.
• Escaping at the wrong layer. Sanitising user input on its way in to the database means every other consumer needs to know that. Escape on the way out, in the context of the destination.
• Building HTML by string concatenation. Use a templating engine that escapes by default (Handlebars {{x}}, JSX {x}, Jinja2 autoescape on). Mistakes are caught at the language level.
• Escaping URL-encoded data again. If you call encodeURIComponent on something that's already encoded you get %2520 instead of %20.
• Using innerHTML with sanitised input. Even sanitised HTML can carry mutation-XSS payloads. Prefer textContent for plain text; use setAttribute for attributes; use a vetted HTML sanitiser (DOMPurify) when you really need to render rich HTML.
• Trusting the regex you wrote in 2018. Browsers, attack techniques, and parser quirks all evolve. Use the platform escape function (encodeURIComponent, JSON.stringify, DOMPurify.sanitize) instead.
• Forgetting to escape the same string twice across formats. A string going into a JSON-in-HTML attribute needs both JSON encoding and HTML attribute encoding. Order: JSON first, then HTML escape the result.