Data and structured data
Where should I fix this JSON error?
Tools to use
You changed one setting and the JSON stopped loading. The reported line contains an ordinary closing brace. Before deleting braces or values, consider what the parser was expecting when it reached that point.
We will use small fictional examples instead of production configuration. The aim is not merely to silence an error: it is to preserve the meaning of each name and value while restoring data that the receiving system can read.
Look immediately before the closing brace
Open JSON formatting and validation and run the following input, including its final comma. First reproduce the failure; then change only one thing so you can identify why it failed.
{"name":"Ada","count":2,}The comma after count promises another member, but the next character closes the object. An error near the brace therefore does not necessarily mean the brace itself is wrong. Inspect the separator immediately before it.
{"name":"Ada","count":2}Run it again and inspect the formatted output. name should still be Ada and count should still be the number 2. Finish the repair by checking preserved values, rather than stopping as soon as the success indicator appears.
One small repair is easier to verify
Several errors in a long configuration can tempt you to replace every quote or comma. A single missing quote, however, can change how the entire remainder is interpreted. Start at the earliest reported error and inspect a small surrounding region.
- Keep your own working copy of the original data.
- Inspect the first error and the quotes, separators, and brackets before it.
- Make one minimal repair that preserves meaning, then run again.
- After success, check values and counts and compare before and after if needed.
Similar-looking quotation marks are different characters
{"name":"Ada"}
{'name':'Ada'}
{“name”:“Ada”}The first input uses JSON double quotes. The second uses single quotes, and the third uses typographic quotation marks. They may look similar on screen but are different characters. This is a useful check when data stopped working after being copied through a document or message.
Avoid blindly replacing every apostrophe with a double quote. An apostrophe in O'Reilly is part of a value. Delimiters and the contents they enclose have different roles, so a global replacement can damage otherwise correct data.
Did a syntax repair accidentally change a type?
{"count":2,"enabled":false}
{"count":"2","enabled":"false"}Quoting a value may make an input parse, but the receiving application might require a number or boolean. The string false is not the boolean false. Formatting success establishes neither the application's accepted types nor its business rules.
Conversely, a membership identifier such as 00123 may deliberately be a string to preserve its leading zeros. Ask whether the value is a quantity used in arithmetic or an identifier. Check the receiving contract before changing its type.
Formatting reveals structure, not just prettier text
{"items":[{"name":"pen","quantity":2},{"name":"book","quantity":1}],"currency":"JPY"}Format this with two-space indentation. The two items become easier to follow: each name belongs with its quantity, while currency is outside the array. Indentation exposes relationships already present in the data; it does not add new fields.
Minification removes unnecessary whitespace outside strings. Spaces inside a name are still data and must remain. Use formatting for review and minification when a compact representation is useful; neither operation should be confused with editing the actual values.
Check every digit of long identifiers
{"id":9007199254740993}This sample detects a failure that is easy to overlook visually. SheepDev's formatter uses a precision-preserving parser and retains the final 3. That does not establish how a spreadsheet or another program will handle the output: compare the digits again at the destination.
Formatting data after a digit has already changed cannot recover the lost original. This is another reason to keep the source for comparison. Representing an identifier as a string may help in a suitable contract, but changing the receiving contract is a separate decision.
When a value contains a newline or a quote
{"message":"He said \"hello\".\nNext line."}A quote inside a sentence can make the boundary of a value confusing. Here a backslash makes the following quote part of the content rather than the end of the string. Backslash followed by n represents a newline. The two visible characters in the editor and the newline in the decoded value are different representations.
Do not confuse an escaped newline with pasting a literal line break inside a quoted JSON string. Deleting a newline just to remove an error may change the intended message. Treat formatting as improving the representation, not as permission to edit the prose itself.
Did you copy only the JSON?
Copying an entire log line may include a timestamp or INFO prefix. A developer console may show an explanatory object representation rather than the response body. Failure to parse that display does not prove that the API is broken. First identify whether you copied actual JSON or a presentation surrounding it.
Examples copied from chat or articles may include code-fence markers or an 'Example' heading. A selection can also end too early and omit the closing bracket. Recopy the actual body and check its beginning and end before modifying the content; this avoids repairing a problem caused only by the selection.
Do two pasted objects become an array?
{"id":1}
{"id":2}Each line can be valid on its own while the combined input is not one JSON document. Formats such as JSON Lines have a different framing convention. SheepDev's JSON formatter does not automatically combine separate documents into a new structure.
[{"id":1},{"id":2}]An array requires square brackets and commas between elements. But use an array because the receiver expects one, not merely because it removes an error. A line-oriented log may need to remain line-oriented. Distinguish a syntax repair from a change to the data structure.
What should you check after formatting succeeds?
Readable JSON is not necessarily a correct configuration. A negative quantity or a misspelled field such as quantitiy can still be syntactically valid. Required fields and accepted ranges must be checked against the receiving system's specification.
When handing over a fix, say what changed and what you checked: for example, 'Removed the trailing comma; name and count are unchanged.' This is more useful than 'It formats now' because the next person can see both the cause and the limits of your verification.