String Escape / Unescape

Why JSON-escaping "café" or an apostrophe gives you \u-codes

This tool's JSON mode runs your input through System.Text.Json's default serializer, which is deliberately stricter than the JSON spec requires. By default it escapes every character outside the printable ASCII range as a six-character \uXXXX sequence — not just control characters and quotes — and for HTML-embedding safety it also escapes the angle brackets, ampersand, and apostrophe, none of which plain JSON syntax actually requires. Escape the word café and the accented letter comes back as the escape sequence backslash-u-zero-zero-e-nine, instead of the original character. Escape <script> and each angle bracket comes back as its own backslash-u escape sequence too, instead of the literal < and > characters. Both forms are valid, spec-compliant JSON — a parser decodes the \u-escaped form and the original character to the exact same string — but it surprises people who expect "JSON escape" to only touch backslashes, quotes, and newlines.

Supported formats

Escaping vs encoding — the distinction

The terms are often used interchangeably but technically differ. Escaping adds a prefix character (like a backslash) before a special character to remove its special meaning: \n is a newline escape in most programming languages. Encoding replaces a character with an alternate representation using a defined scheme: %20 replaces a space in URL encoding, & replaces & in HTML encoding. Both achieve the same goal — making a character safe in a context where it would otherwise be interpreted — through different mechanisms.

How to use this tool

1. Pick Escape or Unescape using the toggle.
2. Select the target format from the dropdown (JSON, HTML, URL, C#/Java, Regex, or XML).
3. Paste your text into the input editor.
4. Click the action button and copy the safe output.

Security implications of missing escapes

Failing to escape output is the root cause of the two most common web vulnerabilities. Cross-site scripting (XSS) occurs when user input is inserted into HTML without HTML escaping — the browser executes the injected script in the victim's session. SQL injection occurs when user input is inserted into a SQL query without proper parameterisation (SQL has its own escaping rules, handled by prepared statements). Both are entirely preventable by escaping all untrusted data before inserting it into any format — HTML, SQL, JSON, or XML.

The C# / Java mode only covers six specific sequences

Unlike the JSON mode, the C# escaper here isn't built on a library's string serializer — it's a fixed chain of six character replacements: backslash, double-quote, newline, carriage return, tab, and the null character. That covers what you'll hit constructing an ordinary string literal from pasted text. It does not escape the other standard C# escape sequences — bell, backspace, form feed, or vertical tab — so a raw control character of one of those kinds in your input passes through unescaped rather than becoming \a, \b, \f, or \v. In practice this almost never matters, since those characters essentially never appear in real text content, but it's not a complete implementation of every C# escape sequence — just the ones that actually come up.