JSON Editor

Editing JSON Safely

JSON is unforgiving to edit by hand because a single misplaced character invalidates the entire document, and the error is usually reported somewhere other than where you made the change. A few habits remove almost all of that pain.

Validate continuously rather than at the end. If you check after twenty edits, you have twenty candidate causes for the failure. If the editor tells you the moment a change breaks the syntax, you always know which edit did it, because it was the one you just made.

Format before you start editing. Minified JSON is nearly impossible to modify correctly by hand: you cannot see nesting, you cannot tell which closing brace matches which opening one, and a comma inserted in the wrong place looks identical to one in the right place. Beautify first, edit in the readable form, and minify at the end if you need to.

Keep the original before any bulk change. Renaming a key across 400 records or removing a nested block is fast to do and slow to undo. Copy the source somewhere first, whether that is a git commit, a duplicate file, or another browser tab. Then diff the two when you finish, because a diff catches the record you accidentally skipped in a way that re-reading the file never will.

Change one kind of thing at a time. Renaming keys and converting types in the same pass makes the diff much harder to review and hides mistakes inside noise.

Common Editing Tasks

Four operations cover most hand edits. Each has a specific failure mode worth naming.

Adding a field

The mistake is always the comma. Adding a pair at the end of an object means the previous last line now needs a trailing comma, and the new line must not have one.

{
  "name": "reporting-service",
  "port": 8080
}

{
  "name": "reporting-service",
  "port": 8080,
  "healthPath": "/healthz"
}

Renaming a key across an array of records

Find and replace works, but only if you match enough context to avoid collateral damage. Searching for user and replacing it will also hit values, substrings such as username, and any key ending in user. Include the quotes and the colon in the search term, so you replace "user": and not user. Then confirm the replacement count matches the record count before you save.

Changing a type from string to number

This is a two-character edit that is easy to do halfway, leaving one quote behind and breaking the document. Delete both quotes together, and check the value is still a legal JSON number afterwards: a leading zero or a plus sign that was harmless inside a string becomes a syntax error outside one.

{
  "quantity": "12",
  "unitPrice": "4.50",
  "batch": "0091"
}

{
  "quantity": 12,
  "unitPrice": 4.5,
  "batch": "0091"
}

Note that batch stayed a string on purpose. Its leading zeros are meaningful and would both be lost and be invalid as a number.

Removing a nested block

Delete from the opening brace of the block through its matching closing brace, then fix the comma on whichever side is now adjacent to a bracket. If the removed block was last in its parent, the preceding entry loses its trailing comma. If it was first or in the middle, one comma goes with it. Reformatting immediately afterwards confirms you got the braces right, since a mismatched pair will refuse to format.

Config File Formats You Will Edit

Most hand-edited JSON is configuration rather than data. These are the files you will meet most often and what each one controls.

The tsconfig.json row is the one that causes arguments. TypeScript accepts comments and trailing commas there because it parses the file as JSONC, and the default generated config is full of explanatory comments. Those same comments will make a strict JSON validator reject the file, and that rejection is accurate: the file is valid JSONC and invalid JSON. The same applies to Visual Studio Code settings.json and launch.json. Everything else in the table is strict JSON, so a comment in package.json really will break npm.

Escaping Rules When Hand Editing

Six characters cannot appear literally inside a JSON string. Everything else, including unicode text in any script, can be written directly as long as the file is UTF-8.

The classic trap is the Windows file path. A single backslash starts an escape sequence, so a path pasted straight from Explorer is either invalid or, worse, silently wrong. In the example below the first line fails because backslash U is not a recognized escape, while a path containing a folder starting with n or t would parse into a string with a real newline or tab inside it and cause a confusing failure much later.

{"log": "C:\Users\dev\notes\temp.txt"}

{"log": "C:\\Users\\dev\\notes\\temp.txt"}

Forward slashes are the simpler answer where the consuming program accepts them, since Windows APIs generally do and no escaping is needed at all. Note also that a forward slash may optionally be written as backslash forward-slash, a legacy allowance for embedding JSON inside HTML script tags, but it is never required.

Pair this with the JSON Validator while you work and the JSON Formatter before you commit. Browse the full collection of free JSON tools to find the right one for the job.