JSON Formatter Online – Format & Validate JSON

How JSON Formatting Works

Formatting JSON is not a text find and replace operation. It is a full round trip: the formatter reads your input, parses it into an in-memory structure of objects, arrays, strings, numbers, booleans, and nulls, then serializes that structure back out to text while inserting line breaks and indentation at every structural boundary. In JavaScript the whole operation is two calls, one to parse and one to stringify with an indent argument.

const value = JSON.parse(input);
const pretty = JSON.stringify(value, null, 2);

That design has one consequence people run into constantly: invalid JSON cannot be formatted at all. If the parse step fails, there is no structure to serialize, so the formatter has nothing to indent. A missing comma or a stray single quote produces an error rather than a partly formatted result. This is why a formatter doubles as a syntax checker without trying to be one. If your text comes out formatted, it was valid. If it does not, fix the syntax first and format second.

The round trip also explains why the output is normalized rather than merely re-spaced. Whatever whitespace you had before is discarded entirely, so mixed indentation, stray blank lines, and inconsistent spacing after colons all disappear in one pass. Two files that describe the same data will come out byte identical after formatting with the same settings, which is exactly what you want when comparing responses from two environments.

Indentation Styles Compared

There is no single correct indent width. The three common choices each come from a different ecosystem, and each has a defensible argument behind it. Here is the same small product object rendered all three ways.

{
  "sku": "TR-4410",
  "price": 24.99,
  "tags": ["tripod", "photo"]
}

Two spaces is the default in the JavaScript world. It is what npm writes into package.json, what Prettier uses out of the box, and what most Node tooling emits. It keeps deeply nested payloads narrow enough to read without horizontal scrolling, which matters because API responses often nest five or six levels deep.

{
    "sku": "TR-4410",
    "price": 24.99,
    "tags": ["tripod", "photo"]
}

Four spaces is the norm in Python and Java projects, where the surrounding source code already uses four and consistency across the repository is worth more than compactness. Python's own json.dump call is frequently used with indent=4. The tradeoff is width: at six levels of nesting you are already 24 columns in before the key starts.

{
	"sku": "TR-4410",
	"price": 24.99,
	"tags": ["tripod", "photo"]
}

Tabs carry a genuine accessibility benefit that spaces cannot match. One tab character is a single logical indent, and every editor lets the reader choose how wide that renders. A developer with low vision can set tab width to eight, a colleague on a narrow laptop can set it to two, and both are reading the identical file. With spaces the author decides for everyone, permanently.

Key Ordering in JSON Objects

The JSON specification is explicit that an object is an unordered collection of name and value pairs. Two documents whose keys appear in different orders represent the same data, and no conforming consumer is allowed to behave differently based on the order it received.

In practice almost every parser you will meet preserves insertion order anyway. JavaScript objects iterate string keys in insertion order, Python dictionaries have guaranteed insertion order since 3.7, and most serializers write keys back out in the order they were read. So the order is stable even though it is not meaningful.

That gap between not meaningful and reliably preserved is what makes alphabetical key sorting useful. If a server builds its response by iterating a hash map, the same endpoint can emit keys in a different order on different runs. Sorting both documents before comparison removes that noise entirely, so a diff shows only the values that genuinely changed. The same applies to config files: sorted keys mean new entries always land in a predictable place instead of being appended to the bottom.

Formatting for Clean Git Diffs

Version control operates on lines. A JSON file stored on a single line is therefore a single unit as far as git is concerned, and changing one boolean rewrites the entire file from the diff tool's point of view. Reviewers see a wall of red and a wall of green and cannot tell what actually moved.

Formatting with one key per line fixes this completely. Change a single price and the diff is one removed line and one added line, reviewable in a second.

   "sku": "TR-4410",
-  "price": 24.99,
+  "price": 21.50,
   "tags": ["tripod", "photo"]

Two habits make this work well over time. First, pick one indent width per repository and never change it, because a reformat commit that touches every line destroys the blame history for that file. Second, keep short arrays of primitives on one line but break arrays of objects across lines, since an added object should read as an added block rather than an edited line.

Once your JSON is formatted, the JSON Validator will confirm the syntax and the JSON Minifier will strip it back down for transport. Browse the full collection of free JSON tools to find the right one for the job.