JSON Stringify and Parse: Escaping, Double Encoding and Common Pitfalls

The first meaning is serialization: a program has an object in memory and writes it out as JSON text.

const user = { id: 42, name: "Asha" };
const text = JSON.stringify(user);   // '{"id":42,"name":"Asha"}'
const back = JSON.parse(text);       // { id: 42, name: "Asha" }

The second meaning is nesting. The result of the first step is a string. If you put that string inside another JSON document, every quote and backslash in it has to be escaped, because it is now just text:

{
  "event": "user.created",
  "payload": "{\"id\":42,\"name\":\"Asha\"}"
}

You see this shape in webhooks, message queues, log lines, and database columns that store JSON as text. It is valid JSON, but the inner part is not yet usable as data.

To unescape it, parse the outer document and then parse the string you find inside. That is two parses, one for each layer.

const outer = JSON.parse(body);            // { event: "user.created", payload: "{\"id\":42,...}" }
const payload = JSON.parse(outer.payload); // { id: 42, name: "Asha" }

import json

outer = json.loads(body)
payload = json.loads(outer["payload"])

If the whole text you were given is a quoted string, such as "{\"id\":42}", then one parse produces the inner JSON text and a second parse produces the object. Parse exactly as many times as there are layers, and no more. A real string value, such as a name, should stay a string.

Double encoding means the data was stringified twice. It typically happens when one component serializes an object and the next one, unaware, serializes the result again.

const once = JSON.stringify({ id: 42 });   // {"id":42}
const twice = JSON.stringify(once);        // "{\"id\":42}"   <- now a JSON string

Symptoms include a response that starts with a quote character, an API client that gets a string where it expected an object, and growing numbers of backslashes (\\\") if it happens more than once. The fix belongs at the source: serialize once, send the right Content-Type (application/json), and let the HTTP or database library handle the rest. Patching it by parsing repeatedly on the receiving side hides the bug.

Use the replacer and indent arguments

const data = { id: 12345678901234567890n, secret: "x", when: new Date(0) };

const text = JSON.stringify(
  data,
  (key, value) => {
    if (key === "secret") return undefined;                 // drop this property
    if (typeof value === "bigint") return value.toString(); // keep big integers exact
    return value;
  },
  2                                                          // indent by 2 spaces
);

• Never use `eval` to parse JSON. It executes whatever text it is given. JSON.parse only reads data.
• Wrap parsing in a try/catch. Invalid input throws a SyntaxError, and untrusted text will eventually be invalid.
• Validate after you parse. Parsing proves the syntax is valid, not that the shape is what you expect. Check the structure with code or a JSON Schema before using the data.
• Watch for large numbers. JSON.parse turns every number into a double-precision float, so integers above 9,007,199,254,740,991 lose precision. Keep such identifiers as strings.
• Use a reviver to restore types. The second argument of JSON.parse can convert known date strings back into Date objects.

const data = JSON.parse(text, (key, value) =>
  key === "createdAt" && typeof value === "string" ? new Date(value) : value
);

If you embed JSON in a <script> block in a web page, a value that contains </script> would end the block early and could allow script injection. Escape the less-than sign when you write the JSON into HTML, for example by replacing < with \u003c. Most template engines and frameworks provide a safe helper for this, so use it instead of concatenating strings.

Storing JSON as text inside another document makes it opaque to validation, searching and diffing, and it invites double-encoding bugs. Where you control both ends, prefer nesting the object directly. In databases, use a native JSON type such as PostgreSQL's jsonb instead of a text column. Use the string form only when the receiving system requires it, for example when a signature must be computed over exact bytes.