Processing...
Pick a mode, choose Escape or Unescape, type or paste your string, then click Process →
Why String Escaping Matters
Every target format — JSON, HTML, SQL, URL, shell — has its own set of special characters that carry structural meaning. When user-supplied data contains those characters unescaped, the parser cannot distinguish data from structure. That ambiguity is the root cause of XSS, SQL injection, broken API payloads, and shell command injection.
Without escaping
SELECT * FROM users WHERE name='O'Reilly'The bare apostrophe closes the string literal — SQL syntax error or injection.
With escaping
SELECT * FROM users WHERE name='O''Reilly'The doubled apostrophe is treated as literal data. The query runs safely.
This tool covers all nine common developer escaping contexts in one place. Rather than switching between nine different browser tabs, paste once and switch modes.
Escape Characters Reference
| Format | Special characters | Escape method |
|---|---|---|
| JSON | " \ and control chars | \" \\ \n \r \t \uXXXX |
| HTML | < > & " ' | < > & " ' |
| XML | < > & " ' | < > & " ' |
| URL | All non-unreserved chars | %XX percent-encoding, space→+ |
| JavaScript | " ' ` \ and control chars | \" \' \` \\ \n \uXXXX \xXX |
| SQL | ' and \ (MySQL) | '' (ANSI) \\ (MySQL) |
| RegEx | . * + ? ( ) [ ] { } ^ $ | \ | Prefix with \ |
| Bash | All non-alphanumeric chars | Single-quote wrap, ' → '\'' |
| CSV | , " newline | Wrap in " and double internal " |
SQL Escaping: ANSI vs MySQL vs PostgreSQL
The ANSI SQL standard escapes a single quote by doubling it: O'Reilly → O''Reilly. This works in PostgreSQL, SQL Server, SQLite, and Oracle. MySQL supports the ANSI form but also treats backslash as an escape character by default (O\'Reilly), which this tool also outputs for maximum compatibility.
Important: escaping is not a substitute for parameterised queries
String escaping is for understanding and one-off tasks. In production code, always use prepared statements or parameterised queries — your database driver handles escaping automatically and correctly for the specific dialect and character set.
URL Encoding: Query Strings vs Path Segments
URL encoding converts characters to %XX hex sequences. The exact rules differ depending on where in a URL the value appears:
Query string ?key=value
Space encodes as + (HTML form convention). This is what this tool outputs. Used for application/x-www-form-urlencoded data.
hello world → hello+worldPath segment /path/here
Space encodes as %20. Slashes inside values must be %2F. Used when embedding dynamic values in URL paths.
hello world → hello%20worldFrequently Asked Questions
What is the difference between HTML and XML escaping?
Both escape <, >, and &. The key difference is the apostrophe: XML defines ' as a named entity, while HTML4 does not (HTML uses ' instead). HTML5 accepts both. Use XML escaping when generating well-formed XML documents; use HTML escaping for HTML content.
Why doesn't JSON escaping use < for the < character?
JSON has its own escape system using backslashes, entirely separate from HTML entities. A < character in a JSON string value is valid as-is — it only needs escaping if you are embedding the raw JSON inside an HTML <script> tag (where the browser stops parsing at </script>). In that case, additionally HTML-escape the JSON output.
Is escaping the same as encoding?
Not exactly, though the terms overlap in practice. Escaping keeps the string in the same format but marks special characters so they are treated as data rather than syntax (e.g. " → \" in JSON). Encoding transforms the representation — often between character sets or formats (e.g. a → %61 in URL encoding). URL percent-encoding is both: it encodes the byte value and escapes structural characters.
Why wrap bash strings in single quotes instead of double quotes?
Single quotes in bash suppress all special character interpretation — variables ($HOME), glob patterns (*), command substitution (backticks), and history expansion (!). Double quotes still expand $, backtick substitution, and \ sequences. Single-quote wrapping is the safest universal strategy for passing arbitrary strings as shell arguments.
Should I use this tool instead of parameterised queries for SQL?
No. Parameterised queries (prepared statements) are always the correct approach for production SQL. Your database driver handles quoting automatically for the specific dialect and character encoding. Manual escaping is error-prone across dialects, character sets, and edge cases. Use this tool for learning, debugging, and one-off data tasks — not as a substitute for safe database access patterns.