JSON Tools

JSON Pretty Print

Turn dense single-line JSON into beautifully indented, readable output — your choice of indentation, with optional alphabetical key sorting.

In short

Pretty print JSON online with 2, 3, 4-space or tab indentation and optional alphabetical key sorting for stable diffs. Free, instant, 100% private.

By NaveenKumar T · Updated 10 Sep 2026

Learn: What is JSON? A Practical Introduction

2 / 3 / 4-space or tab indent
Optional alphabetical key sort
Syntax-highlighted output

Runs entirely in your browser — nothing you paste or open here is uploaded, logged, or stored.How we handle data →

Example

JSON Pretty Print: input and output

A minified API error response — the one-line blob you would otherwise have to squint at inside a network tab — printed at two-space indent with Sort keys turned on.

Input · json

{"error":{"code":"RATE_LIMITED","message":"Too many requests. Retry after 30s.","status":429,"request_id":"req_9F2KXQ7","retry_after":30,"docs_url":"https://example.com/docs/errors#rate-limited"}}

Output · json

{
  "error": {
    "code": "RATE_LIMITED",
    "docs_url": "https://example.com/docs/errors#rate-limited",
    "message": "Too many requests. Retry after 30s.",
    "request_id": "req_9F2KXQ7",
    "retry_after": 30,
    "status": 429
  }
}

The nested error object's six fields each land on their own line at 2-space indent, and Sort keys puts them in alphabetical order — code, docs_url, message, request_id, retry_after, status — rather than the order the server happened to serialize them in.

Learn more

Why pretty print JSON?

APIs return JSON optimized for machines: no spaces, no line breaks, every byte saved. That is perfect on the wire and miserable in a code review. Pretty printing restores the visual hierarchy — each nesting level indented, each key on its own line — so you can scan structure, spot the field that is missing, and diff two versions meaningfully instead of staring at a wall of commas.

This tool validates while it prints. If the document is malformed you get the exact line and column of the first error instead of half-formatted garbage, and the one-click Repair can usually fix the mechanical mistakes — trailing commas, single quotes, unquoted keys — that a hand-edited config picks up. Everything runs in your browser tab, so pasting a production payload with customer data or an API key does not send it anywhere.

The same job comes up in code, not just in a browser tab: `JSON.stringify(value, null, 2)` in JavaScript, `json.dumps(obj, indent=2)` in Python, `jq .` at a terminal. This page is the version you reach for when the document is in your clipboard rather than in a variable — and when you want to see it validated, sorted and tree-explorable in the same pass. The step-by-step guides for both languages are worth a read if you are automating the job: pretty-print JSON in Python and in JavaScript.

Choosing an indentation width

The indentation choice is cosmetic to a parser and anything but cosmetic to a reader. Two spaces is the JavaScript-ecosystem default and the right answer for most documents: it survives six or seven levels of nesting before lines start wrapping, and it is what the tooling around you already emits, so files stay diff-clean when someone else re-saves them. Four spaces doubles the horizontal cost per level, which is fine for a three-level configuration file in documentation and painful for a deeply nested API response. Tabs are the accessibility-friendly option, because each reader controls the rendered width, and the awkward option anywhere the file is shown with a fixed tab stop — GitHub renders a tab as eight columns by default, which makes a nested document look far worse than it is.

One rule beats all of the above: match whatever the file already uses, or whatever the repository's `.editorconfig` and formatter say. A pretty-print pass that changes every line's indentation turns a one-line change into a whole-file diff, and reviewers stop reading. If you are introducing a convention rather than following one, two spaces plus a formatter check in CI is the least controversial choice available.

Indentation widths at a glance
Setting	Typical home	Why you would choose it	Cost
2 spaces	package.json, npm, most JS/TS tooling, jq's default is 2	Survives deep nesting; matches what other tools emit	Slightly harder to scan at a glance in shallow files
3 spaces	Some legacy .NET and Java config	Only to match an existing file	Non-standard; nothing else emits it
4 spaces	Python's json.dumps examples, docs and slides	Reads clearly when nesting is shallow	Deep documents wrap or scroll horizontally
Tab	Go ecosystem, editor-configurable teams	Each reader picks their own width	Renders as 8 columns on GitHub and in many viewers
Minify	Production payloads, storage, message queues	Smallest bytes on the wire	Unreadable without a tool like this one

Sorting keys, and when it earns its place

The Sort keys toggle alphabetizes every object's keys, recursively, before printing. Its real purpose is diffing. Two services serialize the same record and one of them iterates a hash map in a different order; the payloads are semantically identical, but a line-based diff shows twenty changed lines. Sort both sides first and the diff collapses to the fields that genuinely differ. The same trick makes JSON fixtures in a test suite stable across language runtimes, and makes a checked-in snapshot file produce a clean commit instead of a reshuffled one.

