Overview
Escapes or unescapes a string for eight different contexts - JavaScript string literals, JSON, HTML, XML, URLs, CSV, SQL, and regular expressions - in one page, in both directions. It exists because 'escaping' means something different in each of those worlds, and pasting a value escaped for one context into another is how injection bugs and parse errors are born.
How It Works
Pick a target context, pick Escape or Unescape, and type into the left panel. The result appears on the right as you type; click it to copy. Unescaping is offered only where the mapping is unambiguous - the tool tells you plainly that escaped regular expressions cannot be reversed, because '\d' is a character class, not a backslashed letter d.
Step-by-Step Usage Guide
- Choose the context you are escaping for - JSON, SQL, HTML, and so on.
- Paste your raw text if you are escaping, or the already-escaped text if you are unescaping.
- Copy the result and paste it into your code, query, or template.
- If a value must be valid in two contexts (for example, text inside a JSON string inside an HTML attribute), escape for the innermost context first and verify each layer.
Technical Specifications & Standards
Each target follows the standard that governs it, not a generic approximation. JSON escaping follows RFC 8259: quotes and backslashes are backslashed and control characters below 0x20 become \n, \t, or \uXXXX. CSV follows RFC 4180: a field is wrapped in quotes only when it contains a comma, quote, or line break, and embedded quotes double - which is why 'plain' stays plain. SQL uses the doubled single-quote convention ('' for ') that is portable across standard SQL, MySQL, and PostgreSQL. HTML uses named entities (< > & " ') and XML uses ' where HTML would not. URL escaping is encodeURIComponent, and unescaping decodes + as a space for query-string convenience. JavaScript unescaping handles \xHH, \uHHHH, \u{...} code points up to U+10FFFF, legacy octal escapes, and the JS rule that an unknown escape like \q simply yields q - with an out-of-range code point rejected rather than silently wrapped.
Targeted Use Cases
- Putting user text into a JSON payload without breaking the string or the parser.
- Building a SQL WHERE clause safely from a value that contains an apostrophe, like O'Brien.
- Cleaning up copied CSV exports where quoted fields were double-escaped.
- Decoding entities from scraped HTML back into readable text.
Notes & Gotchas
- Escape at the boundary: keep data raw in your code and escape only at the moment it enters another format.
- Never stack escapes blindly - double-escaping (&lt;) is the most common escape bug.
- For SQL, parameterised queries beat string escaping whenever you control the code; escaping here is for the cases you do not.
- Remember escaping is not security by itself: HTML-escape for element text, but attribute values also need quote escaping - this tool does both.
Frequently Asked Questions
Why can't regex escapes be unescaped?
Backslashing in a regex is overloaded: \d, \w, and \s are character classes, not escaped letters, so no algorithm can know whether \d means 'the letter d' or 'any digit'. Reversal would guess, and guesses in this area become bugs.
Does escaping make my SQL safe from injection?
Doubled-quote escaping handles the classic quote-breakout for string literals, but parameterised queries are the real defence. Use this when you cannot change the query construction - for example when generating SQL from data you control.
Why does my CSV field sometimes gain quotes?
RFC 4180 only requires quoting when the field contains a comma, a quote, or a line break. Fields without those characters stay bare, which keeps the output clean and still parses identically.
What is the difference between HTML and XML escaping here?
They share < > & and ", but the single quote is written as ' for HTML (where ' is valid but less traditional) and ' for XML, which defines it. Both decode correctly either way in practice.