JSON VIEW PARSER

Formatting, Beautifying and Pretty Printing Are the Same Thing

Before anything else, one piece of vocabulary worth clearing up, because it causes real confusion: formatting, beautifying and pretty printing JSON all describe one operation — inserting whitespace so a document's structure becomes visible. There is no technical difference between them.

The three names are historical accidents. "Pretty printing" is the oldest, borrowed from compiler and Lisp literature where it meant rendering a syntax tree back into readable source. "Beautify" arrived through web tooling in the 2000s. "Format" is what most editors and language standard libraries call it today. If a tutorial tells you to beautify your JSON and your library only offers a format function, you already have what you need.

What Formatting Actually Changes

JSON's grammar treats whitespace between tokens as insignificant. Spaces, tabs, carriage returns and newlines that sit outside of string values carry no meaning, so a parser discards them. That single fact is what makes formatting safe: you can add or remove as much whitespace as you like and the parsed result is identical.

A raw API response typically arrives with none of it:

{"status":"success","data":{"id":101,"user":"dev_user","active":true,"roles":["admin","editor"],"profile":{"city":"Chennai","timezone":"Asia/Kolkata"}}}

Formatted at two spaces, the same document becomes navigable:

{
  "status": "success",
  "data": {
    "id": 101,
    "user": "dev_user",
    "active": true,
    "roles": [
      "admin",
      "editor"
    ],
    "profile": {
      "city": "Chennai",
      "timezone": "Asia/Kolkata"
    }
  }
}

Both blocks parse to exactly the same value. Nothing was added, removed or renamed — only the whitespace differs. This is why formatting is a safe operation to run on data you do not fully understand yet.

Why It Is Worth Doing

• Hierarchy becomes visible. Indentation is the only cue that tells you timezone belongs to profile and not to data. In a single-line document that relationship is invisible.
• Structural errors surface. A misplaced closing brace produces indentation that suddenly jumps in the wrong direction. Your eye catches that far faster than it counts brackets.
• Diffs become meaningful. A one-line JSON file changes entirely when one value changes, so version control shows the whole line as modified. A formatted file produces a diff of one or two lines, which is reviewable.
• Paths become quotable. Once the shape is visible you can write data.profile.city with confidence instead of guessing at nesting depth.
• Learning is faster. If you are still internalising JSON's rules, formatted output shows you where commas do and do not go far more effectively than prose does.

Choosing an Indentation Width

JSON's specification says nothing about indentation, so this is purely a convention question. In practice three options are in circulation:

There is no correct answer, and the choice has no effect on how the data behaves. What does matter is consistency: a repository where some JSON files use two spaces and others use four produces noisy diffs every time a developer's editor reformats on save. Pick one, put it in your .editorconfig or Prettier config, and stop thinking about it.

Formatting With This Tool

The formatter on this site runs entirely in your browser. Nothing is uploaded, which means you can safely paste responses containing customer data or internal identifiers.

1. Paste your JSON into the input panel on the left. Minified, partially formatted or inconsistently indented input all work.
2. Choose a width. The input toolbar has dedicated buttons for 2-space and 4-space indentation, which rewrite the input in place.
3. Read the result in the Pretty Print tab, or switch to the Tree tab to collapse and expand nodes instead.
4. Filter if the document is large. The search box above the output filters both the formatted view and the tree.
5. Copy or download the result as a .json file once it looks right.

Keyboard shortcuts, if you prefer not to reach for the mouse:

Formatting JSON in Code

An online tool is the fastest option for a one-off inspection, but inside an application you will want to format programmatically — when writing a config file, logging a request body, or generating a fixture. Every mainstream language ships this in its standard library.

JavaScript and TypeScript

JSON.stringify takes an indentation argument as its third parameter. The second parameter is a replacer, which you rarely need — pass null.

const data = { name: "Alice", roles: ["admin"], active: true };

// Third argument: number of spaces, or a string to indent with
JSON.stringify(data, null, 2);      // two spaces
JSON.stringify(data, null, 4);      // four spaces
JSON.stringify(data, null, "\t");   // tabs

// Re-formatting a JSON string means parsing it first
const pretty = JSON.stringify(JSON.parse(rawText), null, 2);

Python

json.dumps uses an indent keyword. sort_keys is worth knowing about: it produces deterministic output, which makes generated files diff cleanly.

import json

data = {"name": "Alice", "roles": ["admin"], "active": True}

print(json.dumps(data, indent=2))
print(json.dumps(data, indent=4, sort_keys=True))

# Preserve non-ASCII characters instead of escaping them
print(json.dumps({"city": "Chennai"}, indent=2, ensure_ascii=False))

PHP

$data = ["name" => "Alice", "roles" => ["admin"]];

echo json_encode($data, JSON_PRETTY_PRINT);

// Usually combined, to stop slashes and unicode being escaped
echo json_encode($data, JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE);

Java

// Jackson
ObjectMapper mapper = new ObjectMapper();
String pretty = mapper.writerWithDefaultPrettyPrinter().writeValueAsString(data);

// Gson
Gson gson = new GsonBuilder().setPrettyPrinting().create();
String pretty = gson.toJson(data);

Go

Go offers MarshalIndent for values you hold, and Indent for re-formatting bytes you already have.

// From a value
out, err := json.MarshalIndent(user, "", "  ")

// Re-indent an existing JSON byte slice
var buf bytes.Buffer
err := json.Indent(&buf, rawBytes, "", "  ")

Command line

For piping API responses around a terminal, jq is the usual choice. If it is not installed, Python's built-in module does the job with no extra dependency.

# jq pretty prints by default
curl -s https://api.example.com/users | jq

# Explicit indent width
curl -s https://api.example.com/users | jq --indent 4

# No jq installed? Python ships a formatter
curl -s https://api.example.com/users | python3 -m json.tool

# Format a file in place with jq
jq . data.json > tmp && mv tmp data.json

Formatting Versus Minification

Minification is the same operation in reverse: strip every insignificant byte of whitespace to make the document as small as possible. The two are complementary rather than competing, and most workflows use both at different stages.

One caveat worth knowing: if your responses are already served with gzip or Brotli compression — as most are — the bandwidth saving from minification is much smaller than the raw byte difference suggests, because compression algorithms handle repetitive whitespace extremely well. Minify because it is free, not because you expect dramatic gains. See the JSON minifier guide for the details.

Things Formatting Will Not Do

A formatter is a narrow tool, and knowing its limits saves time when something looks wrong:

• It will not fix invalid JSON. Formatting requires a successful parse, so a trailing comma or unquoted key must be corrected first. If the formatter refuses, you have a syntax problem — the common JSON errors guide covers the usual culprits.
• It will not validate your structure. Syntactically perfect JSON can still be missing a required field or carry a string where a number belongs. That is JSON Schema's job.
• It will not preserve comments. Standard JSON has no comment syntax, so anything resembling one is a parse error to begin with. If you need comments in a config file, JSON5 or YAML is the better format.
• It will not guarantee key order. Objects are unordered by specification. Most implementations preserve insertion order in practice, but nothing requires them to, so never write code that depends on it.
• It will not help much past a certain size. Beyond a few megabytes, formatted output becomes too long to scroll usefully. At that point a collapsible tree view or a query tool like jq is the better instrument.

Frequently Asked Questions