JSONエスケープ解除
JSON Unescape reverses string escaping: it turns \" back into a quote, \n back into a newline and \uXXXX back into its character, recovering the document that was embedded inside another one. It is deliberately tolerant of fragments copied out of log lines, which usually arrive missing their outer quotes.
このツールの画面は英語表記です。
以下の解説は英語のみでご覧いただけます。
How does JSON Unescape work?
You almost always arrive at this tool from a log file. Something logged a request body by putting the whole JSON document into a single string field, and what you are looking at is a dense line of \" where the quotes should be, with \n instead of line breaks and \\ wherever a Windows path appeared. It is technically readable and practically not.
Unescaping is the inverse of escaping, and mechanically simple: scan the text, and each time a backslash appears, consume the character after it and emit what the pair stands for. The judgement is entirely in how to handle the input being imperfect, which it nearly always is.
A strict JSON parser would reject most of what people paste here. The fragment has usually lost its surrounding quotes to a copy-paste that selected the interesting part. It may be truncated by a log field’s length limit. It may contain a backslash that is not a valid JSON escape at all, because the thing that produced it was escaping for a different target. A parser that refuses all of these is correct and useless.
So this is tolerant on purpose. Missing outer quotes are fine and reported rather than required. An unknown escape such as \q keeps both characters and raises a warning. A trailing backslash is kept. An incomplete \u sequence is left as written. In every case the rest of the document is still recovered, because a partially recovered payload is far more use than an error message.
Unicode gets proper treatment. A \uXXXX escape becomes its character, and a high surrogate followed by a low surrogate is recombined into the single character they jointly encode — without that step every emoji and every rarer CJK glyph comes out as two replacement boxes.
Once unescaped, the result is checked: if it is valid JSON it is pretty-printed, which is nearly always what you actually wanted. If it is not, it is shown as plain text with the parse error, so you can see whether the document was truncated in the log or was broken before it got there.
Escaped string
"{\"name\":\"Ada\",\"note\":\"line one\nline two\"}"Recovered document
{
"name": "Ada",
"note": "line one
line two"
}What options and edge cases does JSON Unescape support?
| Parameter | Type | Default | Behaviour & edge cases |
|---|---|---|---|
| \" \\ \/ | escape | — | Quote, backslash and forward slash. The slash escape is legal but optional in JSON, so it appears in some producers' output and not others. |
| \n \r \t \b \f | escape | — | The named control characters. \n is the one that makes the difference between a wall of text and a readable document. |
| \uXXXX | escape | — | A UTF-16 code unit. A high surrogate followed by a low one is recombined into the single character it encodes; without that, every emoji and many CJK characters come back as two broken boxes. |
| Surrounding quotes | optional | stripped if present | A fragment pasted out of a log line has usually lost them. Whether they were there is reported rather than required. |
| Unknown escape | kept + warning | — | \q and similar keep both characters. A strict parser rejects the whole document; keeping going recovers the rest, which is what you came for. |
| Lone surrogate | kept + warning | — | A high surrogate with no low half cannot form a character. It is preserved and flagged, since it usually means the source was truncated mid-character. |
| Pretty-print | boolean | true | Re-indents when the recovered text is valid JSON. When it is not, the raw text is shown with the parse error, which distinguishes a truncated log field from a document that was already broken. |
Frequently asked questions
My log line is double-escaped. Do I run this twice?
Yes. Double-escaping happens when an already-escaped string is escaped again — a payload logged as a string, then that log line logged as a string by an aggregator. You will see \\\" where \" should be. Run the output back through the tool and the second layer comes off. If it looks the same after a pass, you have reached the bottom.
Why is the result still not valid JSON?
Usually truncation. Log fields have length limits, so the document is often cut mid-string or mid-object, and unescaping it faithfully produces something that cannot parse because it genuinely is incomplete. The parse error names the line and column where it stops, which normally lands exactly at the truncation point.
What happened to my emoji?
If they survived, the surrogate pair was recombined correctly. If a tool shows two boxes instead, it decoded each \uXXXX half independently — characters outside the Basic Multilingual Plane are encoded as two code units and must be joined. This tool joins them, and warns when it finds a lone half, which indicates truncation.
Can I paste text that is not JSON?
Yes. The unescaping is textual, so an escaped SQL statement, an escaped HTML fragment or an escaped shell command unescapes fine. It will simply report that the result is not valid JSON and show it as plain text rather than pretty-printing it.
Is the log line I paste sent anywhere?
No. Unescaping runs in your browser. This matters more here than for most tools: the log lines people unescape are frequently production request bodies containing tokens, session identifiers and customer records, and pasting one into a server-side tool copies it into a second access log.
Does unescaping change the characters, or only how they are written?
Only how they are written. \u00e9 and é are two spellings of one character, and unescaping rewrites the spelling — what comes out is exactly the text the escaped form encoded. That is also why the output sometimes looks identical to the input: a log line with nothing escaped in it has nothing to change.