Format and inspect JSON before you review it

Use this synthetic input to check the actual result before using private data.

Paste the example in JSON Tree Viewer, then open Minified. The output must match this text exactly.

{"id":9007199254740993,"2":"b","1":"a"}

The integer ends in 993 and key 2 stays before key 1. With {"name":}, the error is at line 1, column 9. Limits: 256 KiB, depth 40, 10,000 nodes; duplicate and reserved keys are rejected.

Minified JSON is built for machines: one line, no indentation, keys in whatever order the serializer produced. Asking your eyes to review that wall is how a removed permission, a flipped flag, or an unexpected endpoint slips through.

A pretty-printer is also the cheapest validity check you own. A document that fails to parse was never going to behave in production either, and learning that in a review tab is far better than learning it from a deployment log.

• Readability onlyFormatting preserves parsed JSON values but can normalize escape sequences and number spelling. Compare meaning rather than byte-for-byte text, and keep the original for signed or byte-sensitive files.
• Depth is signalConsistent indentation exposes nesting depth at a glance, and depth is where configuration mistakes hide—an option placed one level too deep is simply ignored.
• Ship the expected shapeReview the formatted copy, but ship whatever shape the system expects; pretty-printing is for humans, not for the wire.

A tree view answers the questions a reviewer actually asks—what keys exist, what type each value has, how deep the structure goes—without scanning brackets. Raw text answers none of those quickly.

JSON Tree Viewer checks pasted text immediately and typed text after a short pause when Auto-check is enabled. You can also use Format & validate. Syntax errors include a location and recovery hint; valid input opens a tree and formatted or minified views.

The summary reports node count and depth. Reserved prototype keys are rejected, but this check does not certify application security.

The tree also flattens the conversation in a review: “the third element of items has a null price” is a comment anyone can verify in seconds, while a byte offset into a minified line is not.

Comparing two JSON documents by eye fails as soon as key order changes. A structural diff parses both sides and reports what actually changed—added, removed, and modified values—regardless of ordering or whitespace.

Text & JSON Diff has Text and JSON modes. In Text mode, choose smart, line, word, or character precision. JSON mode parses both documents and compares values, so reordered keys and reformatted whitespace report as identical.

For non-JSON text, Text mode offers ignore-whitespace and line-ending normalization toggles, and the summary counts additions, removals, and changes. Use JSON mode for payloads and configuration; switch to Text mode when one side is not valid JSON.

Determinism matters beyond convenience. When two reviewers run the same comparison, they must get the same answer—otherwise the review becomes a negotiation about tooling instead of a decision about the change.

These are local runtimes with explicit ceilings, sized for review payloads rather than bulk data processing. Knowing the ceiling tells you when to reach for desktop tooling instead.

The ceilings exist because parsing and diffing run in the same tab you are reading in; an honest limit beats a frozen page, and the workspace reports an exceeded limit as an explicit error rather than a silent truncation.

• Viewer ceilingJSON Tree Viewer accepts up to 256 KiB of input, forty levels of nesting, and ten thousand nodes—plenty for an API response or a configuration file.
• Diff ceilingText mode accepts up to 256K characters per side; JSON mode also enforces a 256 KiB UTF-8 parse limit per side. Both cap difference records at 10,000.
• Beyond the browserLarger exports—database dumps, log archives, generated fixtures—belong in a desktop editor or a command-line tool, not in a browser tab.

A short routine that catches most payload problems before they reach production.

Run the checklist on the producer’s sample data as well as the live payload; a fixture that disagrees with reality invalidates the review just as surely as a bug does.

• ParseFormat and parse first: confirm the document is valid and glance at the node count and depth against expectations.
• InspectInspect the tree: check types at the leaves—a numeric identifier arriving as a string is a classic integration bug.
• DiffDiff against the last known-good version in JSON mode, and read every reported change before approving.

Review payloads often contain customer records, tokens, or internal URLs. A local viewer keeps that material in the tab: the text is parsed by code running on your device and is never transmitted as part of the operation.

That boundary is what makes these tools usable with real staging payloads during a review. It does not erase your own obligations: downloaded exports, clipboard contents, and screenshots of the tree are still yours to handle carefully once they leave the workspace.

If you must share a payload fragment in the review itself, paste the smallest excerpt that shows the issue and redact identifiers first—the same discipline the support channels ask for.

Contract description revision: 2026-10-05.2

Same-page handoff accepts at most 256 KiB of UTF-8 text for 10 minutes. This is the transfer limit; each receiving tool has its own parsing and display limits.

JSON Tree Viewer and Structured Data Converter send output to a single same-page target. Tree accepts JSON only; Converter and Text & JSON Diff can receive JSON, YAML or CSV. Opening a target does not automatically run a conversion.

The transferred text stays in page memory. It is excluded from URLs, storage and analytics. Closing the target, replacing the source, leaving or refreshing the page, or expiry discards it. Focus returns to the source heading on expiry only when focus was inside the target.