Escape and Unescape Online — JSON, XML, HTML, SQL

A single browser-based tool for escaping and unescaping strings across the four formats developers handle every day: JSON, HTML, XML and SQL. Paste a value, pick the target format, and the conversion happens live in your browser. Nothing leaves the page.

What it does

The escape/unescape tool takes any input string and either encodes its special characters into the syntax required by a target format, or decodes a previously-escaped string back to its raw form. It supports four formats in one interface:

• JSON — handles \", \\, \n, \r, \t, \b, \f, \/ and Unicode escapes of the form \uXXXX, including surrogate pairs for characters outside the BMP.
• HTML — converts &, <, >, ", ' and produces numeric entities like   for non-printable or non-ASCII characters when needed.
• XML — like HTML but limited to the five predefined entities (&, <, >, ", '), the only ones an XML parser is guaranteed to understand without a DTD.
• SQL — escapes single quotes, backslashes, and control characters in a way that matches the dialect you select (ANSI single-quote doubling, MySQL backslash escapes, or PostgreSQL E'...' strings).

You can switch direction with one button: the same panel encodes or decodes. A live mode applies the transform as you type, and a per-line mode treats each line of input as an independent string — useful when you have a list of values and want to escape every one of them at once.

Who it's for

• Backend and frontend developers embedding literal strings into source code, config files, or rendered templates. The classic case: pasting a JSON sample into a JavaScript file and watching it break because of an unescaped quote.
• Security researchers and pentesters probing how an application handles encoded payloads. The tool is useful for crafting test strings, but it is not a substitute for output encoding inside the application itself.
• Database administrators who occasionally hand-write a SQL statement and need to embed a value containing apostrophes, newlines, or backslashes.
• Ad-tech and integration engineers dealing with JSON-in-JSON: the OpenRTB adm field that contains a stringified VAST tag, or an event payload nested inside a tracking URL.

When to use it

Some concrete situations where this tool saves time:

• Embedding strings in code. You want to paste a multi-line snippet of HTML into a JavaScript string literal. Escape it once with JSON rules and the result drops in cleanly between double quotes.
• Sanitising user input for HTML output. You have a comment body or a log line containing <script> tags or ampersands and you need a clean preview of what it will look like when rendered as text.
• Hand-building a SQL query for an ad-hoc fix. The user's last name is O'Brien. You want a quick way to produce a safe literal without firing up a full client.
• Working with JSON-in-JSON. A creative payload is stored as a string field inside an OpenRTB bid response. To inspect or edit it, you unescape it once to recover the original JSON, edit, then re-escape it back into the wrapper.
• Debugging an XML feed. A VAST tag has a tracking URL with query-string ampersands that aren't entity-encoded — the parser rejects it. You paste, escape as XML, and slot the result back in.

Features

How escaping works, conceptually

Each format defines its own grammar for representing characters that would otherwise be ambiguous or illegal. Here is a brief walk through with examples.

JSON

JSON strings are delimited by double quotes, so a literal double-quote inside the string must be escaped. The same applies to the backslash itself, and to control characters which are forbidden in raw form.

Input:  She said "hello\world"
Output: "She said \"hello\\world\""

Unicode characters outside ASCII may be left as UTF-8 bytes or written as \uXXXX. For characters above U+FFFF, JSON uses a UTF-16 surrogate pair — for example, the emoji U+1F600 becomes 😀.

HTML

In HTML, the characters <, > and & have special meaning. Inside attribute values, " and ' are also dangerous depending on which quote you used as a delimiter.

Input:  Tom & Jerry <3 cheese
Output: Tom &amp; Jerry &lt;3 cheese

The tool can also emit named entities ( ) or numeric ones ( ) depending on the option you pick.

XML

XML has only five predefined entities. If you need anything else as an entity reference, you have to declare it in a DTD — which most people do not want to do. The pragmatic rule: encode the five, and emit everything else as raw Unicode (assuming the document is UTF-8).

SQL

SQL escaping is dialect-dependent. The ANSI rule is simple: double the single quote ('O''Brien'). MySQL and SQLite also accept backslash escapes ('O\'Brien'). PostgreSQL distinguishes ordinary strings (ANSI rules) from escape strings prefixed with E (C-style backslash escapes). The tool offers a dialect selector so you can match your target database.

Common pitfalls

• Double-escaping. Running escape twice on the same string is the most common mistake — every \ becomes \\, and your JSON suddenly contains literal backslashes. The fix: keep careful track of which side of the boundary your data is on. If in doubt, unescape first and then escape exactly once.
• Missing Unicode handling. Some naive escapers handle only ASCII control characters and pass everything else through literally. That breaks the moment a user pastes an em-dash or a curly quote and the receiving system is configured for ASCII or Latin-1.
• SQL injection prevention vs proper parameterisation. Escaping is not a substitute for parameterised queries. Use prepared statements with bind parameters in production code; reserve hand-escaping for ad-hoc queries you run yourself, or for cases where parameterisation is genuinely unavailable.
• HTML context confusion. The right escape depends on where the value lands: element text, attribute value, JavaScript string inside a <script> tag, URL query parameter, or CSS context all have different rules. This tool covers the element-and-attribute case; the others need a context-aware library.

FAQ

Should I use this for security?

For learning, testing and ad-hoc fixes, yes. For production output encoding, no — use a context-aware library in your framework (Django's autoescape, React's JSX, Spring's HtmlUtils, etc.). The right escape depends on the context the data lands in, and a one-shot tool cannot know that for you.

What about \xHH escapes?

JSON does not support \xHH — only \uXXXX. JavaScript string literals do support it, and so do C, Python and several other languages. The tool's JSON mode rejects \xHH on decode by default; switch to "JS string" mode to accept it.

How are Unicode surrogates handled?

On encode, characters above U+FFFF are written as a pair of \uXXXX escapes (the standard JSON behaviour). On decode, the tool reassembles surrogate pairs into single code points before returning the result, and warns about unpaired or invalid surrogates rather than silently passing them through.

Does it support custom HTML entities?

On decode, yes — the full HTML5 named entity set is supported. On encode, the tool emits named entities only for a small core (&, <, >, ", ',  ) and uses numeric entities for everything else. Numeric entities are more portable and avoid the obscure-name problem.

Related tools

• URL encoder and decoder — percent-encoding for query strings and path segments.
• JSON beautifier and validator — pretty-print, minify, and validate JSON payloads.
• Text diff — compare before-and-after of an escape transformation.

Related reading

• JSON formatting best practices
• URL encoding explained