Free String Escape/Unescape Online

Use string escape/unescape when raw text needs to travel safely inside a format that treats certain characters as special — a quote inside a JSON string, an angle bracket inside HTML, a space inside a URL, or a newline inside a JavaScript source file. Escaping converts those troublesome characters into a safe representation the target format won't misinterpret; unescaping reverses the process, turning the safe representation back into the original text. This tool covers both directions for JSON-style string literals directly in the browser, with quick reference to how the same escaping problem plays out across HTML, URLs, and JavaScript source, so you can pick the right approach for whichever format you're actually working with.

How the String Escape/Unescape Tool Works

The layout is deliberately minimal — one input box, an Escape/Unescape toggle, and an output box that fills in as you type:

• Choose a mode: Escape turns raw text into its safely-encoded form; Unescape reverses an already-escaped string back into plain text. The toggle sits above the input so you always know which direction you're working in.
• Paste or type your text into the input field. Nothing needs to be selected or triggered manually — the output box below updates on every keystroke thanks to the tool's live-preview behavior.
• In Escape mode, backslashes, double quotes, single quotes, newlines, carriage returns, tabs, and null characters are each converted to their standard backslash-escaped form — the same representation used inside JSON string literals and JavaScript string source.
• In Unescape mode, the same set of backslash sequences is converted back — \n becomes an actual newline, \" becomes a literal quote, and so on — restoring the string to its original, unescaped form.
• Copy the result with the single button next to the output box once it looks right. There's no size limit worth worrying about for normal text, log lines, or short code snippets.

Behind the scenes, this same escape/unescape logic is also reachable as an API endpoint, documented at /docs, where it additionally accepts a format parameter so you can specify JSON, HTML, URL, or JavaScript-style escaping explicitly rather than relying on the browser tool's default backslash handling — useful if you're wiring string sanitization into a script or a build pipeline instead of pasting text by hand.

Why You'd Need to Escape or Unescape a String

This sounds like a narrow, technical need until you actually hit it — and then it comes up constantly:

• Building a JSON payload by hand. If you're constructing an API request body manually and your string value contains a quote mark or a line break, an unescaped character will break the JSON parser. Escaping it first avoids a cryptic "unexpected token" error later.
• Debugging a log line full of literal backslash-n sequences. When a log viewer shows \n as text instead of an actual line break, unescaping the string reveals the real, multi-line content the way it was originally written.
• Embedding user-submitted text into HTML. Angle brackets and ampersands in HTML have special meaning, and forgetting to escape them is a classic way markup breaks or, worse, becomes an injection point. Understanding the HTML-specific escaping rules (covered below) matters here even though the browser tool's default mode handles the JSON/JS backslash case.
• Passing a value inside a URL query string. Spaces, ampersands, and question marks all carry meaning in a URL, so a raw string with any of those characters needs percent-encoding before it can be safely appended to a link.
• Pasting a JavaScript string literal from one file into another. Copying a string that already contains escaped quotes or newlines into new source code often needs a round trip through escape or unescape to come out correctly formatted on the other side.
• Preparing test fixtures or sample data. QA and test-writing regularly involves converting between "this is what the string looks like" and "this is what it looks like written as a JSON literal," and doing that conversion by hand is slow and error-prone.

Technical Deep Dive: Escaping Across Different Formats

Every format that treats certain characters as structurally meaningful needs its own escaping rules, and they don't overlap as much as people expect:

JSON and JavaScript string escaping use a backslash followed by a letter or character to represent something that can't appear literally inside a quoted string: \n for newline, \t for tab, \r for carriage return, \\ for a literal backslash, \" for a double quote, and \0 for a null character. This is exactly the representation the browser tool's Escape mode produces and its Unescape mode reverses.

HTML escaping works completely differently — instead of backslashes, it uses named or numeric character references. The ampersand becomes &, the less-than sign becomes <, greater-than becomes >, and quote characters become " or '. Skipping this step when inserting user-supplied text into a page is one of the most common sources of broken layouts and injection vulnerabilities on the web.

URL escaping (percent-encoding) replaces any character outside a small safe set with a percent sign followed by two hexadecimal digits representing its byte value — a space becomes %20, an ampersand becomes %26. This is required for query parameters and path segments so that structural characters like & and ? aren't misread as part of the URL's own syntax.

Here's an honest comparison of how the same handful of characters get treated differently depending on context:

