Format and inspect JSON before you review it

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 is a readability transform: it changes whitespace and line breaks, never the data, so a formatted copy is always safe to review against the original.
• 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 parses explicitly: nothing renders until you press Parse JSON, and invalid input gets a located error with a repair hint instead of a silent failure. The result opens as an expandable tree with per-node types and counts, and a Formatted tab shows the normalized document with your choice of indentation.

The parse summary reports node count and maximum depth, a quick sanity check against what the payload should contain. Reserved prototype keys are rejected, so a hostile payload cannot masquerade as an innocent one while you inspect it.

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 offers three modes: lines, characters, and JSON. The JSON mode is the deterministic one for reviews: both documents are parsed and then compared value by value, so reordered keys and reformatted whitespace correctly report as identical.

For non-JSON text, the line and character modes include ignore-whitespace and line-ending normalization toggles, and the summary counts additions, removals, and changes. Use JSON mode for payloads and configuration; fall back to line mode when one side is not valid JSON at all.

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 & JSON Diff compares up to 256 KiB per side and reports at most ten thousand difference records before declaring the comparison too complex.
• 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.