JSON lint — syntax and quality warnings
A stricter read than a plain parse: syntax errors with line and column, plus warnings for duplicate keys and unsafe integers. Runs offline.
- Runs in your browser
- Files are never uploaded
- Free, no account
Your JSON never leaves this tab — check it yourself—
Starting the network probe…
The counter above wraps fetch, XMLHttpRequest and navigator.sendBeacon in this tab and counts every call. It does not block anything — it just reports.
Two ways to verify independently
- Turn off Wi-Fi or enable airplane mode, then use the tool. It keeps working, because the page is already fully loaded.
- Open your browser devtools, switch to the Network tab, clear it, and run the tool. No new row appears.
Why this matters
In 2025 researchers found that popular online formatters had retained tens of thousands of user-submitted snippets — JSONFormatter.org and CodeBeautify together exposed roughly 80,000 saved documents, many containing live cloud credentials, private keys and internal database connection strings, because “format this” quietly meant “upload this”. A separate incident exposed roughly 3.5 million user PDFs on a document-conversion service. The only structural fix is not sending the data in the first place: this site is served under a Content-Security-Policy whose connect-src contains no third-party origin, so a request off this device cannot be made even by accident.
Validating and linting are different jobs
Validation answers a yes/no question: will a parser accept this document? Linting asks a harder one: is this document what its author meant? A file can pass the first and fail the second, and the failures are the expensive kind — they do not throw, they just behave differently from how the file reads.
Both run here. The syntax verdict appears first; the lint warnings appear underneath it.
The checks that run on a valid document
Duplicate keys
Nothing in the JSON grammar forbids the same key twice in one object, and nothing in any
mainstream parser reports it. JSON.parse, Python’s json, Go’s
encoding/json and Jackson all keep the last occurrence. The practical consequence:
a settings file where a key was accidentally pasted twice silently uses the wrong value, and a
code review of the diff shows nothing wrong because both lines look plausible.
Integers beyond double precision
The JSON specification places no limit on the magnitude of a number, but it also says nothing about how one must be represented. Every JavaScript parser uses a double, which is exact only up to 253 − 1. Any longer integer — a Snowflake ID, a nanosecond timestamp, a bigint primary key — is silently rounded on parse and re-serialised as the rounded value. The linter flags integers of 16 digits or more that fail an exactness check.
What this linter deliberately does not do
It does not enforce a style. JSON has no canonical formatting, so a linter that complained about indentation, key order or line length would produce nothing but noise. If you want consistency across a repository, pick one indent and sort keys, apply it once, and commit the result — the sort-keys switch on this page makes it a one-step operation and makes future diffs stable.
It also does not validate structure. Whether "email" is present, whether
"status" is one of three allowed values, whether "count" is
non-negative — those are schema questions. Generate a starting schema with the
JSON Schema generator and validate with Ajv or
python-jsonschema in your own pipeline.
Linting JSON that is not quite JSON
| Format | What it adds | How to lint it here |
|---|---|---|
| JSONC (VS Code settings, tsconfig) | Comments, trailing commas | Run the repair, then lint the strict copy |
| JSON5 | Comments, unquoted keys, single quotes, hex numbers, Infinity | Repair handles all but hex numbers |
| NDJSON / JSON Lines | One document per line | Lint one line at a time, or wrap the lines in an array |
| JSON with a BOM | An invisible U+FEFF prefix | Repair strips it |
A workflow that catches problems earlier
- Lint the file the moment it fails, not after you have edited it — the original error position is far more informative than the position after three speculative fixes.
- If the document came from an API, check the first character. A
<means you received an HTML error page, and the JSON is not the problem. - Once it parses, read the warnings before closing the tab. A duplicate key found now is cheaper than a support ticket later.
- Format with a fixed indent and commit that, so the next diff is about content rather than whitespace.
Questions
What does linting add over validating?
Validation answers one question: will a parser accept this? Linting also flags things that parse fine but are almost certainly bugs — the same key appearing twice in one object, and integers too large to survive a JavaScript round trip. Both checks run here; the lint warnings appear under the green verdict.
Does it enforce a style guide?
No. JSON has no canonical style, and imposing one would produce noise rather than findings. If you want consistent formatting across a repository, format with a fixed indent and sorted keys and commit that — the sort-keys switch on this page makes diffs stable.
Can I lint newline-delimited JSON (NDJSON)?
Not as one document — JSON permits exactly one top-level value, so an NDJSON file fails with “expected the end of the document”. Lint one line at a time, or wrap the lines in an array first.
What about JSON5 or JSONC?
They are different languages. Comments, trailing commas and unquoted keys are legal in JSON5 and in VS Code's JSONC, and illegal in JSON. If your file is meant to be JSONC, the errors this page reports are expected — use the repair button to produce a strict-JSON copy.