Consider this English source:

{"choices":["Yes","No"]}

And this Japanese target:

{"choices":["いいえ","はい"]}

The target means “No, Yes.” Both arrays contain two strings. A structural comparison that pairs elements by index has nothing structural to flag. If the application expects the first item to represent an affirmative choice, the translation now describes the opposite action.

That is a useful test case for any localization review process: include a known bad translation that your structural checker is expected to miss.

Decide what identifies a string

JSON objects and arrays give a checker different ways to match content. An object uses member names; an array uses positions. RFC 8259 describes objects as unordered collections and arrays as ordered sequences. A formatter's choice of indentation is separate from either relationship.

These objects should therefore be compared by play and exit, even though their order differs:

{"menu":{"play":"Play","exit":"Exit"}}

{
  "menu": {
    "exit": "終了",
    "play": "開始"
  }
}

A text diff shows many changed lines. A key-based localization check can concentrate on the two corresponding strings.

Arrays need extra care. Remove the middle item from a three-step list:

{"steps":["Open","Save","Close"]}

{"steps":["開く","閉じる"]}

An index-based comparison pairs Save with 閉じる (“Close”) at index 1 and reports a missing index 2. It can flag the length difference and missing position. It cannot infer that the translator removed the middle step, then realign the remaining elements by meaning.

If your application's format allows stable identifiers, names such as save and close can make those relationships easier to inspect. Changing an established file schema also requires changing its consumer; renaming the keys in a translation file alone is not a migration.

Eight small tests against a released checker

The following results came from Taiyaku JSON Check 1.1.1, a tool published by TAIYAKU WORKS. They describe this implementation, rather than every JSON comparison tool.

For this check, the engine embedded in each distributed HTML file was run with Node.js 24.19.0. The HTML hashes matched the release manifest. Both the free and full editions produced the same results for all eight pairs. Each input went through the product's parser before comparison.

Unchanged-string notices were disabled except in the dedicated unchanged case. The placeholder case used Simple placeholders mode. These are small synthetic checks, not a translation-quality benchmark or application runtime tests.

The paths identify locations in the file. The severity describes the checker's review priority. Neither is a verdict on the quality of the translation.

An extra target key can be intentional. A proper name can correctly remain unchanged. A boolean change may be significant to the application even though this checker labels it a warning. Decide which findings block a release using the requirements of the application that consumes the files.

Inspect the input before comparing it

A duplicate key creates an earlier problem:

{"label":"A","label":"B"}

The tested parser rejected this input with Duplicate object key: /label. That is an explicit parser policy. RFC 8259 recommends unique member names and explains that implementations differ when names repeat. If parsing silently discards one occurrence, a later comparison cannot inspect the value that was lost.

For a localization pipeline, record parse failures separately from comparison findings. “Could not compare this file” must not become “zero issues.”

Keep the structural and language reviews connected

A useful handoff has two parts:

1. A structural review queue: missing keys, type changes, changed non-text values, array differences, and supported placeholder checks.

2. A contextual review: what each string means, which action it represents, how variables are supplied, and how it appears in the application.

For arrays, include one case where an item is removed and one where equal-length items are reversed. For strings, include an opposite-meaning translation with the same key and type. These cases expose the boundary of the checker before a clean result acquires more authority than it deserves.

You can reproduce the pairs above in the free browser trial. Save each source and target as separate UTF-8 JSON files, load one pair at a time, and use the settings described above. The trial allows one pair and up to 100 strings, without report export. Use these synthetic examples or anonymized files; the hosting page is online. An offline edition is linked from the trial page.

A clean result means the enabled rules found no issue in their supported scope. Keep the reversed-choice example beside that result when deciding what to check next.