8 min read · Try JSON Formatter
Why invalid JSON still reaches production
JSON looks simple until a trailing comma, an unquoted key, or a single-quoted string slips into a hand-edited config file. Many pipelines only discover the problem when a service fails to start or an API client throws a parse error at 2 a.m.
The fix is not “be more careful”—it is to validate at the same boundaries where you already lint code: editor save, pre-commit, and CI.
Validate at three checkpoints
First, use your editor’s JSON language mode or schema association so mistakes appear while you type. Second, run a formatter or validator in pre-commit for files that humans edit (feature flags, static site config, OpenAPI snippets). Third, add a CI step that parses every committed JSON file and fails the build on the first error with a file path and line number.
- Treat minified JSON in repos the same as pretty JSON—parsing is the gate, not aesthetics.
- When merging branches, re-validate files both sides touched; conflict markers inside JSON are a common post-merge failure.
Pretty vs minified in version control
Teams disagree on whether to commit pretty or minified JSON. Pretty diffs are easier to review; minified files are smaller. Pick one convention per repository and document it in CONTRIBUTING.md. Switching conventions mid-project creates noisy history without improving safety.
Using a browser formatter responsibly
Online formatters are excellent for one-off debugging of API responses. Paste redacted samples—replace tokens, emails, and internal hostnames with placeholders before sharing a URL that encodes the payload in query parameters.
// Example: synthetic fixture instead of production payload
{
"userId": "user_***",
"plan": "pro",
"features": ["audit_log", "sso"]
}This article is part of the DevToolsHub learning guides—original writing meant to complement our free tools, not replace official documentation from vendors or standards bodies.