String Escaper: Quote, Embed, and Sanitize Strings Across JSON, HTML, SQL, and JS

TL;DR — The String Escaper escapes (and unescapes) text for JSON, HTML, JavaScript, SQL, Java, Python, and shell — one tool, no mental gymnastics. Pair with the JSON Formatter to verify your escaped string parses, and the HTML Entity Encoder for the entity-name variant.

What "escaping" actually means

Every text-based format has reserved characters with structural meaning: " ends a JSON string, < starts an HTML tag, ' ends a SQL string literal. To include those characters as literal data, you replace them with an escape sequence the parser understands as "treat this as content, not syntax."

The escape rules per format

Format	Must escape	How
JSON	" \ / + control chars	Backslash: \" \\ \n \t \uXXXX
HTML	< > & " '	Entities: &lt; &gt; &amp; &quot;
JavaScript	' " ` \ + newlines	Backslash escapes; or use template literals
SQL	'	Double up: ' → '' (or use parameterized queries)
Shell (Bash)	' " $ ` \ ! *	Single-quote whole string, or backslash-escape
URL	Almost everything	Percent-encode (see the URL Encoder)

Why this matters beyond syntax errors

• SQL injection. Unescaped user input in a SQL query lets attackers run their own commands. The fix is parameterized queries; the band-aid is escaping.
• XSS. Unescaped user content rendered as HTML lets attackers run their JavaScript on your users’ pages. Always HTML-escape user-generated text before insertion.
• Shell injection. Passing unescaped user input to a shell command is how servers get pwned. Always escape — or better, avoid the shell entirely.

Escape any string in 5 seconds

1. Open the String Escaper.
2. Paste the raw text.
3. Pick the target format (JSON, HTML, JS, SQL, etc.).
4. Copy the escaped result; or toggle to Unescape for the reverse.

Example: putting a SQL query inside a JavaScript string

// Raw query
SELECT * FROM users WHERE name = 'O\'Brien'

// Escaped for a JS string
"SELECT * FROM users WHERE name = 'O\\'Brien'"

The right way vs the cheap way

Escaping is the cheap way. The right way is to use the API for your context: parameterized queries for SQL (? or $1 placeholders), template engines for HTML (which auto-escape), and execFile with array args instead of exec for shell. Escaping is what you reach for when those aren’t available, and what you double-check with the String Escaper when they are.

FAQ

Is escaping enough to prevent SQL injection?

Technically yes if done perfectly. Practically no — humans miss edge cases. Use parameterized queries; reserve escaping for truly dynamic SQL that can’t be parameterized.

Should I escape user input before storing or before displaying?

Before displaying, in the format of the target context. Storing raw is usually correct — you don’t know yet whether it’ll be rendered as HTML, JSON, or plain text.

What’s the difference between escaping and encoding?

Mostly the same idea in different formats. "Escaping" usually refers to source-code contexts (JSON, JS, SQL). "Encoding" usually refers to transport (URL, Base64, HTML entities).

Safe-strings toolkit

• String Escaper — every common format in one place.
• JSON Formatter — verify escaped JSON parses.
• HTML Entity Encoder — named-entity variant.