Code & data
Format JSON without changing the data you meant to keep
Make a JSON document readable while understanding duplicate keys, large numeric identifiers and the difference between syntax and schema.
Check syntax before changing the data
JSON uses quoted member names, double-quoted strings and a small set of value types. Comments, trailing commas and single-quoted strings are common reasons a pasted example is rejected. A JavaScript object written in source code is not automatically a valid JSON document.
When a document fails to format, compare it with the original response or file. Avoid deleting punctuation at random until the error disappears. You might turn an obvious syntax problem into a document that parses successfully but has the wrong fields or values.
Use indentation to expose the structure
Paste the document into KitForma’s JSON Formatter and choose two spaces, four spaces or tabs. Run the formatter and inspect arrays, nested objects and the relationships between fields. Keep the original until you have reviewed the output.
KitForma’s formatter changes whitespace outside strings while retaining number spellings, member order, duplicate keys and string escapes. Its minifier uses the same approach to remove formatting whitespace. Neither operation is intended to sort keys, redact secrets, translate field names or repair missing values.
Input: {"item":"notebook","quantity":2,"active":true}
Formatted:
{
"item": "notebook",
"quantity": 2,
"active": true
}Review identifiers and duplicate names
A long account or order identifier often belongs in a quoted string, even when it contains only digits. The formatter preserves the literal you supplied, but another application may parse a numeric value with less precision. Check the receiving system’s data contract before choosing a representation.
Duplicate member names are another review point. KitForma preserves them so formatting does not silently choose one for you. That is not an endorsement of duplicate keys: other parsers may handle them differently. Resolve the intended data structure at its source rather than relying on a formatted view to settle the ambiguity.
Check the application’s expectations separately
A syntactically valid document can still contain a missing customer name, an unexpected currency or a date in the wrong format. KitForma’s formatter does not validate an application-specific JSON Schema or contact an API to test whether the request will be accepted.
Use a small representative sample and review the required fields against your application’s documentation. For configuration changes, compare the before and after text and test the configuration in its intended environment. A neat indentation pattern cannot establish that a setting is safe or correct.
- Confirm that the top-level value is the object or array the application expects.
- Check important values and types after formatting.
- Run the receiving application’s own validation before using the document.
Keep the browser task manageable
Input is limited to 200,000 UTF-16 code units, and nesting is limited to 100 levels. Values outside the supported finite numeric range are rejected. For a very large response, obtain a smaller representative export rather than cutting through the middle of a JSON string or object.
The tool processes text locally, but copied output and downloaded files still need appropriate handling. Remove secrets before sharing an example with someone else. If your next step is CSV conversion, review that tool’s separate rules for nested values and numeric precision; successful formatting does not guarantee a lossless conversion to a table.
KITFORMA
Put it into practice
No account needed. Open an article, then try the matching tool.