How to Escape Strings for JSON, HTML, SQL, and Regex

You can escape and unescape strings for JSON, HTML, SQL, Regex, and URL encoding entirely in your browser using brevio String Escape Tool — everything runs locally in JavaScript, with zero network transmission. Results update on every keystroke.

Unescaped input injected into JSON, HTML, SQL, or Regex is a primary source of security vulnerabilities — SQL injection, cross-site scripting (XSS), broken parsers. Understanding what each mode does and when to use it reduces bugs and security risks.

How to Use the String Escape Tool

1. Open brevio String Escape Tool. No account required.
2. Choose Escape or Unescape depending on your task.
3. Select the target format: JSON, HTML, SQL, Regex, or URL.
4. Paste or type your string. The result appears immediately — no button to click.
5. Click Copy to use the output in your code.

How to Verify No Data Is Transmitted

1. Open DevTools. Press F12 on Windows/Linux or ⌘⌥I on Mac.
2. Go to the Network tab. Filter to Fetch/XHR.
3. Paste your string into the input field.
4. Observe the Network tab. You will see zero outbound requests. All escaping logic runs in JavaScript in your browser — no keystrokes or string content are transmitted. This is particularly important when escaping strings that contain API keys, passwords, or confidential content.

Each Escape Mode Explained

JSON Escaping

JSON strings must escape certain characters to be valid. When building JSON programmatically or embedding dynamic values in JSON payloads, missed escaping causes JSON parse errors or, in some contexts, injection.

Example: the string Hello "world"\nNew line becomes Hello \"world\"\nNew line when JSON-escaped.

HTML Escaping

HTML escaping converts characters that have special meaning in HTML into their entity equivalents so they render as literal characters rather than being interpreted as markup. This is the primary defense against XSS (cross-site scripting) attacks.

Example: <script>alert(1)</script> HTML-escaped becomes <script>alert(1)</script> — harmless text rather than executable code.

SQL Escaping

SQL escaping prevents SQL injection by escaping the single quote character — the most common injection vector. In standard SQL, a literal single quote inside a string is represented by doubling it.

Example: O'Brien SQL-escaped becomes O''Brien.

Important: SQL escaping alone is not a complete injection defense. Use parameterized queries (prepared statements) for any production code — they prevent injection regardless of input content. SQL escaping is useful for one-off data migration scripts and when understanding what a raw escaped query would look like.

Regex Escaping

When you construct a regular expression dynamically from user input or a string variable, any regex metacharacters in that string must be escaped — otherwise they are interpreted as operators rather than literal characters.

Regex metacharacters that are escaped: . * + ? ^ $ { } ( ) | [ ] \

Example: searching for the literal string 3.14 in text using a regex requires escaping the dot: 3\.14 (otherwise . matches any character, so 3.14 would also match 3x14).

Note: Regex unescape is not available since it is not a standard reversible operation — a regex escape sequence has context-dependent meaning depending on the surrounding pattern.

URL Encoding

URL encoding (percent-encoding) converts characters that are not safe in a URL to %XX hex sequences. This is used for query parameter values, form submissions, and any user-supplied text embedded in a URL.

Example: hello world & more URL-encoded becomes hello%20world%20%26%20more.

This tool uses encodeURIComponent() — the correct JavaScript function for encoding individual query parameter values. It encodes everything except letters, digits, and - _ . ! ~ * ' ( ). Do not use encodeURI() for values — it leaves characters like & and = unencoded, which breaks query strings.

Common Escaping Mistakes

String Escape Tool Comparison

Using Browser DevTools Console as an Alternative

For quick one-off escaping without opening a dedicated tool, the browser console handles the most common cases:

// JSON escape
JSON.stringify("hello \"world\"\nnew line")
// → '"hello \"world\"\nnew line"'

// URL encode
encodeURIComponent("hello world & more")
// → 'hello%20world%20%26%20more'

// URL decode
decodeURIComponent("hello%20world%20%26%20more")
// → 'hello world & more'

Frequently Asked Questions

Why does string escaping matter for security?

Unescaped user input injected into a structured context (HTML, SQL, JSON, a regex) is interpreted as part of the structure rather than as literal data. SQL injection exploits unescaped quotes in database queries to append attacker-controlled SQL clauses. XSS exploits unescaped HTML to inject JavaScript into a victim's browser. Proper escaping treats all user input as data — never as code.

Is JSON escaping the same as JavaScript string escaping?

Similar but not identical. JavaScript strings support more escape sequences (\', \0, \xHH, template literals) that are not valid in JSON. JSON requires double-quote delimiters and does not allow single-quoted strings. When in doubt for JSON contexts, use JSON.stringify() — it produces spec-compliant JSON escaping every time.

When should I use HTML escaping vs URL encoding?

HTML escaping is for content rendered inside HTML elements or attributes — preventing characters from being interpreted as markup. URL encoding is for values embedded in URLs — preventing characters from being misinterpreted by URL parsers. They are applied in different contexts and cannot substitute for each other: a URL-encoded string placed directly in HTML as user-visible text will display literal %20 instead of a space.

Does the tool send my escaped strings to a server?

No. All escaping and unescaping logic runs locally in JavaScript in your browser. Verify with DevTools → Network tab: paste your string and confirm no outbound requests fire. This is important when escaping strings that contain credentials, API keys, connection strings, or confidential content — common in developer workflows.

Can I use this tool to prevent SQL injection in production code?

Not as a primary defense. SQL escaping (doubling single quotes) is a last resort for one-off scripts. In production code, use parameterized queries (prepared statements) provided by your database driver — they separate the query structure from the data entirely, making injection impossible regardless of input content. SQL escaping via string manipulation is error-prone and incomplete as a defense mechanism.