JSON Master

Format, validate, and explore JSON with an interactive tree view.

Indent:

JSON Input

Deep-Dive Technical Documentation

The JSON Grammar: ECMA-404 and RFC 8259 Under the Hood

JSON's formal grammar is specified by two overlapping standards: ECMA-404, published by Ecma International, which defines the data interchange syntax itself, and RFC 8259, published by the IETF, which tightens requirements for interoperability on the open internet. RFC 8259 mandates UTF-8 encoding (earlier drafts allowed UTF-16 and UTF-32), requires unique keys within an object (a SHOULD-level recommendation that many parsers still don't enforce), and clarifies that top-level values may be any JSON type — not just objects or arrays, as some early implementations assumed. The ECMA-404 grammar is context-free: six structural characters (left and right brackets and braces, colon, comma), three literal names (true, false, null), two composite types (object, array), and four primitive types (string, number, true/false, null). No comments, no trailing commas, no single quotes — the format is deliberately minimal. Understanding these rules matters because real-world toolchains enforce them differently: Python's json module rejects duplicate keys silently by keeping the last one, Go's encoding/json preserves insertion order, and JavaScript's JSON.parse follows the ECMA-262 spec which technically permits duplicate keys but returns only the final value.

How JSON.parse Works: V8's Recursive-Descent Scanner

When you press Format in JSON Master, the browser calls JSON.parse() — a method whose internals are often misunderstood. In V8, the engine powering Chrome and Node.js, JSON.parse is not a general-purpose JavaScript evaluation. It runs a dedicated fast-path scanner written in C++ (src/json/json-parser.h in the V8 source tree) that tokenizes the input as a strict JSON stream without ever entering the full JavaScript parser pipeline. This scanner performs single-pass lexical analysis: it reads one character at a time, matches structural tokens, builds an AST of nested objects and arrays, and constructs the corresponding JavaScript values. If it encounters a byte that violates the grammar — say, a single quote at position 423 — it raises a SyntaxError with the exact offset. SpiderMonkey (Firefox) and JavaScriptCore (Safari) use similar dedicated scanners. The key takeaway for developers: JSON.parse is significantly faster than eval() and introduces zero code-execution risk, which is why JSON Master delegates all validation directly to the engine.

Indentation, Whitespace, and the Minification Trade-Off

JSON allows four whitespace characters between tokens: space (0x20), horizontal tab (0x09), line feed (0x0A), and carriage return (0x0D). Pretty-printing injects these characters to create visual hierarchy. The second argument to JSON.stringify — the replacer — is often overlooked, but the third argument (the space parameter) controls indentation depth. JSON Master lets you choose 2-space, 4-space, or tab indentation because these map directly to the three most common project conventions (Google style uses 2, Airbnb and many Java projects use 4, and Go/Makefile ecosystems use tabs). Minification strips all insignificant whitespace, and the size savings are real: a typical nested API response with 2-space indentation shrinks 30–60% after minification. For latency-sensitive applications — WebSocket frames, localStorage writes, or URL query payloads — those saved bytes translate directly to faster parse times on the receiving end.

Security Considerations: JSON Injection and Prototype Pollution

Working with untrusted JSON payloads introduces two classes of risk that developers should understand. First, JSON injection: if you concatenate user input into a JSON string without proper escaping (failing to escape backslashes, double quotes, or control characters), an attacker can break out of a string value and inject arbitrary keys. This is analogous to SQL injection and is prevented by always using JSON.stringify() or a validated serializer rather than manual string concatenation. Second, prototype pollution: when a JSON payload contains keys like __proto__, constructor, or prototype, naive deep-merge or deep-clone functions can overwrite properties on Object.prototype, potentially enabling denial-of-service or privilege escalation. Libraries like lodash.merge were historically vulnerable to this. JSON Master's Tree View helps you spot these suspicious keys visually, and because the tool never merges your data into application state — it only displays it — there's no prototype pollution vector within the tool itself.

What is JSON Master?

JSON Master is a browser-based JSON toolkit for anyone who spends their day wrangling API responses, config files, or database dumps. If you've ever squinted at a 10,000-character single-line payload from a REST endpoint trying to find a missing comma — this is the tool you needed twenty minutes ago. JSON (JavaScript Object Notation) powers practically everything: REST and GraphQL APIs, NoSQL stores like MongoDB, config manifests (package.json, tsconfig.json), and even WebSocket message frames. The format looks simple, but its grammar is strict. One trailing comma, one unquoted key, one set of single quotes instead of double, and the whole document is invalid — no partial parsing, no graceful degradation. JSON Master runs your input through the browser's native JSON.parse() — the exact same recursive-descent parser inside V8 and SpiderMonkey — so you get the real error message with the real character offset, not a generic 'something went wrong.' From there you can pretty-print with 2-space, 4-space, or tab indentation, or go the other way and minify to strip every byte of whitespace (typically shaving 30–60% off nested payloads). The Tree View is where it really shines for large documents: it renders a collapsible, color-coded hierarchy so you can drill into a 500-key Kubernetes manifest without losing your place. And because everything runs client-side in your browser's JS sandbox, your API keys, tokens, and PII never touch a network cable.

