{ } JSON Workbench0 network requests. Check DevTools

"JSON Linter":{ }

Lint JSON the moment you paste it: an instant, strict RFC 8259 check with the exact line, column, and a caret on the first error: the same failure your editor or CI linter would catch, only faster. Use it for quick checks, then wire a CLI recipe into pre-commit or CI to stop bad JSON at the source. Runs 100% in your browser: zero network requests, so your data never leaves the page.

What is a JSON linter?

A JSON linter catches syntax errors in JSON before they break something downstream: a failed deploy, a rejected API request, a config your app won't boot with. "Lint" is the tooling term: the same strict RFC 8259 parse a validator runs, but framed around where you run it: in your editor as you type, in a pre-commit hook, or in CI. This page is the fast, ad-hoc version: paste or open a file and get the first error's exact line, column, and a caret on the offending character, all in your browser. For hands-off enforcement across a repo, pair it with one of the CLI recipes below.

Lint JSON in your editor, pre-commit hook, and CI

Use this page for the one-off check; automate the rest so a bad file can't slip through:

  • Editor: VS Code underlines JSON syntax errors natively. For comment-bearing configs, switch the language to JSONC or map the file via files.associations. Add a $schema key to lint values against a schema too.
  • Pre-commit: the check-json hook (from pre-commit-hooks) parses every staged .json and blocks the commit on a syntax error. Zero-dependency alternative: python -m json.tool staged.json > /dev/null.
  • CI: add a step running npx jsonlint -q "**/*.json" or npx prettier --check "**/*.json". A non-zero exit code fails the pipeline, so malformed JSON never merges.

The browser linter and the CLI use the same strictness, so what passes here passes there.

Common JSON lint errors and how to fix them

What you'll seeCauseFix
Unexpected end of inputA bracket, brace, or quote is never closed: often a truncated copy-paste or stream.Close the pair, or Repair to auto-close it.
Unexpected token '}', expected a valueA key with no value, or a trailing comma before the closing bracket.Add the value or delete the stray comma.
Unexpected token 'Single quotes: valid in JS and JSON5, but not JSON.Use double quotes, or Repair.
Comment flagged// or /* */ in a config file (JSONC).Strip Comments to get strict JSON.
Unexpected token TPython-style True/False/None instead of true/false/null.Lowercase the literals (Repair handles this).
Unquoted keyAn object key without double quotes (JS object syntax).Wrap every key in double quotes.

How to use

  1. Paste JSON (or open a config file like tsconfig.json or package.json) into the Input pane.
  2. The linter checks every keystroke against the strict JSON standard (RFC 8259), so you catch the error here instead of in a failing build.
  3. A red Invalid JSON badge gives the exact line, column, and a caret at the character your editor or CI linter would choke on.
  4. Non-standard-but-common input (single quotes, trailing commas, // comments) is flagged as fixable, with a one-click link to repair or strip it.
  5. For automation, wire one of the CLI recipes below into a pre-commit hook or CI step; use this page for the quick, ad-hoc check.

Examples

Config file lints clean

Input
{
  "compilerOptions": { "strict": true },
  "include": ["src"]
}
Output
✓ Valid JSON
Root: object · 2 keys · Depth: 3

Unexpected end of input (unclosed brace)

Input
{
  "port": 8080,
  "hosts": ["a", "b"]
Output
✗ Invalid JSON
Line 3, col 21: Unexpected end of input, expected ',' or '}'

Comment in a config (JSONC, not strict JSON)

Input
{
  // dev only
  "debug": true
}
Output
✗ Invalid. Line 2, col 3. Comments aren't JSON; strip them for a strict lint.

FAQ

Is a JSON linter the same as a JSON validator?

For JSON, they do the same core check: parse the text against the strict standard (RFC 8259) and report the first error. The difference is framing: "validate" answers "is this valid?", while "lint" is the developer-workflow word for catching those errors in your editor, a pre-commit hook, or CI before they reach production. If you just want a pass/fail verdict, the JSON Validator is the same engine with a validation-first layout.

How do I lint JSON in VS Code?

VS Code lints .json files out of the box via its built-in JSON language service. Syntax errors are underlined as you type. For files with comments (tsconfig.json, .vscode/settings.json), set the language mode to JSON with Comments (JSONC) or add a files.associations entry so valid comments aren't flagged. Attach a $schema to also lint against a JSON Schema, not just syntax.

How do I lint JSON in a pre-commit hook or CI?

Run a strict parser over your JSON as a build step and let a non-zero exit code fail the commit or pipeline. Cross-platform options: python -m json.tool file.json > /dev/null (no install), npx jsonlint -q file.json, or npx prettier --check "**/*.json". In a pre-commit config, the check-json hook does this for every staged JSON file.

What's the difference between linting and formatting JSON?

Linting only checks. It reports errors and changes nothing. Formatting rewrites the whitespace (beautify or minify). A typical flow is lint to catch problems, then beautify to standardize style or repair to fix broken input. Tools like Prettier blur the line by refusing to format input that doesn't parse, effectively linting first.

Can it lint JSONC or JSON5?

This linter is strict, so comments, trailing commas, and single quotes are reported as errors, which is exactly what you want before shipping to a strict parser. If your source is intentionally JSONC/JSON5 (a config file), run Strip Comments first to get the strict-JSON equivalent, then lint that.

Is my JSON uploaded?

No. The linter runs 100% in your browser. Open DevTools → Network and confirm: zero requests after the page loads. Config files and payloads with secrets never leave your machine.

Related tools