How to Format JSON Before Sharing an API Example

A one-line API example makes it difficult to see which fields belong together. Indentation helps a teammate review an item list, locate a nested status, and copy a usable example into documentation. Prepare a small fictional payload first, then format it and check the result against the contract it is supposed to illustrate.

This workflow uses the JSON Formatter and Validator. It rebuilds JSON through JavaScript parsing and serialization; it is not a tool for preserving the exact original bytes.

Start with a fictional example and a clear contract

Imagine a workshop booking API whose documentation defines booking_id as a string, confirmed as a boolean, and seats as a number. The following invented response contains no customer records, credentials, or real booking details:

{"booking_id":"9007199254740993","confirmed":false,"items":[{"workshop":"Clay bowls","seats":2}],"note":"Bring an apron"}

Keep this original in a separate local file. Use invented values when preparing public documentation or a support example. Do not paste access tokens, private keys, or personal records into this exercise.

The quotation marks around the ID are intentional because this fictional contract expects a string. Do not change a real API’s numeric field to a string merely to make a formatter work; its documented field types still govern the example.

Format the payload with readable indentation

1. Open the formatter and paste the example into Paste your JSON.
2. Choose 2 spaces from Indent. Keep Minify and Sort keys alphabetically unchecked for this walkthrough.
3. Click Format JSON. Review the output below the controls rather than assuming the input has been replaced.
4. Check that the result matches the layout and values below. After completing the remaining checks, use Copy to copy the output.

{
  "booking_id": "9007199254740993",
  "confirmed": false,
  "items": [
    {
      "workshop": "Clay bowls",
      "seats": 2
    }
  ],
  "note": "Bring an apron"
}

Four spaces and tabs are also available if your project’s examples use those styles. JavaScript’s serialization function supports indentation through its spacing parameter, as described in MDN’s JSON.stringify reference. Pick one style for the document so nested objects are easy to follow.

Check types and meaning after the success message

The formatter’s success message means its JSON parser accepted the input. It does not confirm required fields, permitted status values, authorization, or whether an endpoint will accept the request. A schema check and an API test are separate steps.

For this example, verify the ID’s exact digits, the unquoted false, the array around items, and the numeric 2. Changing false to "false" produces a string: the document may still parse while violating the fictional contract. If parsing fails, use the guide to common JSON syntax errors before continuing.

Stop if exact numbers change

This tool uses JSON.parse, which can lose precision when converting large JSON numbers into JavaScript numbers. MDN explains this precision limitation. If an original numeric identifier or exact decimal changes, reject the output and use a workflow that preserves the required precision. A success message does not make that changed value acceptable.

Check repeated keys in the original

A repeated key can disappear during parsing and rebuilding. Inspect the original for repeated names within the same object; do not use the formatted result as proof that none existed. RFC 8259 recommends unique object names and describes differing receiver behavior when names repeat. Resolve ambiguous data at its source before sharing it.

Choose a display copy or an exact payload

Use the indented version for human review. If you also need compact JSON, enable Minify and click Format JSON again; keep the readable copy for the documentation. Minifying removes optional formatting whitespace, not spaces inside a string such as "Bring an apron".

Parsing and rebuilding can also change number notation, escape spelling, or member order. Preserve an untouched original when exact bytes matter, including a payload whose signature is checked against its raw body. Share the formatted copy as an illustration, with that distinction explained.

Check the example where readers will copy it

Paste the reviewed output into a code block marked as JSON in your documentation editor. Preview the published page, copy the rendered example back out, and confirm its field names, values, and types. Keep explanations outside the JSON block. Then test the example against the intended schema or endpoint using the appropriate test environment before describing it as a working integration.