JSON Formatter & Beautifier

What this tool does

Takes minified or raw JSON and produces beautified output with configurable indentation (2 spaces, 4 spaces, or tabs). Optional features include sorting keys alphabetically and escaping non-ASCII characters to \uXXXX sequences. The output is valid JSON that any parser can read.

Example

Input (minified):

{"status":"ok","data":{"users":[{"id":1,"name":"Alice"},{"id":2,"name":"Bob"}],"total":2}}

Output (2-space indent):

{
  "status": "ok",
  "data": {
    "users": [
      { "id": 1, "name": "Alice" },
      { "id": 2, "name": "Bob" }
    ],
    "total": 2
  }
}

Options

Formatting API responses for debugging

When you fetch data from a REST or GraphQL API, the response body is usually minified to save bandwidth. A single-line blob with no spaces is efficient on the wire but impossible to read. Pasting it into the formatter makes the structure visible immediately.

Consider a paginated users endpoint that returns the following minified payload:

{"page":1,"per_page":3,"total":128,"pages":43,"users":[{"id":42,"name":"Alice","email":"alice@example.com","roles":["admin","editor"],"last_login":"2026-09-10T14:22:01Z"},{"id":43,"name":"Bob","email":"bob@example.com","roles":["viewer"],"last_login":"2026-08-30T09:15:44Z"},{"id":44,"name":"Carol","email":"carol@example.com","roles":["editor","viewer"],"last_login":null}]}

After formatting with 2-space indentation you can see the pagination envelope at the top level, the users array as a distinct block, and each user’s fields aligned vertically. When a bug report says the third user is missing roles, formatted output lets you scan to index 2 and inspect the roles array without scrolling horizontally. If the API also returns unexpected fields or nulls where you expected strings, the aligned columns make those anomalies obvious within seconds.

For responses wrapped in a top-level envelope — a common pattern with meta, data, and errors siblings — formatting separates each section onto its own lines so you can check whether errors populated alongside data, which is a frequent source of silent failures in client code.

Formatting package.json

A package.json file accumulates entries over time: dependencies, devDependencies, scripts, config blocks. When several properties sit on compressed lines, spotting a duplicate dependency or checking a version range means reading carefully. Formatting puts each property and each dependency on its own line.

Take this compact scripts block:

{"scripts":{"build":"tsc","test":"vitest","lint":"eslint src","dev":"vite"},"dependencies":{"express":"4.18.2","cors":"2.8.5"},"devDependencies":{"typescript":"5.3.0","vitest":"1.0.0"}}

Formatted, every script and dependency gets its own line. Enabling sort keys alphabetizes the dependencies so express and cors sit next to each other instead of appearing in insertion order. This helps before a code review: reviewers can scan the sorted list, spot an unexpected package, and verify the version without hunting through a long unsorted block.

Formatting package.json is also useful when trimming unused dependencies. With each package on its own line you can tick them off against your import statements more quickly than when they are packed into a single line. Note that JSON formatting does not sort arrays like the scripts entry — only object keys are reordered when sort keys is enabled.

Formatting vs minifying vs validating

These three operations solve different problems and you should pick the right one for the task.

Formatting adds whitespace — indentation, newlines, spaces around structural punctuation — so a human can read and edit the data. Use it when you are debugging an API response, reviewing a config file, or hand-editing a manifest. The output is larger than the input but far easier to work with.

Minifying does the reverse: it strips every optional whitespace character to produce the smallest valid byte sequence. Use it before serving JSON over HTTP, embedding it in a bundle, or storing it where disk or memory footprint matters. Minified JSON is harder to read but faster to transmit. This tool does not minify — its purpose is readability, not compression.

Validating checks whether a string is syntactically correct JSON without producing transformed output. Use it when a downstream parser throws a cryptic error and you need to find the offending token. This tool validates incidentally: it calls JSON.parse on your input, and if parsing fails the error message — including the line and column where the parser stopped — is displayed. So formatting and validating happen together: valid input gets beautified, invalid input gets an error.

Common mistakes when formatting

