JSON formatting: validate first, then organize
Make API responses, configuration snippets and JSON logs readable, and distinguish syntax errors from incorrect data.
When to use this tool
Use the JSON tool to inspect an API response, check a configuration file or reduce a text payload. Formatting adds indentation to objects and arrays; minifying removes unnecessary whitespace between structural elements; validation checks whether the text can be parsed as JSON. None of these modes checks business rules. A negative price, an impossible date or a missing required field can still appear in syntactically valid JSON.
From input to output
Keep a copy of the original, then paste the text into the input editor. Select Format and run the tool. Check whether the outermost value is an object or an array, then read the nested structure. Copy or download the result after checking its fields and values. Use Minify for a compact payload or Validate to check syntax. Do not overwrite your only copy of a configuration file.
For example, enter {"items":[{"name":"notebook","count":2}],"active":true}. Indentation makes it easier to see that items is an array, count is a number and active is a boolean. Changing count to "2" still passes syntax validation, but changes its type to a string.
Troubleshooting common errors
JSON requires double quotes around property names and strings. Single quotes, comments, undefined and trailing commas are not accepted. Check quotes, backslashes and brackets near the reported error, then check whether the preceding field is missing a comma. Text copied from a web page or messaging app may contain typographic quotes.
Newlines inside strings must be escaped, as must literal backslashes in file paths. Do not remove every quote to make an error disappear: that changes the data. If a log contains several separate JSON objects, extract and process them individually. Placing them next to one another does not make a single JSON document.
Number precision and duplicate keys
This tool uses the browser's JSON.parse and JSON.stringify functions. Integers outside JavaScript's safe integer range can lose precision. The data provider should supply long identifiers as strings when the receiving system expects them that way. When keys are repeated, parsing keeps the later value. Formatting is therefore not a lossless, character-for-character operation. Keep the original text and use a specialized parser if you need to audit duplicate fields, original number representations or signed content.
Privacy and result checks
Conversion runs in your current browser; the tool code does not upload your input. Refreshing the page clears the current input, so download results you need to keep. Avoid entering credentials, access tokens or customer data in an untrusted browser environment. Local processing does not control extensions or other users of a shared device. Before submitting output, check the field count, important values and the receiving system's requirements. Correct syntax is only the first step.
Try the tool
A worked example: from syntax to field checks
An illustrative order record
{"orderId":"9007199254740993","quantity":2,"paid":false,"items":["notebook","pen"]}Start with the type of each field: orderId is an identifier string, quantity is a number, paid is a boolean and items is an array. Formatting should preserve these types. Changing paid to the string "false" still passes JSON validation, but an API expecting a boolean may reject it.
Keep the original input, then separate troubleshooting into three levels. First, syntax: are brackets, quotes and commas correct? Second, structure: are required fields present, and are arrays and objects in the right places? Third, business rules: does the order identifier match a real record, is the quantity allowed, and does the payment status agree with the business system? Formatting mainly helps with the first level and makes the second easier to inspect. The third depends on your system's rules.
When extracting JSON from an error log, leave timestamps, severity labels and surrounding messages out of the input. Find the complete object or array boundaries before copying. If the response is actually an HTML error page, deleting characters until parsing succeeds discards useful diagnostic information. Check the response source and content type first.
Two problems that pass syntax validation
Duplicate keys replace earlier values
{"status":"pending","status":"paid"}The JavaScript parser used by this tool keeps the last status value. The output contains only paid. A tidy result does not prove that the original input contained just one status field. Compare against the original text when investigating duplicate keys; do not keep only the formatted result.
Large integers can lose precision during parsing
Numeric input: {"id":9007199254740993}
Serialized output: {"id":9007199254740992}
String input: {"id":"9007199254740993"}This integer is outside JavaScript's safe integer range and loses precision when parsed as an ordinary number. Passing it as a string preserves the identifier's digits, but must agree with the receiving API's contract. Do not add quotes to every numeric field. Converting the already-rounded value 9007199254740992 to a string later cannot recover the original number.
Compare this behavior with MDN's JSON.parse documentation and the ECMAScript parsing rules. This page describes the tool's ordinary parsing flow, not a specialized parser that preserves original number tokens.
Reduce an error to a reproducible example
- Copy the input into a separate text file and keep an unmodified version.
- Replace sensitive values with invented values such as invented-id or example-name. Preserve the original string, number and array types.
- Remove unrelated fields gradually. Run the tool after each change until the smallest remaining input still reproduces the problem.
- Record the mode, indentation option, observed error and expected output. Browser error wording can differ, so provide the input rather than only a screenshot of the message.
- Check that simplification has not removed the cause. If a backslash triggers the error, retain a form that reproduces the same escaping problem.
A minimal example also helps locate the failing step: before copying, during parsing, during serialization or after sending the result to an API. Each needs a different next action. Describing all of them as invalid JSON hides the distinction.
A checklist before handing off the result
- Did you save the original separately instead of overwriting it?
- Are complete identifier digits, leading zeros and letter case still correct?
- Do booleans, numbers and strings match the API's requirements?
- Are there duplicate keys or separate log records accidentally combined into one document?
- Is the copied or downloaded content complete, and has another tool added an extra layer of escaping?
For signature verification, original evidence or exact comparisons, preserve the original bytes. Indented JSON helps people read data; it does not prove that the original text is unchanged. Establish your precision and preservation requirements before choosing a processing method.