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.

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.

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 the validator flags the comma right after 1, 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. 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.⁵

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.

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.