Format	Escape style	Example (a quote character)	Typical use
JSON / JavaScript	Backslash sequences	\"	String literals in code and API payloads
HTML	Named/numeric entities	"	Safely rendering text inside markup
URL	Percent-encoding	%22	Query strings and path segments

The practical takeaway: there is no single universal "escape" — the correct transformation always depends on where the string is headed next. A value that's safely escaped for JSON is not automatically safe to drop into HTML, and a URL-encoded value isn't valid JavaScript source. Knowing which context you're targeting matters more than memorizing any single rule.

String Escape/Unescape Tool vs Doing It by Hand or in Code

There are a few realistic alternatives to a dedicated tool, each with its own tradeoffs:

• Manually typing backslashes. Workable for a single short string, but slow and genuinely error-prone once a string has more than one or two special characters — it's easy to miss a quote or double up a backslash by mistake.
• Writing a one-off script. A quick Python or Node snippet using JSON.stringify or a language's built-in escape function works fine if you already have an environment open, but it's overkill for a single string you just need converted right now.
• Your code editor's find-and-replace. This can approximate escaping for very simple cases, but it doesn't handle the full character set correctly and can silently produce broken output on edge cases like embedded null characters.
• An online regex tester. Useful if you already know the exact pattern you need to match and replace, but building and debugging that pattern from scratch takes longer than a purpose-built escape tool for anything beyond a single character type.
• A dedicated browser-based escape/unescape tool. Instant, handles the full character set correctly in both directions, and needs nothing installed — the clear choice for a quick, one-off conversion, though a script is still the better fit if you're processing thousands of strings in a batch job.

None of these alternatives are wrong, exactly — they're just better suited to different situations. A script makes sense once escaping becomes a repeated, automated step in a larger pipeline rather than a one-time fix. Manual editing is fine for a single short value you're only touching once. The dedicated tool earns its place in the middle: faster than writing code for a single string, more reliable than doing it by eye, and available the moment you need it without switching to a terminal or an editor.

How Your Text Is Handled

All escaping and unescaping happens locally in your browser the moment you type — the tool never transmits your input to a server for processing, and nothing you paste is retained after you navigate away. That matters if the strings you're working with come from real application data, log files, or anything else you'd rather not route through a third party just to reformat a few characters.

Common Questions About String Escape and Unescape

Why does my JSON break even though the string looks fine when I read it?

An unescaped quote or newline inside a string value is invalid JSON, even though it might look perfectly normal to a human reader. The parser sees the raw quote as the end of the string, not as a character within it, and the rest of the document fails to parse from that point forward.

What's the difference between escaping and encoding?

They're closely related but not identical: escaping typically inserts a marker (a backslash, an entity, a percent sign) in front of or around a special character so a parser reads it literally, while encoding often transforms an entire string into a different representation, such as Base64. Both aim to make data safe for a specific context, just through different mechanisms.

Can I use JSON escaping rules inside a URL?

No. A backslash-escaped quote is meaningless to a URL parser, which only understands percent-encoding. Mixing escaping styles across formats is a common source of subtle bugs, especially when a string passes through multiple layers — say, JSON inside a URL parameter — and needs a different escaping pass at each layer.

Does unescaping always perfectly reverse an escape operation?

For a matched pair of operations on the same format, yes — escaping and then unescaping a string returns the original text. Problems arise when a string gets double-escaped (escaped twice) or escaped in one format and unescaped as if it were another; both produce garbled output rather than a clean round trip.

Why do I sometimes see a literal backslash-n in text instead of a line break?

That typically means the text was escaped for storage or transport (as it needs to be inside a JSON string) but never unescaped again before being displayed. Running it through unescape mode restores the actual newline characters so multi-line content displays the way it was originally written.

Is HTML entity escaping the same thing as sanitizing HTML for security?

Escaping the handful of characters covered here (angle brackets, ampersands, quotes) is a core part of preventing injection issues, but full HTML sanitization for untrusted input typically involves additional rules around attributes and allowed tags. Treat character escaping as a necessary layer, not a complete security solution on its own.

Related Tools

If JSON structure itself — not just string escaping within it — is what you're troubleshooting, JSON Formatter catches syntax errors and lays the document out for readability. For the HTML-specific entity rules mentioned above, HTML Entity Encoder handles the named and numeric character references directly rather than backslash sequences. When a value needs percent-encoding instead, URL Encode/Decode covers query strings and path segments specifically. For locating and swapping specific escaped or unescaped sequences across a larger block of text, Find and Replace is a faster route than manual editing, and Text Diff Checker is useful for confirming that an escape/unescape round trip actually reproduced the original string exactly.