JSON doesn't allow trailing commas because its grammar only puts a comma between two values, never after the last one. So [1, 2, 3,] and {"a": 1,} aren't valid JSON, even though JavaScript accepts both. The rule was kept strict on purpose: when every parser accepts exactly the same text, a file written in one language reads the same way in every other.
What the grammar actually says
The JSON standard, RFC 8259, defines an array as an opening bracket, an optional first value, then any number of "comma, value" pairs, then the closing bracket. Objects work the same way with members. Every comma has to be followed by another value. There's no rule that lets a comma sit in front of ] or }.
You can see it in the error messages. In a recent Node.js release I got:
JSON.parse('[1, 2, 3,]')
// Unexpected token ']', "[1, 2, 3,]" is not valid JSON
JSON.parse('{"a": 1,}')
// Expected double-quoted property name in JSON at position 8 (line 1 column 9)
The second message shows how the parser reads an object: after a comma it expects another key, so it complains about a missing property name instead of the comma. Python 3.14 is blunter: json.loads('[1, 2, 3,]') says Illegal trailing comma before end of array.
Why it was kept strict
I couldn't find a statement from Douglas Crockford himself explaining this exact rule. The history explains it well enough.
Parsers used to disagree. RFC 8259 says a parser must accept all valid JSON and may accept extensions. Firefox's engine used that freedom. Its JSON parser accepted input like JSON.parse('[1, 2, 3, ]') until 2010, when the team removed it. Their reason: accepting extra syntax makes interoperability harder, because JSON that worked in one browser broke in another. ES5 specified the allowed JSON syntax precisely, and trailing commas weren't in it.
JSON isn't only for JavaScript. It is read by Python, Go, Java, C and many more. When someone asked Crockford why JSON doesn't allow empty array slots (a close cousin of the trailing comma), he reportedly said it was because not all languages handle sparse arrays. That fits the JavaScript side too: in JS, more than one trailing comma creates a hole in the array, and MDN shows that [1, 2, 3, , ,] has a length of 5. A data format can't have rules like that.
Meanwhile JavaScript kept loosening. MDN notes that JavaScript has allowed trailing commas in array literals since the beginning, and later added them to object literals, function parameters, imports and exports. JSON is a very restricted subset of that syntax and disallows all trailing commas. The same text is fine in a .js file and broken in a .json file.
Where you'll trip over it
The usual case is hand-editing. You delete the last item in a package.json list, leave the comma behind, and npm refuses to read the file. Or you copy an object out of your JavaScript code into a fixture file, and the trailing commas that Prettier added come along with it.
The other case is JSON built with string concatenation, like a loop that writes item + "," for every element. The last item gets a comma too, and the output is broken in a way that only shows up when something tries to parse it. Use your language's serializer instead. JSON.stringify never writes a trailing comma, and neither does Python's json.dumps, so if you build the data as a normal array or object and serialize it at the end, the problem can't happen.
To fix a file by hand, go to the position in the error message and look one step back. The bad comma is the last one before the ] or } the parser points at. For arrays, Node names the ] it ran into; for objects, it gives the position where it expected a new key, which is the }. Python reports the comma's line and column directly.
If you've got a long file and can't spot the comma, the OnlineViewer JSON validator shows the JSON.parse error with its position, and it runs in the page, so you can paste config that holds secrets. For other parse errors, such as an empty response body, see what "Unexpected end of JSON input" means.
When trailing commas are fine
Some JSON-like files allow them, which is why people expect strict JSON to.
- VS Code settings. VS Code opens
settings.json,tasks.jsonandlaunch.jsonin a JSON with Comments (jsonc) mode. That mode accepts trailing commas, though the editor discourages them and shows a warning. A trailing comma that works in your editor settings tells you nothing about strict JSON. - JSON5. JSON5 is an extension of JSON meant to be easier to write by hand. Objects and arrays may have a single trailing comma, and comments are allowed. The project says plainly that it is not intended for machine-to-machine communication.
My take: the strict rule is the right call for data, and a mild nuisance for config. Keep anything that goes over the network or between programs as plain JSON. Use JSON5 or jsonc only for files people edit by hand, where you know which tool reads them.
The cost: once a file depends on trailing commas, every tool that touches it (linters, CI scripts, other languages) needs a parser that understands that dialect, and a plain JSON.parse will reject it.
FAQ
Is a trailing comma valid JSON?
No. The JSON grammar in RFC 8259 only allows a comma between two values or two members, so a comma right before ] or } is invalid.
Why does JavaScript allow trailing commas but JSON doesn't?
JSON is a very restricted subset of JavaScript syntax. JavaScript added trailing commas in more places over time; JSON's grammar stayed fixed so every parser in every language agrees on what is valid.
Why does VS Code accept trailing commas in settings.json?
VS Code opens its own config files in JSON with Comments (jsonc) mode, which accepts trailing commas but shows a warning. That file is not strict JSON.
What format should I use if I want trailing commas?
For hand-edited config, JSON5 or jsonc allow them. For data sent between programs, stick to strict JSON.