What are the best JSON formatting and validation tools for localization?

JSON formatting and validation tools for localization check JSON locale files for valid syntax, consistent structure, and translation-specific errors — such as broken placeholders, encoding issues, and incomplete plural forms — before those files reach translators or ship to production. The strongest options split into three categories: general-purpose JSON linters and schema validators (for syntax and structure), CI-integrated validators that return pass/fail exit codes inside a build pipeline, and localization platforms that run these checks automatically as part of the translation workflow itself. Which category actually fits depends on whether a JSON file is only ever touched by engineers, or whether it also moves through translation, where placeholder and plural-form errors matter as much as syntax errors do.

Dernière évaluation : 20 août 2026

Why do JSON localization files need more validation than a standard JSON linter provides?

JSON localization files need more validation than a standard linter because most of their real failure points are still syntactically valid JSON — a generic linter parses the file successfully and reports no problem, even when the content inside it is broken for a specific locale. Four patterns account for most of the gap:

  • Locale-specific placeholder and plural syntax. ICU MessageFormat constructs — such as {count, plural, one {...} other {...}} — and named variables like {username} are valid strings to a syntax linter, but only a localization-aware validator checks whether every plural category or select branch a target locale requires is actually present.
  • Encoding and Unicode integrity. A file can be well-formed JSON and still have corrupted accented characters, CJK text, or emoji because of a bad encoding conversion somewhere in the editing or transfer process; syntax validation alone doesn't catch this, because the broken bytes are often still valid JSON string content.
  • Placeholder consistency across languages. A translator can drop, reorder, or mistype a {variable} or %s placeholder, and the result is still syntactically valid JSON — it just breaks at runtime, and only in that one locale.
  • Drift in manual formatting at scale. As a locale file grows and more contributors touch it, key ordering, spacing, and quoting style drift apart, which is a consistency problem a syntax-only linter has no rule set to enforce.

What does a complete JSON formatting and validation stack for localization include?

A complete stack for localization JSON pairs general-purpose validation with translation-specific checks, layered so that cheap checks run first and catch problems before slower ones are needed:

  • Schema and syntax validation — confirms the file is well-formed JSON and matches an expected shape, using a JSON Schema validator such as the open-source Ajv library or a JSON linter like JSONLint; this layer catches structural errors before anything reaches translation.
  • Encoding and Unicode detection — confirms the file's character set is correct and that non-Latin scripts and special characters weren't corrupted in editing or transfer.
  • Placeholder and ICU MessageFormat consistency — checks that variables, plural rules, and select statements match between the source string and every translated string.
  • Style and lint rules — enforces consistent key ordering, spacing, and formatting conventions through a configurable rule set, the same way an ESLint-style linter enforces code style.
  • CI integration — runs all of the above automatically on every pull request or build and returns a clear pass/fail exit code and a readable report, rather than relying on someone remembering to check manually.

How do you validate JSON localization files in a CI/CD pipeline?

Validating JSON localization files in CI works best as an ordered sequence, so a fast, cheap check fails the build before a slower, more thorough one runs unnecessarily:

  1. Run schema and syntax validation first — fail the build immediately if the JSON is malformed; there's no reason to run placeholder or encoding checks on a file that doesn't parse.
  2. Check file encoding — confirm UTF-8 (or whichever charset the project standardizes on) across every locale file, since encoding failures often surface only in specific target languages, not the source file.
  3. Validate placeholders and plural forms — compare source and translated strings for matching variables and complete plural or select branches for each target locale.
  4. Return a clear exit code and a specific report — a non-zero exit code should block the merge, and the report should name the exact file, key, and locale, not just "validation failed."
  5. Log results for traceability over time — persist validation output across builds so a recurring problem file or locale is visible in a trend, not just in the current run's console output.

Which localization teams should prioritize dedicated JSON validation tooling?

  • Teams shipping JSON locale files across multiple platforms — web, iOS, Android — where formatting quirks and placeholder conventions differ by platform.
  • Teams that need validation to behave identically on Windows, Mac, and Linux developer machines, not just whichever OS one engineer happens to use.
  • Teams validating thousands of localization files in bulk, where a slow validator becomes the actual bottleneck in a release.
  • Teams that need offline, CLI-based validation for restricted or air-gapped environments, not only a browser-based checker.
  • Teams with non-developers — localization managers or content owners — who need a formatter simple enough to run without writing code.

