String Escape / Unescape

String escaping replaces characters that have special meaning in a given context with safe encoded equivalents. For example, a double quote inside a JSON string must be escaped as \" because an unescaped quote would terminate the string prematurely. Escaping prevents syntax errors, injection vulnerabilities (XSS, SQL injection), and data corruption. Different contexts (JavaScript, HTML, URLs, SQL, etc.) have different characters that must be escaped and different escape syntaxes.

This tool is a universal escape/unescape utility that supports 12 different contexts in one place. The dedicated URL Encoder and HTML Entity tools focus on a single context with more specialized options. Use this tool when you need to quickly switch between contexts or compare how the same string is escaped differently across languages and formats.

Yes. All escape and unescape operations use JavaScript's native Unicode support. Unicode characters outside the ASCII range are preserved in most contexts. For JSON and JavaScript, characters are escaped using standard \uXXXX notation when necessary.

The tool correctly implements standard escaping rules for each context. However, for security-critical operations (preventing XSS, SQL injection), always use your framework's built-in escaping or parameterized query functions rather than manually escaping strings. This tool is best used for debugging, understanding escape behavior, and preparing test data.

The Swap button copies the output to the input field and toggles the direction (Escape ↔ Unescape). This lets you quickly reverse an operation: escape a string, then swap to verify it unescapes back to the original. It is also useful for chaining operations — escape for one context, then swap and re-escape for a different context.

Because manual escaping is fragile and easy to get subtly wrong, and a single miss is a vulnerability. For SQL, the correct defense is parameterized queries (prepared statements), which send the query structure and the data separately so user input can never be interpreted as SQL — escaping quotes by hand can't match that guarantee, especially across encodings and edge cases. For HTML/XSS, use your framework's context-aware auto-escaping (React, Vue, and templating engines do this on output). Manual escaping is excellent for debugging, preparing test data, and understanding what's happening — but production security should rest on parameterized queries and framework escaping, not strings you escaped by hand.

Escape from the inside out, once per layer, in the right order. Consider a value going into an onclick attribute: it lives in a JavaScript string (innermost) that sits inside an HTML attribute (outer). You first apply JavaScript-string escaping, then HTML-attribute escaping on top — and the browser decodes them in reverse when it parses. Getting the order or count wrong causes either broken syntax or, worse, an injection hole. This is exactly why inline event handlers and dynamically-built script are discouraged: nested contexts are error-prone. When you can, avoid the nesting (use addEventListener and data attributes); when you can't, escape each layer deliberately and test the round-trip.