Common JSON Formatting Errors and How to Fix Them
Invalid JSON stops deployments and breaks API integrations — usually over a trailing comma or a smart quote. Here are the failures I see weekly and the fastest fixes.
By Vertex Solutions Editorial
The Slack message read: "prod config broken, JSON.parse exploded."
The culprit was a trailing comma after the last feature flag. One character. The deploy had been green twelve minutes earlier — someone pasted from a JavaScript object literal into a .json file and didn't run a validator.
I've seen JSON failures take down deploy scripts, break Zapier zaps, and make Notion API importers spew hex errors at non-technical users. The language is strict on purpose. Strict doesn't mean mysterious once you know the repeat offenders.
Quick answer
Most invalid JSON fails on trailing commas, smart quotes, or comments copied from JavaScript. Paste the payload into a validator, fix the reported line, and re-run parse before you deploy — one character usually separates working config from a production outage.
JSON isn't JavaScript (even though it looks related)
JSON is a data interchange format. JavaScript object literals borrowed its shape but added comforts JSON refuses:
- Trailing commas
- Comments
- Single-quoted strings
- Unquoted keys
undefined,NaN,Infinity- Functions
Copy-paste from JS into JSON is the #1 source of "it worked in the console" incidents.
Error 1: Trailing commas
{
"host": "api.example.com",
"port": 443,
}
That comma after 443 is illegal in JSON.
Fix: Delete it. Configure Prettier or ESLint for JSON files if your editor allows JSONC — know which files must stay strict.
Paste into JSON Validator to confirm clean parse.
Error 2: Single quotes
{'name': 'Vertex Solutions'}
Fix: Double quotes only:
{"name": "Vertex Solutions"}
Or run through JSON Formatter after find-replace — but watch for apostrophes inside strings.
Error 3: Unquoted keys
JavaScript allows {name: "value"}. JSON does not.
Fix:
{"name": "value"}
Error 4: Comments left in config files
{
// production API
"url": "https://api.example.com"
}
Fix: Remove comments or move notes to README. Some teams use JSON5 or YAML for human-edited config — pick one format per file and enforce it in CI.
Error 5: Smart quotes from Word/Slack
Curly quotes " " break parsers that expect ASCII ".
Fix: Re-type quotes or paste through a plain-text stripper. Case Converter won't fix quotes — awareness will.
Error 6: NaN, Infinity, undefined
JavaScript serializes odd floats sometimes; JSON spec excludes them.
Fix: Use null or strings "NaN" if downstream expects that contract — document the choice.
Error 7: Duplicate keys
{"id": 1, "id": 2}
Last key wins in many parsers — silently. Bugs hide.
Fix: Validator + code review. Some linters flag duplicates.
Error 8: BOM and invisible characters
UTF-8 BOM at file start breaks naive parsers. Zero-width spaces from web copies do too.
Fix: Save as UTF-8 without BOM. Hex dump the first bytes if errors point to line 1 column 1 with "empty-looking" content.
Step-by-step debugging workflow
- Copy the exact payload failing in prod (redact secrets).
- Paste into JSON Validator — read line/column.
- Jump to that line in editor; fix the obvious (comma, quote).
- Format with JSON Formatter for readable diff next time.
- Add CI check:
jq empty file.jsonor equivalent on every commit touching config.
Worked example: broken webhook body
Marketing pasted this into a no-code tool:
{
event: "signup",
'email': user@example.com,
}
Three issues: unquoted event, single-quoted key, unquoted email without string delimiters.
Corrected:
{
"event": "signup",
"email": "user@example.com"
}
Validator green. Zap runs.
When to format vs when to minify
Format (pretty-print) for humans editing configs and reviewing PRs.
Minify for wire transport where bytes matter — but keep a pretty source of truth in git, not a one-line blob nobody can review.
Don't minify until valid — minifiers assume parseable input.
Common mistakes in teams
Validating only in the browser
Node, Python, and Go parsers differ on edge cases slightly — validate in the same runtime that consumes the file if possible.
Huge monolithic JSON
Split environment configs. Smaller files mean faster human location of errors.
Storing secrets in JSON committed to git
Formatting won't fix leakage. Use env vars or secret managers.
Browser compatibility
JSON.parse exists in all modern browsers. Vertex Solutions text tools run client-side — payloads you paste aren't inherently sent to a server for validation, but treat pasted production secrets carefully anyway.
Related reading
- The Complete Guide to Formatting JSON Data — broader workflow
- Base64 in Web Development — adjacent encoding confusion
- UUID in API Development — IDs beside JSON payloads
Troubleshooting
Why does JSON not allow trailing commas? The JSON spec forbids trailing commas after the last array or object element. JavaScript often tolerates them; JSON.parse does not. Remove the comma or use a linter.
Can JSON have comments? Standard JSON does not support // or block comments. Some tools accept JSONC (JSON with comments), but APIs expecting strict JSON will reject them.
Are single quotes valid in JSON? No. Strings must use double quotes. Single-quoted keys or values cause parse errors.
Limitations
Browser-based workflows for common json formatting errors and how to fix them depend on file size, browser memory, and how the source file was created. Very large files, password-protected inputs, or unusual encodings may fail without a desktop alternative. Always keep an original copy before batch processing.
When not to use this approach
Skip browser-only processing when compliance requires audit logs, when files exceed practical browser limits, or when you need features your browser tool does not expose (bookmarks, form fields, digital signatures). In those cases, use dedicated desktop software or an approved enterprise pipeline.
Related tools
Key takeaways
- Why does JSON not allow trailing commas: The JSON spec forbids trailing commas after the last array or object element.
- Can JSON have comments: Standard JSON does not support // or block comments.
- Are single quotes valid in JSON: No.
Conclusion
JSON errors feel catastrophic because they block everything downstream — but most are small syntax slips, not deep logic bugs. Kill trailing commas, ban smart quotes, quote your keys, run a validator before deploy, and stop copy-pasting JavaScript object literals into .json files without a second look.
Strict syntax is a feature. Treat it like one.
CI integration tip
Add a jsonlint or jq empty step to pull requests that touch .json files. Fail the build on the first parse error with file path and line number in the log. Teams that only validate manually before deploy still ship broken configs — automation catches the Friday 5 p.m. edit that nobody re-reads until Monday's incident.
Real-world examples
Teams usually adopt this workflow when a recurring task — weekly exports, client deliverables, or form validation — starts costing more time in rework than in doing it carefully once. Start with one real document or dataset from this week, not a synthetic demo.
Frequently Asked Questions
Common questions answered to help you get the most from this tool.