Why a Duplicate JSON Key Disappears After Formatting

If a JSON field disappears after formatting, compare the result with the untouched input before copying it onward. Two occurrences of the same property name inside one object can collapse into a single property during parsing. Readable output can therefore hide an ambiguity that was present in the source.

This guide uses a fictional delivery response with the JSON Formatter and Validator. Its current implementation parses JSON into JavaScript values before rebuilding the display text. It does not flag duplicate names separately.

Reproduce the missing occurrence

1. Save an unchanged copy of the original response.
2. Paste this small sample into Paste your JSON.
3. Choose 2 spaces under Indent. Leave Minify and Sort keys alphabetically unchecked.
4. Select Format JSON and compare the output with the source.

{"order_ref":"DEMO-73","delivery":"standard","delivery":"express"}

The current output is:

{
  "order_ref": "DEMO-73",
  "delivery": "express"
}

The tool reports Valid JSON. Formatted output shown below. The earlier delivery value has gone. Its Total keys statistic is calculated after parsing, so the displayed count of two does not establish how many name-value pairs appeared in the original.

Keep the failing input alongside the result when reporting this problem. The formatted copy alone no longer shows the competing values.

Understand why the later value survives here

MDN describes JSON.parse as converting JSON text into a JavaScript value. This is a structural conversion, rather than simply inserting line breaks into the original text.

For duplicate names in one object, JavaScript parsing retains the later value, as specified in the ECMAScript ParseJSON rules. Reverse the two delivery members in the sample and the resulting value becomes standard. That demonstrates parser behavior; it does not identify which delivery option the source system intended.

RFC 8259 recommends unique names within an object and describes receiver differences when they repeat. Another implementation may reject the document or expose multiple occurrences. Do not design an interchange contract around the assumption that every receiver chooses the same winner.

Check decoded names within each individual object

Repeated spelling anywhere in a document is not enough to establish a duplicate. These two city properties belong to different objects:

{"billing":{"city":"Pune"},"delivery":{"city":"Jaipur"}}

Format this control with the same settings. Both cities remain, one under billing and one under delivery. Record the containing object when investigating a larger response.

Different escape spellings can also represent the same name. Try:

{"delivery":"standard","deliv\u0065ry":"express"}

The escape \u0065 represents the letter e, so both names decode to delivery. The current formatter produces:

{
  "delivery": "express"
}

RFC 8259 discusses comparing decoded strings rather than leaving escape sequences unconverted. A search for two identical raw spellings would miss this example. Conversely, city and City are different names; do not apply a case-insensitive text cleanup to decide whether JSON members match.

Resolve the conflict at the producer

1. Return to the untouched response and identify the object containing the repeated name.
2. Record both source values, their order and the expected field definition. For the first fixture, the competing values are standard and express at the root property delivery.
3. Check the producing template, serializer or merge step that emitted the two members.
4. Have the producer emit the intended field once, following the agreed contract, then repeat the test with a fresh response.

If the contract defines one delivery string, silently converting the values into an array changes that contract. If they represent separate facts, agree on appropriate fields or structure before altering the payload. Removing one occurrence by guesswork can preserve valid syntax while selecting the wrong instruction.

Validate the original before accepting a display copy

For a large response, use a duplicate-aware check that reads the original JSON text, tracks each object separately and compares decoded member names. A check performed only on an already rebuilt object cannot recover an overwritten occurrence. The on-site formatter provides readable output, not this original-text duplicate check.

If punctuation prevents parsing, use the JSON syntax repair guide. Once the producer emits unambiguous data, follow the API example formatting workflow and verify the retained values against the source before sharing the result.