How to Use

Paste your raw JSON into the input area — it can be a single-line minified API response, a multi-line config file, or even clipboard text from a database query. Alternatively, click 'Load Sample' to see a working demo.
Choose your indentation preference (2 spaces, 4 spaces, or tab) from the dropdown, then click 'Format' to pretty-print. To reduce payload size, click 'Minify' to strip all whitespace.
If the JSON contains a syntax error, the validation bar will highlight the exact error message returned by the parser, including character position, so you can pinpoint the issue instantly.
Switch to 'Tree View' to explore deeply nested objects and arrays interactively — click any node to expand or collapse it.
Hit 'Copy' to place the formatted or minified output on your clipboard, ready to paste into your IDE, Postman, or CI pipeline.

Common Use Cases

Formatting REST and GraphQL API responses from tools like Postman, curl, or Insomnia for human-readable debugging.
Validating JSON configuration files such as package.json, tsconfig.json, .eslintrc, or Docker Compose manifests before committing.
Navigating deeply nested Kubernetes resource definitions, Terraform state files, or AWS CloudFormation outputs using the Tree View.
Minifying JSON payloads before embedding them in localStorage, IndexedDB, query parameters, or WebSocket frames to reduce bandwidth.
Debugging deserialization errors in backend services by isolating the exact key or value that breaks the parser.
Converting single-line log output from structured logging libraries (Bunyan, Winston JSON transport) into readable, indented records.
Preparing mock API fixtures for unit tests in Jest, Vitest, or Cypress by cleaning and formatting sample data.

Frequently Asked Questions

Format adds newlines and indentation so you can actually read the structure. Minify does the opposite — strips every space, tab, and newline to produce the smallest valid string. A nested API response can easily shrink 30–60% after minification, which adds up fast if you're storing payloads or sending them over the wire.

It calls the browser's built-in JSON.parse() — the same strict parser inside V8 (Chrome/Node) and SpiderMonkey (Firefox) that conforms to ECMA-404 / RFC 8259. If your input breaks any rule — trailing commas, single quotes, unquoted keys, JS-style comments — the parser throws a SyntaxError with the exact character offset, and the tool shows it to you right in the validation bar.

It recursively walks the parsed object and renders each node as a collapsible section. Objects show curly-brace notation, arrays show their length in brackets, and primitive values are color-coded — green for strings, blue for numbers, purple for booleans, grey for null. Nodes deeper than level 2 start collapsed by default so the initial render stays fast, even on documents with thousands of keys.

JSON is way stricter than JavaScript object syntax. The usual culprits: trailing commas after the last item, single quotes instead of double quotes, unquoted keys, hex literals like 0xFF, JS comments (// or /* */), and values like undefined or NaN that JSON simply doesn't allow. The error message shows the exact character position — jump to that offset in your text and you'll find the problem.

Everything runs in a single JS thread in your browser, so it depends on your hardware. Documents up to ~10 MB usually format in under a second on any modern machine. Once you're north of 50 MB, you're better off with a streaming parser like oboe.js or a CLI tool like jq. The Tree View stays snappy on large files because it only renders the nodes you've actually expanded.

Yes. Zero network requests — open DevTools > Network tab while you use it and see for yourself. Formatting, validation, and tree rendering all happen in your browser's JS sandbox. No data leaves your machine, period. That makes it safe for API keys, tokens, credentials, PII, whatever you're working with.

Client-Side Sandbox Security Verification

Zero server transmission. All processing runs entirely within your browser's JavaScript sandbox using native browser-compiled APIs. 0% of your data payloads ever cross an external server boundary, origin log, or third-party endpoint.

Browser-native compilation. Operations like JSON.parse(), btoa()/atob(), encodeURIComponent(), and the Intl API are executed by the browser engine itself (V8, SpiderMonkey, or JavaScriptCore) — no WebAssembly payloads, no remote execution, no server-side eval.

Independently verifiable. Open your browser's DevTools > Network tab while using any tool. You will see zero outbound requests containing your data. This is a verifiable, auditable privacy architecture.