Validating JSON Before a Deploy

Validating JSON Before a Deploy: package.json, Configs, and More

A single misplaced comma can take down a deploy. Configuration files such as package.json, tsconfig.json, and countless CI pipeline definitions are strict JSON under the hood, and a build tool that expects strict JSON will refuse to start the moment one character breaks the grammar.¹ Catching that error on your own machine costs seconds; catching it after a deploy already started costs a rollback.

What actually breaks a config file

Configuration files fail validation for a small, predictable set of reasons, and nearly all of them are hand-editing slips rather than logic errors. A trailing comma left after removing the last property, a missing comma between two properties, an unquoted key copied from JavaScript source, or single quotes where the grammar requires double quotes account for the overwhelming majority of broken config files.

Every one of those mistakes is legal in a JavaScript object literal,² which is exactly why they slip through so easily when someone edits a .json file inside an editor that is set up for .js syntax highlighting. Strict JSON has no such leniency. JSON.parse, the same parser this tool runs, rejects all four without exception, and most build tools call that same parser or an equivalent under the hood.³

Where these mistakes tend to hide

Trailing commas cluster at the end of arrays and objects, right after whoever edited the file last deleted an entry without deleting its preceding comma. Unquoted keys show up most often when a snippet gets copied from a JavaScript config file into a sibling .json file, since the two formats look nearly identical until a parser disagrees.

Missing commas follow a similar pattern, usually appearing right where a new property was inserted above an existing one without adding the separator the new line needed. That gap is easy to miss during a quick review, since the two properties can look perfectly fine individually and only the boundary between them is wrong.

Reading the validator output before you commit

Pasting your config into the input runs it through the same strict parser your build tool will eventually use, so a pass here means the file's syntax will not be the reason a deploy fails. When something is wrong, the error console shows the parser's message together with a line and column, normalized from whatever raw offset or position your browser's engine reported.

That line and column feed directly into a "Jump to error" action: clicking it focuses the input and selects the exact line the parser stopped on, so you fix the one character that matters instead of re-reading the whole file top to bottom. For a 200-line CI configuration, that difference is the gap between a ten-second fix and a frustrating manual scan.

Because the validation happens entirely in your browser before anything reaches version control, you can check a file as many times as you edit it, with no round trip to a linter service and no risk of an unfinished config leaving your machine. That local loop is what turns checking into a habit instead of an extra chore.

Catching it before a pre-commit hook does

Many teams already run a JSON validation step inside a pre-commit hook or a CI linting stage, and that automated check will catch the same syntax errors this tool does. The difference is speed of feedback: a pre-commit hook fails after you have already staged the change and often after you have moved on to a different file, while checking here happens the moment you finish editing, before the mistake even reaches your commit history.

JSON5, JSONC, and why some valid-looking files still fail here

Some ecosystems accept a looser dialect than strict JSON. JSONC, used by VS Code's own settings files, permits comments;⁴ JSON5 permits comments, trailing commas, and unquoted keys.⁵ Neither dialect is what JSON.parse accepts, and this tool validates strict JSON exactly as RFC 8259 defines it, so a JSONC file with a // comment will correctly fail here even though your editor renders it without complaint.

Confirming which dialect your build step actually expects

That distinction matters most right before a deploy. Consequently, if your build pipeline specifically expects JSON5 or JSONC for a given file, a fail here is not a false positive, it is telling you the wrong parser standard for that file. Strip comments and trailing commas before validating, or confirm which parser your actual build step uses so you are testing against the right grammar rather than the strictest possible one.

When to use this

Use this guide before committing or deploying any strict-JSON config file, whenever you want to catch a syntax error locally and jump straight to the failing line instead of discovering it mid-deploy.

Examples

{"dependencies": {"react": "^18.0.0", "astro": "^5.0.0",}}

The validator flags the comma immediately after "^5.0.0", since JSON.parse treats a comma with no following member as a syntax error. Deleting that one character produces valid JSON your package manager will accept.

{ env: 'production', retries: 3 }

{"env": "production", "retries": 3}, since both keys need double quotes: unquoted keys are only valid in JavaScript object literals, not in JSON.