String Escape/Unescape

Each format has its own set of characters that are structurally significant and therefore need to be neutralized before you can safely embed arbitrary text inside it. JavaScript string literals need backslashes, quotes, and control characters like newlines escaped so they don't prematurely end the string or break your code. HTML needs the characters that define markup itself — < > & " ' — converted to entities so they display as text instead of being interpreted as tags or attributes. URLs need any character outside a small 'safe' set percent-encoded so it survives transmission through browsers, servers, and proxies without being misread as a delimiter (like & or =). JSON strings follow a strict subset of JavaScript's escaping rules defined by the JSON specification itself. SQL string literals need embedded single quotes doubled so the database doesn't interpret them as the end of the string — a critical defense against SQL injection when literals are built manually.

Escaping and encoding are closely related — both transform text into a representation that's safe for a specific context — but neither is the same as sanitization or validation. Escaping preserves the exact original meaning of your text while making it safe to embed; it doesn't remove or judge content, it just changes how special characters are represented. Sanitization, by contrast, actively strips or rejects content it considers unsafe (like removing script tags from user input). This tool performs pure escaping/unescaping — it's a building block that's genuinely useful for security-conscious code (correctly escaping SQL string literals is a real defense against a class of SQL injection, for example), but it's not a substitute for parameterized queries, a proper HTML sanitizer library, or server-side input validation in a production application.

That's expected — a raw newline in your input (created by pressing Enter) is an actual line-break character, while '\n' (backslash followed by the letter n) is the two-character escape sequence JavaScript understands as representing a newline inside a string literal. Escaping converts the former into the latter, replacing the real invisible line break with a printable, two-character sequence your source code can safely contain on a single line; unescaping does the reverse, turning that two-character sequence back into a genuine line break in the output.

JSON's escaping rules are a strict, well-defined subset of JavaScript's string escaping — JSON only requires a smaller fixed set of two-character escapes (\" \\ \/ \b \f \n \r \t) plus \uXXXX for arbitrary code points, and doesn't support JavaScript-only sequences like \0 for null or \xXX hex escapes. This tool's JSON mode uses the browser's native, spec-compliant JSON.stringify and JSON.parse functions directly (rather than a hand-rolled implementation), so the escaped output is guaranteed to be exactly what a JSON parser expects — safe to drop directly inside a JSON string value.

Doubling embedded single quotes (turning O'Brien into O''Brien) is the ANSI SQL standard way to escape a quote inside a string literal, and it's the portable approach that works correctly across PostgreSQL, SQL Server, SQLite, Oracle, and standard-compliant databases. Some database systems — most notably MySQL in its default configuration — additionally support backslash-based escaping as a non-standard extension, but relying on it makes your escaped strings non-portable and can behave unexpectedly if that database's sql_mode changes. This tool intentionally sticks to the standard, portable quote-doubling approach; if you specifically need MySQL's backslash-escaping behavior, keep in mind it's a database-specific extension rather than the SQL standard.

No — even with correct escaping, manually concatenating strings into SQL queries is considered risky practice in real applications, because it's easy to miss an edge case (unusual character encodings, forgetting to escape a value, or a subtle bug in custom escaping logic) that reopens the door to SQL injection. The universally recommended approach in real code is parameterized queries or prepared statements, where the database driver handles value safety for you and the query structure is never built by string concatenation at all. This tool's SQL escaping mode is genuinely useful for learning how the underlying escaping mechanism works, for quick one-off scripts, or for constructing literals in contexts like database migration files or seed scripts — but for production application code handling user input, prefer parameterized queries.

The tool tells you rather than guessing. For JSON, an invalid escape sequence causes the underlying JSON parser to throw, and you'll see a clear 'Invalid JSON-escaped string' message. For URL unescaping, a malformed percent-encoding (like a stray % not followed by two hex digits) causes JavaScript's decodeURIComponent to throw a URIError, which this tool catches and reports clearly rather than silently producing garbled output. JavaScript, HTML, and SQL unescaping are more forgiving by design — matching the way browsers and JavaScript engines actually behave — and will pass through any sequence they don't recognize unchanged rather than failing, since real-world escaped text sometimes contains sequences outside the strict specification.

No. All escaping and unescaping happens entirely inside your browser using native JavaScript string, JSON, and URI APIs — there is no server-side component involved in processing your text at any point, which you can confirm by watching your browser's network tab while using the tool. This means the tool keeps working with no internet connection once the page has loaded, so it's safe to use with sensitive strings like API payloads, internal configuration values, or draft SQL containing real data.