JSON Escape and Unescape
Turn JSON into an escaped string literal you can paste into source code, or decode an escaped blob from a log or database column back into readable JSON.
Hard-coding a JSON payload in source code is mostly a quoting problem. JSON wraps keys and strings in double quotes, and inside a Java or C# string literal every one of those has to be escaped; doing it by hand guarantees missed ones. This tool escapes the entire text into a single line — " becomes \", \ becomes \\, a newline becomes \n — so the result compiles when pasted into a literal.
The reverse direction is just as common. An escaped blob pulled from a log line, a database column or a message queue is unreadable until it is decoded back into something with line breaks. Both directions live on this page, and all of the work happens in the browser: payloads containing internal API structures or credential fields are never uploaded or forwarded.
Which characters escaping touches
Escaping follows JavaScript string literal rules. These characters are rewritten: a double quote becomes \", a backslash becomes \\, a newline becomes \n, a carriage return becomes \r, a tab becomes \t, and backspace and form feed become \b and \f. Everything else passes through unchanged. The whole result is wrapped in a single pair of double quotes, which means the output is a string literal and no longer a JSON document. Java, C#, JavaScript and Python double-quoted strings all accept this escape set, so the result can be pasted directly; in Python you may prefer a triple-quoted or raw string instead, adjusting by hand.
How unescaping restores the text
Unescaping accepts two kinds of input: a complete literal with its surrounding quotes, and a bare fragment without them. When quotes are present it first tries to parse the text as a JSON string, which is the most accurate path because it applies the actual grammar; when that does not apply it walks the escape table character by character, decoding \uXXXX into the code unit it names. The scan is single-pass and left to right, so a sequence such as \\n is correctly restored to "backslash followed by the letter n" rather than being interpreted a second time as a newline. That double-interpretation bug is a common failure in simple online escape tools.
Common mistakes and the right order of operations
The most frequent error is escaping text that has already been escaped, which stacks backslashes until values look like \\\" and become nearly impossible to read. The way to check is to look at the start and end of the result: correct output has exactly one pair of outer double quotes. A related confusion: if the text already contains a sequence such as \u00e9, escaping turns it into \\u00e9 — the backslash is preserved as a literal character and nothing is decoded. To actually turn escape sequences into characters, use the Unicode converter, not this tool. A sensible order is to repair and format until the JSON is valid, then escape last.
Frequently asked questions
- Can escaped output still be used as JSON?
- No. The result is a single-line string literal intended for source code, not a JSON document. Inside JSON you can keep the escaped form as a string value if that is what the receiving field expects; to get structured JSON back, run it through the unescape direction so the text is restored.
- Why does it still fail to compile in Java after escaping?
- Most often the scope is wrong. The tool escaped the entire editor content, but if only part of a literal was replaced by hand, the remaining double quotes still break the string. Also remember that Java limits a single string literal to 65535 bytes of modified UTF-8 in the constant pool, so very long payloads belong in a text block, a resource file, or several concatenated strings.
- Can I escape and unescape back and forth repeatedly?
- A single round trip is reliable: escape and then unescape returns exactly the original text. What you should not do is press escape a second time on already-escaped text — that produces multiple levels of escaping with doubling backslashes, which is hard to undo by eye. If it happens, run unescape the same number of times and the text returns to its original state.
- What happens to non-ASCII characters when escaping?
- They are left as literal characters unless they are one of the control characters listed above. Java, C# and JavaScript source files are normally UTF-8, so a literal accented letter or emoji is valid there. Only if the target pipeline demands pure ASCII should you follow up with the Unicode escape tool, which converts every character above U+007F.