A JSON formatter is most useful when you know what you expect the data to contain. Indentation makes a response easier to inspect, but a neat result can still have a wrong value, a missing field or a number that changed during parsing. Work with a small, invented example first and keep an untouched copy of the source.

This walkthrough uses the BiNotePads JSON Formatter & Validator. The tool processes text in the browser using JavaScript parsing and serialization. The examples contain no live tokens or customer records. They are intended to show what you can check locally before sending a payload to its destination.

Begin with a compact object

{"title":"Handover notes","done":false,"items":["Save export","Check deadline"]}

Paste the object into Input and select Process. The output should place the members and array items on separate, indented lines. Find the title, the boolean value and both items. In this example the task is to make the structure readable, not to edit the underlying data.

Notice that false has no quotation marks. It is a boolean. The text "false" would be a string. An application may reject the string even though both versions are valid JSON. Also check that items is an array rather than a single sentence with commas in it.

Fix one syntax error at a time

The following example has a comma after the last member:

{"title":"Handover notes","done":false,}

Standard JSON does not permit that trailing comma. Remove it and process again. If the parser reports a location, look at nearby punctuation as well as the reported character: a missing quotation mark can make a later part of the input appear to be the problem. Browser error wording can vary.

Here is another malformed input:

{title: 'Handover notes'}

Use double quotation marks for both the member name and the string value: {"title":"Handover notes"}. A JavaScript object literal and a JSON document have related syntax, but they are not interchangeable. Do not paste code with variable names or function calls into a JSON field.

Comments are another frequent source of confusion. A line beginning with two slashes may be accepted by a configuration format that permits comments, but it is not standard JSON. Before deleting it, check the format your application actually expects. A JSON formatter should not be used to rewrite a different configuration language by guesswork.

Protect identifiers from numeric conversion

A code such as 0012 is an identifier, not an amount to add. Store it as a string:

{"code":"0012","quantity":3}

This keeps the leading zeros in the code while leaving quantity as a number. The same distinction applies to reference numbers and labels that happen to contain only digits. A valid numeric value does not preserve its original spelling after parsing and serialization; for example, unnecessary decimal zeros may disappear.

Very large integers need additional care. The current tool uses JavaScript numbers. Values beyond the safe integer range can lose precision when parsed, and formatting does not warn you about every such change. If the receiving API allows identifiers to be strings, keep them quoted. If it requires exact large numeric values, use an appropriate arbitrary-precision workflow instead of this browser formatter.

Check for repeated member names before formatting

A document can contain two members with the same name:

{"status":"planned","status":"finished"}

Do not rely on that input to retain both states. In this tool's JavaScript parse-and-serialize workflow, the later value survives. The pretty-printed output can therefore conceal the earlier value. Keep the original and inspect duplicate keys before treating the formatted result as a faithful archive.

The JSON standard, RFC 8259, describes the format and interoperability considerations, including member names and numeric limits. The practical lesson here is to use unique keys and to check how your receiving system represents values. Syntax success is only one part of a useful validation process.

Separate syntax validation from API validation

These two objects can both parse successfully:

{"quantity":3}
{"quantity":"three"}

Only one may satisfy your application's requirements. A formatter does not know whether quantity must be a positive integer, whether a title is required, or whether a particular user has permission to submit a record. Check the API documentation or schema for field names, types, allowed values and required members.

Use a short checklist after syntax passes: Are the required fields present? Are strings, numbers, booleans and arrays used in the right places? Are dates expressed in the expected timezone? Are identifiers intact? Does a blank value mean an empty string, null or an omitted field? Those choices can produce very different behavior in the receiving application.

Convert to CSV only for an appropriate table

The JSON to CSV Converter expects an array of records. A small flat list is easier to inspect than a nested object. After conversion, check headers and missing values. A spreadsheet can interpret a code such as 0012 as a number, so import the identifier column as text where needed.

If you go in the other direction using CSV to JSON, values are produced as strings. A quantity from a CSV row may therefore become "3", not 3. Plan any type conversion according to the destination's rules rather than assuming a round trip preserves every type.

Keep the checked source

Save the original, the corrected version and a note explaining a meaningful change. Use JSON Minifier only after you have checked the readable version. Reformatting is not a byte-preserving operation and is unsuitable for data whose exact bytes are signed or otherwise significant.

For confidential data, work in an approved local environment and use invented samples when requesting help. A useful formatter workflow ends with verified values and a clear record of changes. Indentation helps you read that record; it cannot decide what the data should mean.