Start with a small, non-sensitive example
A compact API response can be difficult to inspect. Formatting adds indentation and line breaks so you can see which fields belong together. It should help you read the data; it is not a reason to change field names, reorder a list, or replace a missing value.
Try this fictional inventory record in the SLR TECH JSON formatter. The item and values are demonstration data.
{"item":"sample-coconut","quantity":12,"unit":"pieces","available":true,"tags":["demo","inventory"]}A readable version is:
{
"item": "sample-coconut",
"quantity": 12,
"unit": "pieces",
"available": true,
"tags": [
"demo",
"inventory"
]
}Notice that 12 remains a number, true remains a boolean, and the two tags remain in their original sequence. The extra space is outside string values. Spaces inside a quoted description are part of the description and should be preserved.
Fix a syntax error one step at a time
If a formatter refuses the input, check the first reported location and the character immediately before it. A missing comma on one line can cause the parser to complain about the next line. Correct one issue, then validate again.
| Input fragment | Problem | Correction |
|---|---|---|
{item: "demo"} | Unquoted key | {"item": "demo"} |
{"count": 12,} | Trailing comma | {"count": 12} |
{"ready": True} | Incorrect boolean spelling | {"ready": true} |
Standard JSON does not accept comments or single-quoted strings. If an API returns an HTML error page, changing quote marks will not turn it into the expected JSON response: inspect the request status and source first. MDN explains the behavior and syntax errors of JSON.parse().
Readable does not always mean unchanged
The SLR TECH formatter uses JavaScript parsing and serialization. Very large integers may lose precision when converted to JavaScript numbers. Identifiers that must keep every digit should be represented as strings by the system that creates the data, where the receiving contract permits that. Do not silently change a numeric API field into a string just to make one tool accept it.
Consider an account identifier with more digits than a normal counter. Its purpose is identification, not arithmetic. Before running a large export through a formatter, test whether your actual identifier survives a round trip exactly. If it does not, use a workflow that preserves its original text representation.
Duplicate object keys are another reason to keep the source. A parse-and-serialize workflow can collapse repeated keys. Likewise, a formatter is not a byte-preserving editor: do not reformat a signed payload that depends on its exact original bytes.
Valid syntax is only the first check. A JSON document can parse successfully and still be missing a required field, use the wrong unit, or violate an API’s business rules. Use that API’s schema and documentation for those checks.
Before copying the result
- Keep the original response or file in a safe location.
- Remove secrets and personal data from examples used in web tools.
- Compare the important identifiers, values, array order, and value types.
- Check the expected schema or API contract separately.
- Use the JSON comparison tool for an additional review, while remembering that no comparison mode replaces knowledge of the data.
If the result is unexpected, send a minimal fictional example through our contact page. For markup documents, continue with our XML validation guide.