String Escaper
Escape or unescape strings for JSON, JavaScript, HTML, SQL and CSV contexts.
How to use the String Escaper
Pick a format (JSON, JS, HTML, SQL or CSV) and a direction.
Paste your string.
Copy the escaped or unescaped result.
Why the same string needs different escaping in different formats
A string containing a quote, newline, or backslash breaks whatever format you're embedding it in unless you escape it — but each format has its own escaping rules. JSON backslash-escapes control characters and quotes (a literal newline becomes \n, a quote becomes \"); it's stricter than JavaScript string literals, which additionally support single-quote and template-literal delimiters, so "escape for JS" and "escape for JSON" produce subtly different output for the same input. SQL string literals only need embedded single quotes doubled ('' instead of a backslash) — but escaping alone doesn't stop SQL injection; parameterized queries / prepared statements are the actual defense, escaping just makes a literal safe to embed by hand. CSV (RFC 4180) wraps a field in double quotes whenever it contains a comma, quote, or newline, and doubles any internal quotes — a field with no special characters needs no escaping at all, which trips people up when a value inconsistently gets quotes across rows. This tool runs all five conversions (JSON, JavaScript, HTML, SQL, CSV) with real escape/unescape logic per format, not one generic backslash rule reused everywhere.
For a step-by-step walkthrough, read our guide: String Escaping: JSON, JavaScript, HTML, and SQL.
Key features
- Five formats in one tool: JSON, JavaScript, HTML, SQL and CSV
- Escape and unescape (round-trip) in both directions
- Format-correct rules — JSON \n vs SQL doubled quotes vs CSV RFC 4180 quoting
- Instant, private conversion as you type
Frequently asked questions
What exactly does JSON escaping change?
It backslash-escapes double quotes, backslashes, and control characters (newline → \n, tab → \t) so the string can sit inside a JSON string literal without breaking the surrounding structure.
Does escaping for SQL make a query injection-proof?
No — quote-doubling makes a literal syntactically safe to embed, but parameterized queries / prepared statements remain the real defense against SQL injection; treat this as a formatting convenience, not a security control.
Why does my CSV field only get quotes sometimes?
RFC 4180 only requires quoting a field when it contains a comma, a double quote, or a newline — plain text fields are left bare, which is correct CSV, not inconsistent output.
Can I reverse the process to get my original string back?
Yes — switch to Unescape with the same format selected, and it decodes the escaped string back to plain text.