How to repair malformed json configuration files
- Step 1Confirm whether the file is JSON or JSONC — If it's
tsconfig.json,.vscode/settings.json,devcontainer.json, or anything with//comments, it's JSONC — this fixer won't strip the comments. For a strict-JSON config (package.json, mostappsettings.json), continue. - Step 2Paste or drop the config — Paste the full file content, or drop the
.jsonfile on the dropzone. It's read locally viafile.text(); connection strings and secrets never leave your browser. - Step 3Pick an indent matching your repo — Choose 2 or 4 spaces to match your project's style (most JS/TS repos use 2). The fixer re-serializes, so the output's indentation is uniform regardless of the input's.
- Step 4Click Fix JSON — The tool tries
JSON.parsefirst; if it throws, the five repair passes run. For a config, the passes that usually fire are trailing-comma removal and quote normalization. - Step 5Read the Fixes applied list and banner —
Removed trailing commasis the usual culprit. Green means the config will load. Yellow means a comment, a missing bracket, or another non-fixable error remains — don't redeploy yet. - Step 6Paste back and restart — Copy the fixed JSON into the config file and restart the app. If you needed comments, switch the parser to a JSONC reader (
jsonc-parser, or VS Code's built-in JSONC handling) rather than stripping them.
Config errors: fixable vs not
What this strict-JSON fixer repairs in a config file and what it intentionally leaves alone. The right column is the correct alternative.
| Config error | Auto-fixed? | Correct handling |
|---|---|---|
| Trailing comma after last property | Yes | n/a |
| Single-quoted keys/values from a code sample | Yes | n/a |
Unquoted keys (strict: true) | Yes | n/a |
Literal undefined value | Yes (→ null) | Prefer omitting the key entirely |
// line or /* block */ comments | No — no comment pass | Use a JSONC parser (jsonc-parser); don't strip them |
| Duplicate keys | No — not detected | JSON.parse keeps the last; review by hand |
Missing closing } / ] | No | Add the bracket manually (validator shows position) |
| Smart quotes from a doc paste | No — only straight quotes | See the paste-fix guide |
Common config files and what bites you
Whether each file type is strict JSON or JSONC, and the typical hand-edit error.
| File | Format | Typical break |
|---|---|---|
package.json | Strict JSON | Trailing comma after the last dependency |
tsconfig.json | JSONC (allows comments) | Don't run through this fixer if it has comments |
.eslintrc.json | Strict JSON (.eslintrc may be JSONC) | Single quotes copied from a JS config example |
appsettings.json (.NET) | Strict JSON | Trailing comma; duplicate section key (not detected) |
| .vscode/settings.json | JSONC | Has comments — keep using VS Code's JSONC handling |
composer.json / manifest.json | Strict JSON | Trailing comma; unquoted key from a copy-paste |
Cookbook
Real hand-edited config breakages, the fix applied, and the banner. Secrets anonymised.
package.json trailing comma after last dependency
ExampleYou deleted a dependency but left the comma. npm/yarn refuse to read the file. The fixer strips it.
Input:
{
"name": "app",
"dependencies": {
"react": "^18.0.0",
"zod": "^3.0.0",
}
}
Fixes applied (1):
✓ Removed trailing commas
Banner: Fixed & valid JSON — npm install will now read it.ESLint config copied from a JS example
ExampleYou pasted a rule block from a .eslintrc.js example into a .eslintrc.json, carrying single quotes and unquoted keys. Two passes fix it.
Input:
{ rules: { 'no-unused-vars': 'warn', semi: 'error' } }
Fixes applied (2):
✓ Replaced single quotes with double quotes
✓ Added quotes to unquoted object keys
Banner: Fixed & valid JSON
Output:
{
"rules": {
"no-unused-vars": "warn",
"semi": "error"
}
}appsettings.json with a leftover undefined
ExampleA find-replace left the literal undefined in a .NET settings value. The fixer maps the value to null; the pass is string-aware, so any string value containing the word 'undefined' is left untouched.
Input:
{ "ConnectionString": "...", "Timeout": undefined }
Fixes applied (1):
✓ Replaced undefined with null
Banner: Fixed & valid JSON
Better: remove the Timeout key so the app uses its default.tsconfig.json with comments — DON'T use this tool
Exampletsconfig is JSONC. Its // comments are valid for TypeScript but this fixer has no comment pass, so it reports the file invalid. Keep the comments and let the JSONC parser handle them.
Input:
{
// strict mode for the whole project
"compilerOptions": { "strict": true }
}
Fixes applied (0)
Banner: Partially fixed — output may still have issues
Wrong move: stripping the comment to satisfy a strict parser.
Right move: tsconfig is JSONC — TypeScript reads the comments fine.Duplicate key the fixer won't warn about
ExampleA config has the same key twice. The fixer reports it valid because JSON.parse silently keeps the last value. This is a real config bug it cannot surface.
Input:
{ "port": 3000, "host": "a", "port": 8080 }
Fixes applied (0)
Banner: Fixed & valid JSON (!)
Reality: JSON.parse kept port=8080 and discarded 3000
with no warning. Audit for duplicate keys by hand.Errors and edge cases
Real errors and silent failures sourced from each platform's own documentation. Match the wording to the row, fix what the row says to fix.
Config contains // or /* */ comments
InvalidThis fixer has no comment-stripping pass, so any commented config is reported invalid. Crucially, if the file is tsconfig.json, .vscode/settings.json, or devcontainer.json, it's JSONC and the comments are correct — don't strip them. Use a JSONC parser (jsonc-parser) instead of forcing strict JSON.
Duplicate keys
By designThe fixer does not detect duplicate keys, contrary to what you might expect from a 'config repair' tool. JSON.parse silently keeps the last occurrence, so {"port":3000,"port":8080} parses as port:8080 with the file reported valid. This is a real config bug the tool cannot surface — review duplicates by hand.
Missing closing bracket
FailA config truncated mid-edit ({"a":1) has no bracket-balancing pass and stays invalid. Open the partial output in the JSON validator for the exact position, then add the missing } or ] manually.
Smart quotes from a documentation paste
InvalidCopying a config snippet from a rendered docs page or a PDF can introduce curly “ ” quotes. Only straight ' quotes are converted, so smart quotes survive and break parsing. The paste-fix guide explains why and how to source clean snippets.
undefined inside a string config value is preserved
By designThe undefined pass is string-aware: it tracks string state while walking the file, so a value like "fallback is undefined" is left exactly as-is. Only a bare undefined config value is rewritten to null. Config strings are never silently changed, so no review of values containing the word undefined is needed after fixing.
Unquoted key with a hyphen or dot
RejectConfig keys like no-unused-vars or env.production are common, but the unquoted-key pass only matches [A-Za-z0-9_$] and stops at - or .. An unquoted hyphenated key won't be fixed. Wrap it in double quotes by hand: "no-unused-vars":.
Already-valid config
ExpectedA correct config parses on first try — no passes run, No fixes needed, and you get it back re-indented to your chosen style. Handy as a quick consistency pass before committing, though a dedicated prettifier is the better fit for pure reformatting.
Config larger than 2 MB on free tier
BlockedFree tier caps files at 2 MB — generous for config, which is rarely that big. A 2 MB+ config usually means generated data crept into a config file. Pro raises the ceiling to 100 MB.
Single quotes around a value containing an apostrophe
RejectA description value like 'user's home' defeats the value-quote pass ('[^']*' stops at the inner apostrophe), producing broken output. Use proper double quotes for any value containing an apostrophe.
Frequently asked questions
Can JSON config files have comments?
Standard JSON cannot, but JSONC (JSON with Comments) can — and many config files are actually JSONC: tsconfig.json, VS Code's settings.json, and devcontainer.json all allow // and /* */. This fixer produces strict JSON and has no comment-stripping pass, so it reports commented files as invalid. The right answer is to read them with a JSONC parser (jsonc-parser), not to strip the comments.
Does the fixer remove comments from my config?
No. There is no comment-stripping pass. If your config has // or /* */ comments and you run it through this tool, it stays reported as invalid. Either keep the comments and use a JSONC parser, or delete the comments yourself before fixing if you genuinely need strict JSON.
Does it detect duplicate keys?
No — despite being a config-repair tool, it doesn't detect duplicates. JSON.parse silently keeps the last value of a repeated key, so a file with two "port" keys parses as valid with only the last value. This is a real config bug the tool can't surface; audit for duplicate keys manually.
Why does my app fail to start with a JSON config error?
Most often a trailing comma after the last property — valid in JavaScript, invalid in JSON. Other common causes: single quotes copied from a JS example, an unquoted key, or a comment in a file the loader treats as strict JSON. Run the config through the fixer; the Fixes applied list tells you which one it was.
Which config errors does it actually fix?
Four that matter for config: trailing commas, single-quoted keys/values, unquoted keys, and the literal undefined (→ null). It does not fix comments, duplicate keys, missing brackets, or smart quotes — it reports those as still-invalid rather than mangling the file.
It said my config is valid but the wrong value is taking effect.
Almost certainly a duplicate key. JSON.parse (and therefore this fixer) silently keeps the last occurrence and reports the file valid. Search the file for repeated keys at the same nesting level — the tool won't flag them for you.
Can I control the indentation to match my repo style?
Yes — 2 or 4 spaces, the only two options. Pick the one your project uses (most JS/TS repos use 2). The fixer re-serializes via JSON.stringify, so the output is uniformly indented no matter how the input was formatted.
Is it safe to paste a config with secrets into this tool?
Yes — processing is entirely in-browser. Connection strings, API keys, and internal hostnames in your config never reach JAD Apps servers. A signed-in run logs only an anonymous counter with no content. Still, prefer placeholder values for anything you'll share.
What about .env or YAML config?
This tool is JSON-only. For YAML config, convert with yaml-to-json (or the reverse with json-to-yaml) and fix the JSON side here. .env files aren't JSON at all and aren't supported.
How do I find the exact position of a remaining error?
If the banner stays yellow, paste the partially-fixed output into the JSON validator — it reports the line and column of the first error, which is what you need to fix a missing bracket or a stray comment by hand.
Will it reorder or remove my config keys?
No. It preserves key order and content; the only data-affecting pass is undefined→null, which is string-aware — it changes only a bare undefined value, never the word undefined inside a string. Re-serialization keeps the original property order from the source. To compare the fixed config against the original structurally, use the JSON diff tool.
What file size can I fix?
2 MB on free tier, 100 MB on Pro — far more than any normal config needs. A 2 MB+ 'config' usually means generated data was committed into a config file by mistake.
Privacy first
Conversion runs locally in your browser. No file is uploaded — only metadata counters are saved for signed-in dashboard stats.