An API response arrives as one compressed line. The application reports Unexpected token, but the error does not tell you which property is broken. This is the moment when guessing is slow and formatting is useful.
The reliable workflow is simple: preserve the original payload, validate it, then format a corrected copy. Each step answers a different question and keeps you from accidentally changing evidence while debugging.
1. Preserve the raw response
Before editing anything, copy the response exactly as it arrived. Keep headers, status code, and content type nearby. A response that looks like JSON may actually be an HTML error page, a proxy message, or JSON preceded by logging text.
HTTP 502
content-type: text/html
<html>Gateway error</html>No formatter can repair a payload that was never JSON. Confirm that the first meaningful character is usually { or [ and that the server advertises an appropriate content type.
2. Validate before formatting
Paste the untouched payload into a JSON validator. Validation establishes whether the text follows JSON syntax. A parser error often points near the fault, even when the message is terse.
Consider this response:
{"status":"ok","user":{"id":42,"roles":["admin","editor",]}}The trailing comma after "editor" is legal in some programming languages but invalid in JSON. Other frequent problems include single-quoted strings, unescaped line breaks, missing commas, and comments.
| Symptom | Likely cause | First check |
|---|---|---|
Unexpected token near } | Trailing comma | Last property or array item |
| Unexpected end of input | Missing closing bracket | Nested objects and arrays |
Token < at position 0 | HTML response | Status code and content type |
| Bad control character | Unescaped newline or tab | Long string values |
3. Format the corrected payload
Once the syntax is valid, use the JSON formatter to reveal nesting. Indentation makes it much easier to spot a property at the wrong level, an array where an object was expected, or a null value that violates an application assumption.
{
"status": "ok",
"user": {
"id": 42,
"roles": ["admin", "editor"]
}
}Formatting changes whitespace, not values. That distinction matters: a formatter can make structure visible, but it cannot prove that a response matches your API contract.
Syntax validity is not schema validity
Valid JSON can still be wrong for an application. The server might return "42" where the client expects a number, omit a required property, or use an unfamiliar enum value. After syntax passes, compare the result with the API schema, TypeScript types, or a known-good response.
If you only have a representative sample, the JSON to TypeScript generator can create a useful draft. Review optional fields, nullability, dates, and arrays before treating generated interfaces as a contract.
A repeatable debugging checklist
- Save the raw status, headers, and body.
- Confirm the response is actually intended to be JSON.
- Validate the untouched body and note the parser position.
- Correct one syntax issue at a time.
- Format the valid result and inspect its hierarchy.
- Compare values and required fields with the real contract.
- Remove or redact secrets before sharing the payload.
The important habit is separating syntax, structure, and semantics. A formatter is excellent at the middle step, but the full workflow is what turns a vague error into a reproducible fix.