A JSON formatter is useful for much more than making a minified response easier to read. Used with a validator and a careful debugging process, it can help you find syntax errors, inspect nested API data, compare payloads, and separate malformed JSON from application-level problems. This guide explains how to format JSON online or locally, validate it safely, troubleshoot common errors, and decide when a browser-based tool is appropriate.
Overview
JSON, or JavaScript Object Notation, is a text format commonly used to exchange structured data between browsers, APIs, services, command-line tools, and cloud applications. Its basic building blocks are objects, arrays, strings, numbers, booleans, and the null value. A valid document must follow JSON syntax precisely, even when the underlying data seems obvious to a person.
When an API response is compressed onto one line, a JSON formatter or pretty printer adds indentation and line breaks. This makes the structure visible without changing the intended data. A JSON validator goes a step further by checking whether the text can be parsed as JSON and, in some tools, identifying the approximate location of a syntax error.
Formatting and validation answer different questions:
- Formatting: Can the data be displayed in a readable structure?
- Syntax validation: Can a JSON parser read the document?
- Schema validation: Does the document contain the required fields and data types for a particular API contract?
- Application debugging: Does the response represent the result your code was supposed to produce?
A formatter usually handles the first two tasks. It does not automatically confirm that a customer ID is valid, that a status value is allowed, or that a response follows your service's schema. Keeping these levels separate prevents a visually tidy payload from creating false confidence.
Core framework
1. Preserve the original response
Before you format or edit a payload, save the raw response. Keep the HTTP status, response headers, request parameters, and timestamp when they matter to the investigation. A formatted copy is easier to inspect, but the original helps you prove whether a later change came from the server, a proxy, a browser extension, or manual editing.
For repeatable debugging, capture the request and response in an API client, browser developer tools, or a local command-line workflow. Avoid copying only the visible portion of a large response; truncation can hide the field or bracket that causes the problem.
2. Format before you interpret
Paste the response into a trusted JSON formatter, then inspect the resulting hierarchy from the outside in. Start with the top-level value. Is it an object surrounded by {}, or an array surrounded by []? From there, identify the fields that contain nested objects or arrays.
Readable indentation makes several issues easier to spot:
- An array that closes before all expected items appear
- A field whose value is an object rather than a string
- Unexpected nesting, such as
data.data.items - Duplicate keys that may be handled inconsistently by different parsers
- Very large strings, embedded markup, or escaped characters
Do not treat indentation as a data transformation. A reliable formatter should preserve values while changing presentation. If you use a tool that sorts keys, removes fields, converts types, or applies other transformations, check its options before using the output in tests or documentation.
3. Validate syntax, then validate meaning
When a formatter reports an error, read the location carefully, but remember that the parser may identify the point where it became impossible to continue rather than the original mistake. Inspect the preceding line first. A missing comma, unmatched quote, or extra closing bracket is often just before the reported position.
After syntax validation succeeds, apply the rules of the API or application. For example, valid JSON can still be unusable when userId is missing, quantity is a string instead of a number, or createdAt uses a timestamp format your service does not accept. Schema tools, typed models, contract tests, and application-level assertions are better suited to these checks.
4. Compare structures rather than text alone
Two JSON documents can contain the same information in a different key order or with different whitespace. A plain text diff may report many changes that do not affect meaning. For meaningful comparisons, use a structural comparison when available. Decide whether key order, array order, missing fields, extra fields, and data type changes should count as differences.
For production investigations, redact secrets before sharing a payload with an online developer tool or another person. Access tokens, cookies, personal data, payment details, internal hostnames, and confidential business fields may appear in API responses even when they are not relevant to the bug. When possible, use synthetic fixtures or a local formatter for sensitive material. For a broader set of safe debugging practices, see this practical toolkit for online developer tools.
Practical examples
Formatting a minified response
Suppose an endpoint returns this compact payload:
{"ok":true,"data":{"items":[{"id":17,"name":"Notebook","tags":["blue","lined"]}],"nextPage":null}}A pretty printer can display it as:
{
"ok": true,
"data": {
"items": [
{
"id": 17,
"name": "Notebook",
"tags": [
"blue",
"lined"
]
}
],
"nextPage": null
}
}The formatted version makes the response shape clear: items is an array inside data, and nextPage is explicitly null rather than absent. That distinction can matter to frontend code that checks whether a property exists.
Finding a syntax error
This example is invalid:
{
"name": "Notebook"
"quantity": 2
}The comma after the name value is missing. A validator may point to the quantity line because that is where the parser encounters an unexpected string. When a JSON syntax checker highlights a location, inspect the nearby punctuation as well as the highlighted character.
Other frequent corrections include changing single quotes to double quotes, removing trailing commas, escaping a quote inside a string, and closing every object and array. JSON does not allow JavaScript comments, undefined, or unquoted property names.
Distinguishing JSON from a JWT
A decoded JSON object may appear inside a JSON Web Token, but a JWT is not simply a JSON document. JWTs have encoded sections and require separate handling for decoding, signature verification, claims, and expiration. Do not paste an access token into a general formatter unless you have removed or replaced it. For a focused workflow, use the JWT decoder and validation guide.
Checking an API response systematically
- Confirm the HTTP status and content type.
- Save the raw response.
- Format and syntax-check the body.
- Inspect the top-level structure and required fields.
- Compare the result with the API contract or expected schema.
- Check server logs and request inputs if the structure is valid but the result is wrong.
- Record a redacted, reproducible example for a test or bug report.
Common mistakes
Assuming valid JSON means a successful request
An error response can be perfectly valid JSON. Always check the status code and documented error fields before treating a parseable response as a successful result.
Editing the formatted output without tracking changes
It is easy to fix a comma manually and then forget that the edited document is no longer the server response. Label corrected examples as fixtures or proposed payloads, and keep them separate from captured evidence.
Ignoring content types and encodings
Some failures occur before parsing because the response is HTML, plain text, compressed incorrectly, or encoded unexpectedly. If a formatter rejects the input, first inspect the response headers and the first characters of the body. A server error page returned to an API client is not a malformed JSON object; it is a different response format.
Sharing secrets during debugging
Redaction should happen before a value reaches a chat, ticket, paste service, or online tool. Replace sensitive values with realistic placeholders while preserving the same data types and general structure. If a token or credential was exposed, follow your organization's incident process rather than assuming that deleting the pasted text solves the problem.
Using a formatter as a schema tool
Formatting cannot tell you whether a field is required, whether an identifier belongs to the right account, or whether a date is semantically correct. Pair syntax checks with schema validation and tests that reflect the service contract.
When to revisit
Revisit this workflow whenever an API changes its response shape, a service adds versioned endpoints, a parser or formatter changes behavior, or a new data-safety requirement affects where payloads may be processed. It is also worth reviewing after a recurring incident: repeated parsing failures often indicate that a contract test, response fixture, or logging practice needs improvement.
For a practical maintenance routine, keep a small set of redacted JSON fixtures covering successful responses, empty results, pagination, validation errors, and server errors. Run them through your chosen parser and schema checks when dependencies or API contracts change. Update team documentation with the expected top-level shape and examples of nullable, optional, and required fields.
For everyday work, use this checklist: preserve the raw response, format a copy, validate syntax, inspect the schema, compare structures, redact sensitive data, and document the smallest reproducible example. A JSON formatter is a quick developer utility, but it becomes much more valuable when it is part of a disciplined API debugging workflow. If you are building a broader local setup, this guide to a fast local API debugging toolkit can help connect formatting with repeatable tests and logs.