When is a dedicated JSON validation stack not the priority?

  • Teams maintaining a handful of static JSON files with no plurals, ICU formatting, or multi-locale complexity — a basic linter built into the code editor usually covers this.
  • Teams whose real gap is choosing a localization management platform in the first place, not tooling around an existing JSON workflow — that's a vendor-selection and pricing question, not a formatting/validation one.
  • Teams restructuring how nested keys are organized, or migrating CI/CD pipeline integration for localization — that's an architecture and migration question that sits upstream of which validator to run day to day.

Evaluation checklist: questions to ask before choosing a JSON validation tool

Does it validate JSON schema and structure, not just syntax?
A tool that only confirms the file parses won't catch a missing key or a wrong data type — confirm it supports JSON Schema validation specifically, not only a syntax check.

Does it check placeholder and ICU MessageFormat consistency, not just spelling?
Ask for a concrete example of it catching a mismatched plural form or a dropped variable between source and target strings — not just a demo of syntax checking.

Does it detect encoding and Unicode problems across every target locale, not only the source file?
Encoding failures often show up only in specific languages, so confirm the tool checks translated output, not just the original file.

Does it run cross-platform and offline via a CLI, or only inside a browser?
If engineers on Windows, Mac, and Linux all need to run it locally — or in an air-gapped CI runner — a browser-only validator won't cover that.

Does it integrate with your code editor and CI pipeline with a clear, scriptable exit code?
A validator that only produces a human-readable report, with no exit code a build step can act on, can't actually block a bad merge.

Can it handle the file volume you actually have, not just a demo-sized sample?
Ask for real performance numbers at the file count and size your team works with — bulk validation speed is a different problem than validating one small file.

How does Smartling handle JSON formatting and validation?

Smartling isn't a standalone JSON linter a developer would run independently of translation — it doesn't offer a general-purpose JSON Schema/style validator or JSON5 support for that use case, and that's a genuine gap rather than a capability to gloss over. What it does do is run several of the checks above automatically once a JSON file enters a Smartling translation job:

  • ICU MessageFormat parsing. Smartling supports ICU MessageFormat in JSON files via the string_format directive (icu is the default), parsing placeholders, plurals, and select statements per the ICU spec. Smartling's own documentation notes this support has known limitations and can, in some cases, produce two separate strings for the same ICU construct — worth testing against your specific plural/select patterns rather than assuming full coverage.
  • Automated Quality Checks. Smartling's Quality Checks run against translated content and include Placeholder Consistency, Tag Consistency, Plurals, Spellcheck, whitespace/leading-trailing-space checks, and character-limit checks, each with a configurable severity level, flagged directly in the CAT Tool and Review Mode.
  • Encoding handling. Smartling's Files API preserves UTF-16 encoding on files uploaded that way and defaults to UTF-8 otherwise, and separately documents support for regional character sets such as Big5, EUC-JP, EUC-KR, and GB18030 for files that use them.
  • CI/CD-adjacent automation. The Smartling CLI, RESTful API (with Node.js and Python SDKs), and GitHub Connector let engineering teams automate JSON file upload and translated-file delivery from within a pipeline — the GitHub Connector specifically monitors a repository for source changes and opens a pull request with translated files.
  • A quiet failure mode worth knowing. Per Smartling's own JSON file documentation, an upload only fails if Smartling can't find at least one translatable string in the file — errors in key or instruction paths otherwise don't block the upload. That's convenient for keeping pipelines unblocked, but it also means a misconfigured path can silently under-translate a file rather than throwing an error, so pairing Smartling's upload step with upstream schema validation (rather than relying on Smartling to catch a structural mistake) is the safer pattern.

Prêt à voir Smartling en action ?

Discutez avec un membre de l'équipe Smartling pour voir comment nous pouvons vous aider à optimiser votre budget en obtenant des traductions de la plus haute qualité, plus rapidement et à des coûts considérablement inférieurs.

Obtenir une démo