Sorting is also the fastest way to answer 'does this object have the key I think it has?' in a wide, unfamiliar payload — alphabetical order turns scanning into a binary search. And when two documents are meant to be compared field by field, sorting them both before opening JSON Compare removes the ordering noise that would otherwise dominate the result.

Three cautions. Sorting is lossy in a human sense: authored JSON usually leads with identity (`id`, `type`, `name`) and trails with metadata, and alphabetizing destroys that grouping permanently — there is no unsort. Sorting never touches arrays, because arrays are ordered in JSON and reordering them would change the data, so a list of objects stays in its original sequence with each object's keys sorted inside. And if any consumer downstream signs, hashes or checksums the serialized bytes, sorting changes those bytes; canonical-JSON schemes (JCS, RFC 8785) specify their own ordering and escaping rules and are not interchangeable with a simple alphabetical sort. For a dedicated page with sorting as the headline action, use the JSON Sorter.

When pretty-printing is the wrong answer

Indentation is pure overhead on the wire, and at scale the overhead is not small. A typical API response gains roughly 8–15% in size from two-space indentation and newlines, and a deeply nested document with short values — a lot of keys, a lot of nesting, little payload per line — can gain 30% or more, because every level adds two bytes to every line. Multiply that by a few million requests a day and pretty-printing a production endpoint is a bandwidth line item, a latency cost on slow connections, and a mobile data-plan charge you are passing to your users.

The usual counter-argument is that gzip or brotli erases the difference, and it mostly does — indentation is exactly the kind of repetitive run that compresses to almost nothing, so the compressed delta is often 1–3%. But 'mostly' has holes worth knowing: responses below the compression threshold your server applies (commonly 1 kB) are not compressed at all, compression costs CPU on both ends, and payloads that are stored rather than transmitted — rows in a database column, documents in a queue, values in a cache — are frequently stored uncompressed, where whitespace is paid for on every read, every backup and every replication hop. Log lines are the worst case: a pretty-printed JSON log entry breaks the one-event-per-line convention that every log shipper and every `grep` depends on.

So the rule is simple. Pretty-print for humans, at the moment a human is reading: in a code review, a bug report, a screenshot, a debugging session, a documentation example. Minify for machines, everywhere else: API responses, message-queue bodies, database columns, log lines, embedded configuration in a bundle. Because the two forms parse identically, you never have to choose once and live with it — paste the compact form here to read it, and use JSON Minify or JSON to One Line to send it back the other way when you are done.

Help

Frequently asked questions

Everything you need to know about the JSON Pretty Print.

01What does pretty printing JSON mean?

Pretty printing rewrites JSON with line breaks and consistent indentation so its structure is visible to humans. The data itself is unchanged — a pretty-printed document parses to exactly the same value as the original minified one, byte differences and all being whitespace.

02How do I pretty print JSON here?

Paste your JSON (or click Sample), choose an indentation width in the rail — 2, 3, 4 spaces or tabs — and click Pretty Print. The result appears in the output pane ready to copy, download, or explore as a tree. Turn on Sort keys if you also want the object keys alphabetized.

03What does the Sort keys toggle do, and is it safe?

It rewrites every object in the document with its keys in alphabetical (code-unit) order, recursively, before printing. It is safe in the sense that matters: JSON objects are defined as unordered collections, so a consumer that relies on key order is already relying on undefined behaviour. Array order is never touched — arrays ARE ordered in JSON, and reordering them would change the data. The one thing to watch is that sorting is not reversible: once you sort and save, the original author's grouping (id first, metadata last) is gone.

04Which indentation should I use — 2, 3, 4 spaces or tabs?

Two spaces if you have no other constraint: it is what JSON.stringify examples, npm's package.json, and most JavaScript tooling emit, and it keeps deeply nested documents from running off the right edge. Four spaces reads better in documentation, slide decks and printed appendices where nesting is shallow. Three is unusual and mostly appears in legacy .NET and Java configuration. Tabs let every reader pick their own width in their own editor, which matters for accessibility, but they break alignment anywhere the file is displayed with a fixed tab stop.

05Pretty print vs. format vs. beautify — any difference?

They are the same operation under different names: re-indenting JSON for readability. Whichever term you searched for, this tool does it, and validates the document in the same pass. The only real distinction on this site is that pretty printing is the reading-side job, and Minify is its inverse.

06Can I go back to a single line?

Yes — the Minify button strips all insignificant whitespace and returns your document to its smallest single-line form, ideal for production payloads. Pretty print and minify round-trip exactly: neither changes the parsed value.

Keep working