JSON Formatter, Validator & Tree Viewer

Why raw JSON is hard to read

A single-line API response with forty levels of nesting is valid JSON and nearly impossible to read. Servers strip whitespace because machines do not need it: the JSON grammar treats spaces, tabs, and newlines between tokens as insignificant, so frameworks serialize compactly by default to save bytes on the wire.¹ Consequently, the payloads you most often need to inspect, such as webhook bodies, error responses, and configuration exports, usually arrive as one unbroken line.

What JSON actually is

JSON stands for JavaScript Object Notation, a text-based, language-independent serialization format built from exactly two structures.¹ An object is an unordered collection of name-value pairs, and an array is an ordered list of values. Every value inside either structure is a string, a number, an object, an array, or one of exactly three literal names: true, false, and null. One consequence surprises people regularly. A complete JSON text can be any single value, so a bare number or a quoted string pasted on its own is valid JSON, not only the braced and bracketed documents you see in API payloads.

That grammar explains most of this validator's strictness. The parser accepts exactly those values and nothing else, which is the strictness behind the failures this page catalogs: comments, unquoted keys, and single quotes are natural in JavaScript source, and each is absent from the grammar enforced here. The same two structures also describe the entire tree view. Every node the tree renders is one object, one array, or one scalar, which is why expanding a branch always resolves into one of those three shapes and nothing else, no matter how deep the nesting goes.

Formatting rebuilds the structure from scratch

Formatting restores the structure your eyes need. When you paste text into the input, the tool parses it with the browser's native JSON.parse and re-serializes the result through JSON.stringify with the indent you chose, so the output is always a faithful re-encoding of the parsed data rather than a line-by-line reflow of the original text.²

Nested objects indent one level per depth, and every key lands on its own line, so the indentation itself turns into a map of the document's shape. At a glance you can trace a value from its top-level key down through each layer of nesting, which is exactly the kind of orientation a single unbroken line of JSON never gives you.

JSON and XML solve different problems

XML and JSON differ at the design level, not just the syntax level. XML is a document markup language: its units are tags, attributes, and namespaces, and it was designed to carry whole documents in which prose and inline markup interleave freely. JSON is a data serialization format with two structures and named values, and it carries no attributes and no mixed content at all. That contrast maps onto natural homes. Documents a human reads, with prose and markup woven through them, suit XML's machinery; data a program exchanges, with fields and values and nothing else, suits JSON's two structures.

Why did APIs move to JSON then? Three practical reasons did most of the work. The same payload carries less text, because tags repeat the field name at both ends of every value while a JSON key appears once. A parsed document maps directly onto native objects in every mainstream language, which spares an integration from a translation layer. Everyday exchange also needs no schema machinery at all, so the ceremony XML requires buys nothing in the common case. XML keeps the ground where its strengths matter, including document publishing, mixed-content markup, and the older standards built on top of it.

How the validator pinpoints syntax errors

Browser engines disagree about how to describe a broken document. Chrome and Edge, both built on V8, typically report the character position of the failure and, in recent versions, a line and column; Firefox reports a line and column of the JSON data; Safari often names only the unexpected token.³⁴ Because of that inconsistency, most online validators simply print whatever the engine said and leave you to count characters yourself.

Turning a raw offset into a line and column

This tool normalizes the message instead. When the error text carries a line and column, the validator reads them directly; when it carries only a character offset, the tool walks your input, counts newline characters up to that offset, and derives the line and column itself. The result feeds a Jump to error button that focuses the input and selects the offending line, so the cursor lands exactly where the fix belongs.

The four mistakes behind most failures

In practice, four mistakes cause most failures: a trailing comma after the last member, a missing comma between members, an unquoted key, and single quotes where the grammar requires double quotes. All four are typos rather than design errors, which is why the fix is usually a one-character edit. Each one produces a different engine message, yet all four resolve in seconds once the failing line is selected right in front of you.

A trailing comma is the easiest to see in practice. Paste {"a": 1,} and parsing stops at the closing brace that follows the comma, because JSON.parse treats a comma with no following member as a syntax error rather than a harmless trailing token the way JavaScript object literals allow. The engine's message and the derived line and column therefore point at the brace, not at the comma itself, and the Jump to error button selects that entire line so the offending comma sits inside the selection. Deleting that single character so the input reads {"a": 1} turns it into valid JSON that parses and formats cleanly on the next keystroke.

Reading large payloads with the tree view

