String Escape / Unescape

Escape a string for safe embedding in JSON, JavaScript, HTML, SQL, shell, or regex contexts. Or unescape strings copied from those contexts. Handles UTF-8 correctly.

How to use the String Escape / Unescape

Paste your string, pick the target context, choose Escape or Unescape. The escaped output is safe to drop into the chosen context. The unescape direction handles the same escape conventions as input.

Each context escapes differently

Embedding a string inside code means stopping certain characters from taking on special meaning. A double quote ends a JSON string unless you write \"; a < starts a tag in HTML unless you write &lt;; a single quote breaks out of a SQL literal unless it is doubled. Every context — JSON, JavaScript, HTML, SQL, shell, regex — has its own set of characters to escape and its own way of doing it.

Getting this wrong is not just a syntax error; it is the root of injection bugs, where unescaped input becomes executable code or markup. This tool escapes a string for whichever target you choose and unescapes strings copied out of those contexts, handling UTF-8 correctly. It is a convenience for crafting test data and config by hand — in application code, always use your language's parameterized queries and built-in escaping rather than escaping by string substitution.

Common use cases

  • Building JSON or config by hand — escape a value with quotes or newlines so it sits safely in a string field.
  • Embedding HTML — convert <, >, and & so text displays literally instead of as markup.
  • Shell commands — quote a string with awkward characters for a single-quoted shell argument.
  • Regex literals — escape metacharacters so a fixed string matches itself rather than acting as a pattern.
  • Unescaping copied strings — turn an escaped value from a log or source file back into its plain form.

Frequently asked questions

Does escaping here protect my app from injection?

This tool is for crafting test data and config by hand. In application code, rely on parameterized queries, templating auto-escaping, and your language's built-in functions — escaping by manual string substitution is fragile and easy to get wrong.

Why does each mode escape different characters?

Because each context defines its own special characters. JSON cares about quotes and backslashes, HTML about angle brackets and ampersands, SQL about single quotes, shell about quotes and spaces, regex about its metacharacters. The right escape depends entirely on where the string lands.

How are non-ASCII and emoji handled?

They are treated as UTF-8, so multibyte characters round-trip correctly. Where a context needs an escape sequence, such as JSON's \u form, the tool emits it; otherwise the character passes through.

What is the difference between escaping for SQL and using parameters?

Escaping quotes in a SQL literal is a stopgap; parameterized queries (prepared statements) keep data and code separate and are the correct defense against SQL injection. Use this mode for ad-hoc queries, not production code.
Embed this tool on your site

Free to embed, no attribution required (but appreciated). Paste this where you want the tool to appear: