JSON escape vs unescape

Why escaped JSON is hard to read

Logs, queues, databases, and API wrappers often store a JSON object as a string. Quotes become backslash-quote sequences, newlines become \n, and the value is visually noisy even when the outer JSON is valid.

Example

"{\"status\":\"ok\",\"count\":2}"

{"status":"ok","count":2} can be decoded from the string layer, then formatted as normal JSON.

How to handle escaped JSON

1. First check whether the whole value is a valid JSON string, including the outer quotes.
2. Let a JSON parser decode that string layer instead of deleting backslashes by hand.
3. Format or validate the decoded inner value if it is itself JSON.
4. Repeat carefully only when the data has more than one intentional encoding layer.

A practical debugging rule

If the value starts and ends with quotes and contains many backslash-quote sequences, you are probably looking at JSON stored as a string. Decode the string layer first, then inspect the inner value.

If the value starts with an object brace but contains escaped quotes only inside specific fields, the whole object may already be valid JSON. In that case, format the object first and inspect the field that contains the escaped text.

Common mistakes

• Removing every backslash manually and accidentally changing the data
• Trying to format the escaped string as if it were already an object
• Forgetting that \n represents a newline inside a string
• Unescaping twice when only one layer was encoded

Related problems