Why Escaping Text Matters
Character escaping is one of the most fundamental operations in software development. Every data format and programming language reserves certain characters for structural purposes: JSON uses double quotes and backslashes, HTML uses angle brackets and ampersands, CSV uses commas and double quotes, and JavaScript strings use quotes and backslashes. When your actual data contains these reserved characters, they must be escaped — replaced with safe sequences that the parser can distinguish from structural syntax.
Failing to escape text properly leads to parsing errors at best and security vulnerabilities at worst. Unescaped HTML can enable Cross-Site Scripting (XSS) attacks. Unescaped JSON breaks API payloads. Unescaped CSV corrupts spreadsheet imports. This tool handles all of these formats in one place, giving you instant, correct escaping and unescaping without installing any libraries.
JSON Escaping
The JSON specification (RFC 8259) defines a strict set of escape sequences for string values. Inside a JSON string, the following characters must be escaped:
\"— double quote (the string delimiter)\\— backslash (the escape character itself)\n— newline (line feed, U+000A)\r— carriage return (U+000D)\t— horizontal tab (U+0009)\b— backspace (U+0008)\f— form feed (U+000C)\uXXXX— any Unicode character by its hexadecimal code point
All control characters (U+0000 through U+001F) must be escaped using the \uXXXX notation if they do not have a dedicated shorthand. JSON does not support single-quoted strings, so single quotes do not need escaping. Forward slashes may optionally be escaped as \/, which is sometimes used to prevent </script> injection when embedding JSON in HTML.
A common use case for JSON escaping is building API request bodies programmatically. When constructing a JSON string by concatenation instead of using JSON.stringify(), forgetting to escape user input that contains quotes or backslashes will produce invalid JSON and crash the consumer.
HTML and XML Escaping
HTML and XML escaping replaces characters that have structural meaning in markup with their entity equivalents. The five critical characters are:
&→&(ampersand starts entity references)<→<(less-than opens tags)>→>(greater-than closes tags)"→"(double quote delimits attribute values)'→'(single quote in attribute values)
Proper HTML escaping is the primary defense against XSS attacks. When user-supplied content is rendered in a web page without escaping, an attacker can inject <script> tags that execute arbitrary JavaScript in other users’ browsers. Modern frameworks like React, Angular and Vue escape output by default, but developers working with raw HTML strings, template literals or innerHTML must escape manually.
XML escaping follows the same rules as HTML, with one addition: CDATA sections. Text wrapped in <![CDATA[...]]> is treated as literal content and does not need escaping. This tool’s XML mode preserves CDATA sections intact while escaping all other content.
CSV Escaping
CSV (Comma-Separated Values) is deceptively simple until you encounter fields that contain commas, quotes or newlines. The RFC 4180 standard defines these rules:
- Fields containing commas, double quotes or newlines must be enclosed in double quotes.
- Double quotes within a quoted field are escaped by doubling them: a field containing
say "hello"becomes"say ""hello""". - Leading and trailing whitespace in a quoted field is preserved.
CSV escaping bugs are a common source of data corruption when exporting data to spreadsheets. If a field like San Francisco, CA is not quoted, the comma splits it into two columns, misaligning all subsequent data in the row. This tool wraps all non-empty fields in quotes for maximum safety.
JavaScript String Escaping
JavaScript strings can be delimited by single quotes, double quotes or backticks (template literals). Each delimiter character must be escaped when it appears inside a string of that type. Additionally, these escape sequences are recognized:
\\— backslash\n— newline\r— carriage return\t— tab\0— null character\uXXXX— Unicode escape (BMP)\u{XXXXX}— Unicode escape (full range, ES2015+)\xHH— Latin-1 hex escape
This tool escapes all three quote types simultaneously, so the output is safe regardless of which delimiter you use. Control characters and non-printable characters in the range U+007F to U+009F are converted to \uXXXX notation.
Escaping vs Encoding: What’s the Difference?
Escaping and encoding are related but distinct concepts. Escaping adds a prefix (like a backslash) to indicate that the following character should be interpreted literally, not as syntax. Encoding transforms the entire character into a different representation (like Base64 or URL percent-encoding). The boundary can be blurry — HTML entities are often called “encoding” even though they function as escape sequences — but the intent is the same: make data safe for a specific context.
Common Mistakes
Several escaping pitfalls trip up even experienced developers:
- Double escaping: Escaping text that has already been escaped produces sequences like
\\n(a literal backslash followed by the letter n) instead of an actual newline. Always escape raw text, not pre-escaped text. - Wrong context: HTML-escaping a value that will be placed in a JavaScript string does not prevent XSS. Each context (HTML content, HTML attribute, JavaScript string, URL parameter, CSS value) requires its own escaping rules.
- Forgetting unescaping: When reading escaped data back, you must unescape it to recover the original content. Displaying
<div>to a user instead of<div>is a sign that unescaping was skipped. - Platform differences: Windows uses
\r\nfor line endings while Unix uses\n. CSV files from Excel on Windows will contain\r\n, which must be handled during both escaping and parsing.
When to Escape Text
The golden rule is: escape at the boundary. Do not store pre-escaped data in your database (it makes searching and processing harder). Instead, store raw text and escape it at the moment you output it to a specific format:
- Escape for JSON when serializing API responses
- Escape for HTML when rendering templates
- Escape for CSV when exporting data files
- Escape for JavaScript when embedding values in inline scripts
This approach ensures that the same source data can be correctly output to multiple formats without cross-contamination of escape sequences.
Frequently Asked Questions
What is the difference between escaping and sanitizing?
Escaping converts special characters to safe representations while preserving the original content. Sanitizing removes or strips potentially dangerous content entirely. For example, HTML escaping converts <script> to <script> (preserving the text), while HTML sanitizing would remove the entire script tag. Both are valid security strategies depending on the context.
Should I use this tool for production escaping?
This tool is ideal for quick one-off transformations, debugging, and verifying escaping behavior. For production code, always use your programming language’s built-in escaping functions (like JSON.stringify(), your framework’s template escaping, or a dedicated library) to ensure correctness and performance at scale.
Is my data safe?
Yes. This tool runs entirely in your browser using JavaScript. No data is transmitted to any server. You can verify this by checking the Network tab in your browser’s developer tools while using the tool.
Can I escape for multiple formats at once?
You should escape for only one format at a time. Each format has its own set of reserved characters and escape rules. Use the “Output to Input” button if you need to chain transformations, but be aware that double-escaping is usually a mistake.