Find duplicate JSON keys before a parser drops them

This JSON looks small enough to check by eye:

{
  "theme": "light",
  "theme": "dark"
}

But which theme should an application use? A formatter that parses the object and prints it again may leave you with only one value, hiding the conflict before you notice it.

Valid syntax does not settle a duplicate

The JSON standard says names within an object should be unique. Duplicate names can fit the grammar, but receivers do not all handle them alike: some keep the last value, some reject the object, and others expose both.

JavaScript keeps the last one in this example:

JSON.parse('{"theme":"light","theme":"dark"}').theme
// "dark"

That is the parser's behaviour, not evidence that the second value is correct. For configuration files, the first value could be the one you meant to keep.

Find both definitions before editing

Download the duplicate-key sample and open it in CozyToolkit's JSON formatter.

1. Use Open JSON, or paste the example into Your JSON.
2. Look for the highlighted field and the issue list below the editors. This sample flags the second key at line 3, column 3.
3. Select the issue to jump to it. Show first definition takes you to line 2, column 3.
4. Compare the values with the source of truth: your configuration, API schema or original export. Keep a copy before changing anything; Copy raw preserves the input as entered.
5. Remove the unintended property. Once the issues are resolved, review the output and use Copy formatted or Download.

The formatter deliberately blocks formatted output while duplicate keys remain. Sorting keys or changing indentation cannot resolve the ambiguity.

For this example, suppose dark mode is the intended setting. The corrected file contains only that property. We chose it explicitly; the tool did not decide for us.

The same name in separate objects is fine

These two properties belong to different objects:

{
  "editor": { "theme": "light" },
  "preview": { "theme": "dark" }
}

There is no duplicate within either object. A text search for the word “theme” finds two matches, but that is not enough to diagnose a duplicate key. Try the separate-objects file in the formatter: it should have no issues.

If you really need several values, an array may be appropriate—but only if the application receiving the JSON expects an array. Renaming a key or changing a value's type just to clear an error can break that application's contract.

Escaped names can hide the same problem

This object has two spellings of the same decoded key:

{"theme":"light","\u0074heme":"dark"}

The escape represents the letter t. After decoding, both names are theme. Our inspector flags this too. Download the escaped-key sample if you want to check it.

For a large export, use a parser-aware checker rather than searching for repeated words. Our tool supports files up to 5 MB, with limits of 200,000 values and 100 nesting levels. If it reaches the 100-issue display limit, fix the reported issues and let it check again. For files beyond those limits, use a local streaming validator that explicitly detects duplicates before discarding them.

What a clean result tells you

No duplicate-key errors means this particular ambiguity has gone. It does not prove that a price, permission, URL or configuration value is correct. Check those against the schema and the application that will use the file.

On 1 October 2026, we ran all four downloadable samples through the same inspector as the tool. We checked the line and column positions, verified that duplicates block formatting, and confirmed that the corrected and separate-object samples pass. The test results include those checks and the JavaScript parse result. Inspection happens in your browser; no AI model chooses which values to keep.