How to Escape a String for JSON, SQL, Shell, and Every Other Target

Pasting a chunk of text into code looks trivial until the text contains a quote, a backslash, or a newline. Then your JSON request returns a 400, your SQL console throws a syntax error, or your bash command splits a filename in half on a space you forgot about. The fix is always the same word — "escape the string" — but the actual rules are different for every place you paste into. There is no single escape that works everywhere, and using the wrong one either silently corrupts your data or opens a security hole.

This post walks through why each context guards a different set of special characters, how to escape a string for the target you actually have, and why the unescape direction matters just as much.

Each Target Has Its Own Special Characters

The reason there is no universal escaper is that "special" is defined by the parser reading the string, and every parser reads differently. A character that breaks a JSON literal is harmless inside an HTML attribute, and the character that breaks the HTML attribute passes straight through JSON.

Here is what each common target actually cares about:

JSON must escape the double quote ", the backslash \, and control bytes — newlines become \n, tabs become \t, and anything below 0x20 becomes the canonical \uXXXX form. Get this wrong and the parser rejects the whole body.
JavaScript covers the same ground as JSON but adds the cases template literals need: the backtick ` ` and the vertical tab. A string built for a ... template has different hazards than one built for "..."`.
HTML ignores quotes-as-string-terminators entirely and instead escapes the four entity characters: <, >, &, and ". A < you forget to escape turns the rest of your text into a phantom tag.
CSV has no backslash escape at all. Per RFC 4180, a field containing a comma, a quote, or a newline gets wrapped in double quotes, and any inner quote is doubled — She said "hi" becomes "She said ""hi""".
SQL (single-quote dialect) doubles the single quote: O'Brien becomes O''Brien. That is the entire rule for the literal itself.
Regex escapes the metacharacters that otherwise change matching behavior — ., *, +, ?, (, ), [, ], {, }, ^, $, |, and \. An unescaped . matches any character instead of a literal dot.

Notice how little overlap there is. JSON cares about \ and "; HTML does not touch \ at all and adds &. CSV doubles quotes instead of backslashing them. Apply JSON escaping to a value headed for an HTML attribute and the < sails through unescaped; apply HTML escaping to a JSON body and your \n newline never gets encoded. The string escape tool keeps nine separate rule sets so you pick the target and get that target's exact behavior, instead of a one-size-fits-all backslash pass that is wrong for most of them.

A Worked Example: A Quote and a Newline Into JSON

Say you are hand-building a curl request and need to drop this two-line message into a JSON field:

Server said "no".
Retry later.

Pasted raw between quotes, this is broken JSON twice over: the embedded " closes your string early, and the literal newline is not allowed inside a JSON string at all. Escape it for JSON and you get:

Server said \"no\".\nRetry later.

The inner double quotes became \", and the line break collapsed into \n. Now drop that between your own quotes:

{ "error": "Server said \"no\".\nRetry later." }

This parses on the first try. One detail worth knowing: JSON, JS, Java, and C escape only the contents of the string — you still add the surrounding quotes yourself, because you are usually pasting into a slot that already has them. Shell and CSV are the exceptions; for those, the wrapping quotes are part of the escaping rule, so the tool adds them for you.

Why the Wrong Escaping Breaks Things — or Worse

A mismatched escaper fails in one of two ways, and the second is the dangerous one.

The first is a clean break: the string just doesn't work. You forgot to escape a < in HTML and the page renders garbage, or you left a literal newline in a JSON body and the API rejects it. Annoying, but loud — you find out immediately.

The second is silent and unsafe. SQL single-quote escaping is the classic trap. Doubling quotes makes a literal valid, but it does not make untrusted input safe. Numeric contexts, identifiers, charset edge cases, and stored-procedure quirks all slip past naive quote-doubling, which is exactly the seam SQL injection exploits. Escaping a one-off literal for a console fix or a migration script is a fine use of the doubling rule; sanitizing user input with it is not. For anything touching user input, parameterized queries are the only correct defense — the driver sends your value as data, never as SQL text.

There is also the double-escape footgun. Run already-escaped text through an escaper again and every \ doubles: your \n becomes \\n, and the parser now hands you a literal backslash-n instead of a newline. Escape once, at the moment you build the literal. If you are unsure of a string's current state, unescape it back to plain text first, then escape cleanly.

The Unescape Direction

Escaping gets the attention, but reading an escaped string is just as common. A teammate pastes a Java stack trace into Slack, their client escapes it, and you receive one flat line full of \n and \uXXXX. Flip to unescape, pick Java, and the real multi-line trace comes back with its Unicode restored. The same applies to a JSON blob you copied out of a log viewer, or a regex someone over-escaped by hand.

Unescaping is also a sanity check before re-escaping. When you cannot tell whether a string is raw or already escaped, decoding it first removes the ambiguity. If a single glyph in a message looks suspicious after unescaping — a lookalike character, an invisible space — the Unicode character inspector tells you exactly which code point it is, which is handy when an escaped zero-width space is the reason two "identical" strings don't compare equal.

How I Use It Day to Day

I keep this tool open in a pinned tab the way other people keep a calculator. The case that earns its place most often is the curl-by-hand workflow: I am debugging an API, I need to reproduce a request with a customer's actual error message in the body, and that message is full of quotes and newlines. Before, I'd paste it in, watch the request fail, and waste a minute squinting at which character broke the JSON. Now I paste into the escaper, set JSON, and copy the clean output straight into the body. The request goes through on the first attempt, every time. The second-most-used path is the reverse — pasting an escaped log line back to plain text so I can actually read what the server was trying to tell me.

Everything runs client-side in the browser tab, which matters because the input is often a stack trace or a customer record. Nothing is uploaded, nothing is logged. The one caveat is the shareable URL: it encodes your input so a teammate opens the same view, but that means a "share link" lands in the destination's access log. For a public snippet that's fine; for anything sensitive, copy the output manually instead of sharing the link.

Escaping is a small thing that breaks builds, corrupts data, and opens injections when it goes wrong. Picking the right target for the right context is the whole game.

Made by Toolora · Updated 2026-06-13