Validate JSON Files for CI/CD Pipeline Integration

A fromJSON() matrix built by hand picks up a trailing comma after the last entry. The workflow doesn't fail at lint time — it fails when the matrix job tries to expand, with a cryptic 'unexpected end of JSON' in the runner. Validating the raw matrix string locally pins it instantly.

Input (matrix.json, pasted to a file):
{
  "include": [
    { "node": 18 },
    { "node": 20 },
  ]
}

Validator output:
Invalid JSON
Expected double-quoted property name in JSON at position 51 (line 5 column 5)

Fix: delete the comma after { "node": 20 }

tsconfig.json is JSON-with-Comments. TypeScript reads it fine, but a CI step that runs plain JSON.parse/jq on it fails. This validator behaves like that CI step — it rejects the comments — which tells you the script is using the wrong parser, not that your tsconfig is broken.

Input (tsconfig.json):
{
  // base options
  "compilerOptions": { "strict": true }
}

Validator output:
Invalid JSON
Unexpected token / … is not valid JSON

Takeaway: the file is valid JSONC. Don't run plain JSON.parse/jq on it
in CI — use tsc --showConfig or a JSONC-aware step. Strip the comment
first with json-format-fixer if a step truly needs strict JSON.

A test-fixture generator appended a second response to an existing file, producing two top-level objects. Each half is valid, but JSON allows exactly one top-level value, so the consumer's JSON.parse throws at the boundary.

Input (fixture.json):
{ "id": 1, "ok": true }
{ "id": 2, "ok": false }

Validator output:
Invalid JSON
Unexpected non-whitespace character after JSON at position 24 (line 2 column 1)

Fix: wrap both in an array [ … , … ], or split into two files /
use NDJSON with a line-by-line reader instead of JSON.parse.

A platform deploy rejected a config with SyntaxError … at position 412 and no line number. Pasting the same file content here reproduces the parser message with the same offset, and the pretty-printed surrounding structure makes the missing comma obvious.

Deploy log:
SyntaxError: Expected ',' or '}' after property value in JSON at position 412

Validator on the same file:
Invalid JSON
Expected ',' or '}' after property value in JSON at position 412 (line 18 column 3)

Now you have line 18 — the deploy log didn't give you that.

Once the file passes locally, the automated CI gate accepts it because both use RFC 8259 rules. This is the value of using the same parser on both ends — no 'works on my machine' gap.

Local validator: Valid JSON (1.8 KB)

CI step:
  - run: git ls-files '*.json' | xargs -I{} sh -c 'jq empty {} || exit 1'
  result: exit 0 — no files rejected

Files that use // comments or trailing commas are JSONC, not JSON. This tool runs strict JSON.parse, so it rejects them — and so will any CI step using jq or node. The 'Strict mode' checkbox does not enable comment tolerance; there is no permissive path. If a CI step genuinely needs strict JSON, strip comments first with json-format-fixer.

{"a":1,} or [1,2,] fail with Expected double-quoted property name / Expected value. This is the single most common hand-edit CI failure. The validator points at the comma's position; json-format-fixer removes it automatically.

{"env":"a","env":"b"} parses successfully and V8 silently keeps the last value ("b"). This validator does not detect duplicate keys — jq and node don't either. If two pipeline stages set the same config key, this passes and the later wins; review duplicates manually.

JSON permits exactly one top-level value. {...}\n{...} (newline-delimited JSON) fails at the second value with Unexpected non-whitespace character after JSON. NDJSON log/fixture files must be read line-by-line; wrap the lines in a [ ] array if you need a single JSON document.

Files saved by some Windows editors begin with a U+FEFF byte-order mark. The tool calls .trim() before parsing, and U+FEFF is whitespace in ECMAScript, so the BOM is stripped and the file validates. Note other parsers (e.g. some Python or Go readers) do not strip it — a BOM that's fine here can still break a stricter CI step.

An empty config (or one trimmed to nothing) fails with Unexpected end of JSON input. This often means an upstream generator wrote zero bytes — check that the file-producing step actually ran before the deploy step consumed it.

These are valid JavaScript literals but not valid JSON, so V8 rejects them (Unexpected token 'N'/'I'/'+'). A non-finite number usually means an upstream JS service serialised a division result without guarding it. Fix the producer; the validator can only flag it.

RFC 8259 allows a bare scalar as the whole document, so 42 and "ok" validate as 'Valid JSON'. If your consumer expects an object/array wrapper, a bare scalar can still break it downstream even though it's technically valid — the validator's job ends at syntax.

Free tier caps JSON files at 2 MB. Config and manifest files are almost always far below this. A multi-megabyte 'config' usually means embedded data that belongs in a separate file or a database; large bundled JSON validates on Pro (100 MB) or Developer (5 GB).

A raw tab or newline pasted into a string value (instead of \t / \n) fails with Bad control character in string literal. Common when copying multi-line text into a config value by hand; escape it or move the long text out of the JSON.