When an API response is difficult to read or fails to parse, a JSON formatter and validator can quickly separate a syntax problem from an application problem. This guide provides a repeatable workflow for formatting JSON online, locating errors, inspecting nested data, handling escaped strings, and sharing output without exposing sensitive values.
Overview
JSON is designed for machines, but raw API responses are not always comfortable for people to inspect. A response may arrive as one long line, contain several levels of nested objects, or include a string that itself contains escaped JSON. A missing comma, an extra bracket, or an unquoted property name can make the entire document invalid.
A browser-based JSON formatter online is useful for the first pass: paste the response, validate its syntax, and pretty-print it with indentation. A validator tells you whether the document follows JSON syntax, while an editor or command-line tool is better suited to repeatable checks in a codebase or deployment workflow. Formatting improves readability; it does not repair incorrect data or prove that an API returned the values your application expects.
| Tool type | Best use | Check before using |
|---|---|---|
| Browser-based formatter | Quickly format JSON and inspect a response | Remove secrets and confirm how the tool handles pasted data |
| JSON validator | Find syntax errors in a payload or fixture | Read the reported line and column against the original text |
| Code editor | Review JSON alongside application code | Check the file encoding, schema support, and formatting settings |
| Command-line utility | Automate formatting and validation in repeatable workflows | Confirm the command fails clearly when input is invalid |
Use the least complicated option that matches the task. For a one-time inspection, an online JSON formatter may be enough. For fixtures, configuration files, or CI checks, keep validation close to the project and make the result reproducible.
Checklist by scenario
When an API response is hard to read
- Copy the response exactly as received, including braces, brackets, quotation marks, and escaped characters.
- Remove or replace credentials, session tokens, personal information, internal URLs, and other values that should not be shared.
- Paste the sanitized text into a JSON validator or formatter.
- Choose pretty-printing rather than minification so objects and arrays are visually separated.
- Expand the top-level object first, then follow the path to the field your application uses.
- Compare the actual field name and data type with the code that reads it.
"id","ID", and"user_id"are different keys.
When validation reports a syntax error
- Start at the reported line and column, but inspect the character immediately before the location as well. The parser often notices a problem only after the original mistake.
- Check that every object uses double-quoted property names and that every string is enclosed with matching double quotes.
- Look for missing commas between properties or array items. Do not add a comma after the final item.
- Match every opening brace with a closing brace and every opening bracket with a closing bracket.
- Replace JavaScript-only values such as
undefined,NaN, comments, or trailing commas if the document must be strict JSON. - Validate again after each small correction rather than changing many unrelated lines at once.
When a field contains escaped JSON
An API may return JSON inside a string, for example {"payload":"{'status':'ok'}"}. The outer document can be valid even though the inner value is still escaped. First validate and format the outer object. Then copy the decoded value of the relevant string into a second formatter. Treat the two layers separately; adding or removing backslashes in the wrong layer can corrupt the payload.
When comparing two response versions
- Format both responses with the same indentation and ordering rules.
- Compare status codes, top-level keys, nested objects, arrays, and data types.
- Distinguish a missing key from a key whose value is
null, an empty string, or an empty array. - Check whether array order is meaningful before treating a reordering as a functional change.
- Record the request method, endpoint, relevant parameters, and response status separately from the JSON body.
When preparing JSON for documentation or a bug report
Keep a minimal reproducible example. Include only the fields needed to demonstrate the issue, replace sensitive values with clearly labeled placeholders, and preserve the data types that matter. A placeholder such as "example-token" should remain a string; replacing it with an unquoted word would introduce a new syntax error.
What to double-check
Syntax versus schema
Valid JSON only means the text can be parsed as JSON. It does not confirm that required fields exist, values fall within an allowed range, or an endpoint returned the expected schema. If an application still fails after formatting, inspect the API contract, response status, authentication, content type, and code path that consumes the data.
Content type and transport
Check whether the server actually returned JSON. An error page, proxy message, login screen, or plain-text stack trace may be labeled incorrectly or passed to code that expects JSON. Inspect the HTTP status and response headers before assuming that a parsing failure is caused by the body itself.
Numbers, nulls, and types
JSON distinguishes strings, numbers, booleans, objects, arrays, and null. A value that looks numeric but is quoted is a string. A missing property is not the same as a property set to null. These differences can affect comparisons, validation, rendering, and database operations.
Privacy and operational safety
Do not paste production secrets into an unfamiliar browser tool. Before sharing formatted output, search for authorization headers, cookies, API keys, access tokens, email addresses, customer identifiers, private hostnames, and request signatures. Redaction should be deliberate: preserve the shape and type of the value while replacing the secret itself.
For related troubleshooting, see the JWT decoder guide when a response includes a token, and the URL encoder and decoder guide when query parameters or encoded values are involved.
Common mistakes
- Confusing JavaScript with JSON: JSON does not allow comments, single-quoted strings, unquoted keys, or arbitrary expressions.
- Fixing only the displayed line: A missing quote or comma earlier in the document may cause the validator to flag a later position.
- Minifying too early: One-line JSON is harder to inspect while debugging. Pretty-print first and minify only when a consuming system requires it.
- Assuming formatting changes meaning: Indentation changes presentation, not the underlying values. A formatter cannot correct an incorrect endpoint or business rule.
- Ignoring the outer response: Some clients return a wrapper containing status information and a nested data object. Confirm the path before changing application code.
- Sharing raw production output: Sanitization is part of the debugging process, not an optional final step.
- Testing only a successful example: Also inspect empty arrays, null values, validation errors, pagination, and partial responses if those cases affect the integration.
If the problem is not JSON syntax, move to the next layer of the workflow. A regular expression may help locate a recurring text pattern, while a hash tool can verify whether a downloaded payload changed. Use each developer tool for the question it can actually answer.
When to revisit
Return to this checklist whenever an API, webhook, fixture, or configuration workflow changes. It is especially useful before a release, after an endpoint version change, when a third-party integration changes its response shape, or when a previously reliable parser begins failing.
- Capture a representative response and sanitize it.
- Validate the exact payload rather than a manually retyped example.
- Format it and record the path, type, and presence of fields the application depends on.
- Test both normal and failure responses.
- Move recurring checks into an editor, test suite, or command-line workflow so they can be repeated consistently.
- Review the chosen browser-based tool whenever its handling, supported syntax, or privacy assumptions are unclear.
For a broader API and web security workflow, pair JSON inspection with the Content Security Policy guide, and review domain or deployment changes with the DNS records guide. A formatted response is a useful starting point, but reliable debugging comes from validating the payload, its transport, its schema, and the code that consumes it.
