JSON Formatter and Validator
Paste JSON to format, validate, minify, and inspect API responses, logs, configuration snippets, and documentation examples.
- Format nested objects and arrays into readable indentation.
- Validate strict JSON syntax before sharing samples or config files.
- Minify JSON for compact API, documentation, and copy workflows.
Static fallback example
The live JSON Formatter workbench runs in the browser. If it does not load, use this static example to confirm the expected input and output pattern, then enable JavaScript or reload the page to run the tool.
This fallback shows the expected JSON review pattern only. The browser workbench performs the actual parse, indentation, minify, and copy actions after JavaScript loads.
About this tool
The JSON Formatter helps developers inspect API responses, logs, configuration snippets, and pasted JSON samples without changing the source data. It is designed for strict JSON, so JavaScript object literals, comments, JSONP wrappers, and copied HTML error pages should be treated as separate input problems.
When this tool is useful
Use it when an API response is hard to read, when a configuration file needs consistent indentation, or when a JSON sample must be checked before it is shared in documentation, issue reports, or test fixtures.
The formatter keeps valid values intact. It changes whitespace for readability or removes whitespace for compact output after the input parses as strict JSON.
Input and output example
Input: {"status":"ok","items":[{"id":1,"name":"sample"}]}
Formatted output uses nested indentation so object keys, arrays, and values can be reviewed line by line.
Common validation errors
Strict JSON does not allow trailing commas, comments, single-quoted strings, or unquoted object keys.
If pasted API output fails validation, confirm that the response is not an HTML error page, JSONP wrapper, or log prefix.
Privacy boundary
Do not paste passwords, production tokens, private keys, customer records, or confidential payloads into browser tools unless your own security process allows it.
Before copying the result
Review the JSON Formatter and Validator output against the original input and the reason you opened the page. Format, validate, minify, and copy JSON. Paste JSON to get readable output, syntax errors, or compact JSON for APIs and config files.
For JSON, compare the formatted tree with the original payload, then verify object keys, array positions, data types, escaped characters, and whether the source was a true JSON response rather than an HTML error page or log wrapper.
FAQ
Does formatting change the JSON values?
No. Formatting changes whitespace only after the input has parsed as valid JSON.
Why does valid JavaScript object syntax fail?
JSON is stricter than JavaScript object literals. Keys and string values need double quotes, and comments are not valid JSON.
Quick diagnostic path for JSON parse errors
Most JSON formatter failures come from copying the wrong boundary around the payload. Before assuming the data is broken, identify what kind of text reached the tool.
| Input pattern | Likely issue | Next check |
|---|---|---|
<!doctype html> or <html> | The response is an HTML error, login, or proxy page. | Check status code, authentication, and Content-Type. |
callback({...}) | The sample is JSONP, not raw JSON. | Remove the wrapper only if the source contract really returns JSONP. |
{status: "ok"} | The sample is a JavaScript object literal. | Quote property names and remove JS-only syntax. |
{"id":10000000000000001} | A large identifier may lose precision in JavaScript-based workflows. | Keep large IDs as strings when exact identity matters. |
Operational FAQ
Does the formatter reorder object keys?
Treat the tool as a whitespace, minify, and validation helper. Do not depend on object key order for semantic meaning; compare field presence and values instead.
Can I paste secrets?
Avoid pasting access tokens, session cookies, credentials, customer records, and private payloads unless your own security process explicitly permits that browser-side workflow.
JSON review workflow for API responses, logs, and configuration files
A JSON formatter is most valuable when it helps you find structural mistakes before a payload is copied into documentation, configuration, test fixtures, or an incident report. The useful output is not only indentation; it is a reviewed object tree with known field names, value types, nullable fields, array shapes, and escape sequences.
Treat this page as the first pass in a JSON review. It can tell you whether strict JSON parses and can make nested data readable. It cannot decide whether a field is semantically correct for your API contract, whether a number has already lost precision upstream, or whether a redacted sample still contains private identifiers.
Use the tool as a review workflow
- Paste the smallest non-sensitive sample that still shows the problem. For a failed API call, copy the response body, not the browser console prefix or a server log timestamp.
- Validate before formatting. JSON must use double-quoted property names and strings, no trailing commas, no comments, and no JavaScript-only values such as undefined or NaN.
- After formatting, inspect the outer shape first: top-level object versus array, required keys, pagination fields, error objects, and nested list lengths.
- Check value types deliberately. IDs, timestamps, booleans, nullable values, and numeric strings often look correct in a pretty view while still being wrong for the consumer.
- Use minify only after the readable version is accepted. Compact JSON is useful for transport or fixtures, but it is a poor review format.
Three practical examples
| Scenario | Sample input | What to check before copying |
|---|---|---|
| API response triage | {"status":"ok","items":[{"id":"10000000000000001","active":true}],"next":null} | Confirm that the large ID is a string, not a rounded number, and that the next field is intentionally null. |
| Configuration snippet | {"featureFlags":{"checkoutV2":false},"retry":{"count":3,"delayMs":250}} | Verify booleans and millisecond units before copying into a config file or deployment note. |
| Invalid JavaScript literal | {status: "ok", items: [1,2,], // copied from code} | This is not JSON. Quote keys, remove comments, and remove the trailing comma before using it as a JSON sample. |
Common error table
| Symptom | Likely cause | How to confirm | Practical fix |
|---|---|---|---|
| Unexpected token } or ] | A trailing comma after the last property or array item. | Look at the character immediately before the closing brace or bracket. | Remove the final comma and revalidate. |
| Unexpected token s or another letter | Unquoted object key, JSONP wrapper, or log prefix was copied with the body. | The first invalid token appears where a double quote or opening brace was expected. | Copy only the JSON body and quote every property name. |
| Unexpected token < | The pasted text is an HTML error page, proxy response, or login page. | The payload starts with an HTML tag or doctype. | Check the HTTP status, authentication, and response content type before formatting. |
| Large ID changes after processing | Another tool or runtime converted a large integer into a floating-point number. | Compare the exact ID with the raw source before it entered JavaScript. | Represent large identifiers as strings in examples and API contracts. |
| Line breaks inside a string fail | A raw newline was pasted into a JSON string. | The break appears between opening and closing quotes. | Escape it as \n or use an array of strings if the data model allows it. |
Security and privacy boundary
JSON payloads often contain more sensitive data than they appear to contain because nested arrays hide customer records, tokens, account IDs, or internal URLs. Use a sanitized sample whenever possible.
- Do not paste OAuth tokens, session cookies, API keys, private URLs, or production credentials.
- Replace customer names, email addresses, order IDs, and account IDs with stable placeholders before sharing a formatted sample.
- Keep the original raw payload only in your approved project system, not in screenshots or public tickets.
- When reviewing incident data, preserve enough structure to debug the issue while removing private field values.
Technical reference notes
The behavior expected from a strict JSON page should align with the JavaScript JSON APIs and the JSON grammar, but the page remains a review helper rather than a replacement for contract tests.
- MDN JSON.parse() — strict parsing and reviver behavior
- MDN JSON.stringify() — serialization behavior, replacer, and spacing options
- JSON format guide — local guide for formatting and validation decisions
Copy result checklist
- Confirm the pasted sample is valid strict JSON, not a JavaScript object literal.
- Compare the top-level shape with the expected API or config contract.
- Check strings versus numbers for identifiers, timestamps, currency, and version fields.
- Confirm null, empty string, empty array, and missing field are not being treated as the same thing.
- Remove private values before using the formatted output in documentation, tickets, or examples.
- Keep a raw sample and the reviewed formatted output together when the result supports a production change.
Related guides for deeper review
Editorial update: 2026-06-07. This JSON page was reviewed for single-page SEO, task intent, schema consistency, strict syntax examples, privacy boundaries, and copy-review guidance.
See Ymir Tool editorial, testing, and review methods for how this page is maintained.