• Using single-quoted strings. JSON requires double quotes around every string and every key. Single quotes are valid in JavaScript but produce a parse error in JSON.
• Leaving trailing commas. A comma after the last element in an array or the last property in an object is a syntax error. Unlike JavaScript, JSON does not allow trailing commas.
• Pasting JavaScript object literals. Unquoted keys, functions, undefined, and comments are all legal in JS objects but invalid in JSON. Convert them first or fix the source.
• Expecting formatting to repair broken data. If the input has a syntax error the formatter cannot guess your intent. It reports the error location instead of producing partial output.
• Assuming NaN, Infinity, or undefined are valid. The JSON specification only permits null, true, false, numbers, strings, arrays, and objects. NaN and Infinity are not valid JSON even though some serializers accept them.
• Ignoring number format rules. JSON allows integers, decimals, negative values, and scientific notation like 1e3. Leading zeros (except for 0 itself) are not valid. Hexadecimal literals like 0xFF are not valid JSON numbers.
• Confusing key order with meaning. Standard JSON objects are unordered mappings. Sorting keys changes the byte sequence but not the data. Two objects with identical content but different key order are semantically equal.
• Forgetting that formatting normalizes mixed indentation. If the input was hand-edited with inconsistent spacing, the formatter replaces it with your chosen style. The original indentation is lost, which is usually desirable but worth knowing if you need to preserve a specific layout.

How indentation affects readability

Indentation is the primary visual signal for nesting depth in JSON. The choice between 2 spaces, 4 spaces, and tabs affects how comfortably you can scan a document.

2 spaces is the dominant convention in the JavaScript and Node.js ecosystems. Most linters, formatters, and style guides default to it. The advantage is density: each nesting level adds only two characters, so even four levels deep the content stays within a typical editor width. The trade-off is that two characters can be subtle — at a glance, three levels and four levels look similar.

4 spaces doubles the visual step. Each level is unmistakable, which helps when you are tracing a path through a deeply nested response or comparing alignment across sibling objects. The cost is horizontal space: a four-level-deep array of objects with long property names can push content far to the right, causing wrapping on narrow screens or in side-by-side diff views.

Tabs let each reader configure their own display width in their editor — one person sees 2 spaces, another sees 8. This flexibility is useful in mixed-team settings. The downside is portability: when tab-indented JSON is pasted into a chat message, a terminal, or a Markdown code block, the tab width is controlled by the rendering application, which may display it as 8 spaces or as a single space. For JSON that will be shared in prose or pasted into documentation, spaces render identically everywhere.

Sorting keys for diffing

Object key order in JSON is not semantically meaningful — the specification defines objects as unordered — but most serializers preserve the order keys were inserted. When you diff two JSON files produced by different code paths, different key order generates noise: lines appear as removed and re-added even though the values are identical.

Enabling sort keys before formatting eliminates that noise. Both files get the same alphabetical key order at every nesting level, so a line-by-line diff only flags genuine value changes. This is useful in several scenarios:

• Comparing two snapshots from the same API endpoint taken at different times.
• Reviewing a database migration that restructured documents.
• Generating a stable cache key from a normalized JSON representation — sorted keys guarantee identical input produces identical output.
• Checking whether two config files diverge without being distracted by reordering.

Sorting is purely cosmetic from a data perspective. JSON.parse produces the same in-memory object regardless of key order, so sorted output parses to the same values as the original. The only difference is the byte sequence on disk or in the editor.

Do it in code

JavaScript:

const formatted = JSON.stringify(JSON.parse(input), null, 2);
// With sorted keys:
const sorted = JSON.stringify(
  Object.keys(JSON.parse(input)).sort().reduce((o, k) => (o[k] = obj[k], o), {}),
  null, 2
);

Python:

import json
formatted = json.dumps(json.loads(input), indent=2)
# With sorted keys:
sorted_output = json.dumps(json.loads(input), indent=2, sort_keys=True)

CLI:

# Python
echo '{"a":1,"b":2}' | python -m json.tool

# jq (2-space)
echo '{"a":1,"b":2}' | jq '.'

# jq (4-space)
echo '{"a":1,"b":2}' | jq --indent 4 '.'

Edge cases handled

• Minified JSON with no whitespace is formatted correctly.
• Unicode characters (emoji, CJK, accented characters) are preserved unless escape Unicode is enabled.
• Empty objects {} and arrays [] are preserved in the output.
• Deeply nested structures are handled without stack overflow for typical JSON depths.
• Invalid JSON shows an error message without producing partial output.