Text is the wrong shape for a five-megabyte document. Past a certain size, the useful question is no longer what line 40,000 says but what lives under a particular key, and a collapsible tree answers that far faster than scrolling. The tree view renders your parsed data as expandable nodes, with each object showing its key count and each array showing its item count before you ever open it.

Under the hood, the tree is built lazily: a node's children do not exist in the DOM until the first time you expand that node, and any object or array with more than 500 children renders the first 500 plus a button that loads 100 more per click. Building DOM nodes, not parsing, is what freezes a tab on large documents, so deferring construction keeps even huge payloads responsive. Inputs over roughly 500 KB also parse inside a background Web Worker, which keeps typing and scrolling smooth while the document is processed.⁵

Finding one value in a big document

One boundary deserves plain words before you paste something enormous. This viewer has no search box and no query language. Nothing here accepts a path expression or a query filter of any kind, and the tree exists for shape and navigation rather than lookup, so a five-megabyte paste arrives with the right expectations only if you know that up front. The split is deliberate. A query engine and a fast, lazy, collapsible reader are different projects, and this page is the reader, built to open huge payloads smoothly rather than to sift them.

The practical path for a needle is the text view plus your browser. The formatted output is ordinary rendered text in the page, so your browser's built-in find bar locates any substring in it immediately. The workflow for one specific value is short: format the document, stay in Text view, and run find in page, with the tree reserved for questions of shape and structure. Query-shaped work beyond substring hunting belongs to the command-line route a later section of this page describes, where filters and scripted pipelines do the sifting this viewer leaves out.

Pretty print or minify

Pretty output is for people and minified output is for machines. Indented JSON makes code review, debugging, and documentation legible, while minified JSON strips every insignificant byte before a payload ships over the network or lands in a size-limited configuration field. The toggle switches instantly between the two because both render from the same parsed value, and the indent control offers 2-space, 4-space, or tab indentation for the pretty form.

What re-serialization normalizes

One honest caveat applies to both modes. Since the output is a re-serialization of the parsed data, equivalent representations normalize: the number 1e2 comes back as 100, escape sequences may be rewritten in canonical form, and when an object contains the same key twice, JSON.parse keeps only the last value, which the specification explicitly permits.⁶⁷ Your data is unchanged, but its textual spelling may differ from the input.

Key order deserves its own line in that caveat. Formatting preserves the order your keys arrived in, with one exception the serializer imposes: keys that look like array indices, such as "0", "3", or "42", jump ahead of every other key and sort numerically among themselves. Paste {"b": 1, "2": 2, "a": 3} and the output leads with the "2" entry, while the ordinary string keys keep the positions you gave them. A document that mixes index-like keys with named keys is therefore the one that visibly reorders, which is why most payloads never notice the rule at all.

The same job outside the browser

This same pretty-print-and-validate job runs outside the browser tab. jq's default filter exists to validate and pretty-print its input, and its filter language builds pipelines that reshape payloads on the way through.⁸ Python's json module covers scripting needs and doubles as a command-line validator and pretty-printer.⁹ On Windows, PowerShell's ConvertFrom-Json and ConvertTo-Json cmdlets convert between JSON text and objects for automation.¹⁰ Each route works on files already on your disk and prints its result where the next command can read it, so a scripted pipeline can format, check, and transform payloads without a page ever opening.

The browser route still wins for the work this page does best. A one-off inspection needs no shell history and no local files: you paste or drop the payload, read the result, and close the tab. The tree view turns shape exploration into clicks, which plain text output does not offer. And the payload never leaves the tab, which matters when the JSON you are inspecting carries credentials or customer data. The terminal wins when the files already live on disk, when the output feeds the next command in a chain, and when the same transformation runs on a schedule. The two routes complement rather than compete.

Your JSON never leaves the browser

Pasting production payloads into a random website is a real risk. API responses routinely contain session tokens, email addresses, and internal identifiers, and a server-backed formatter receives all of it the moment you paste. This tool takes the opposite approach: parsing, formatting, validation, and the tree view all execute inside your browser tab, and no request carries your input anywhere.

Everything the formatter does relies on primitives your browser already ships: JSON.parse and JSON.stringify for the data work, and a Web Worker for keeping big parses off the main thread.²⁵ After the page loads you can disconnect from the internet entirely and every feature keeps working, which is also the simplest way to verify this claim for yourself. No account, API key, or server round trip sits between your paste and the result, so the only copy of your data is the one already in your own tab.