Every time I debugged a deeply nested API response, I scrolled. I counted brackets. I lost my place. After the third or fourth time of doing this for the same Stripe webhook, I gave up and built a thing: paste JSON in one side, see it as an interactive graph on the other.

The result is jsonbloom.com — free, runs entirely in the browser, no signup. This post is about the architecture choices behind it, because most of them turned out to be smaller decisions than I expected.

Why not react-flow or d3-hierarchy?

Both are great libraries. I tried both before writing anything custom. The problem is that they're designed for a much broader interaction model than what a JSON viewer actually needs.

• react-flow is ~150kb gzipped on its own. It supports node dragging, edge editing, mini-maps, custom handles — none of which a JSON visualizer needs.
• d3-hierarchy gives you the layout math, but you still bring your own renderer, your own collapse logic, your own interaction layer.

What a JSON visualizer actually needs is narrow:

1. Render objects and arrays as boxes
2. Draw edges from a parent to each child
3. Collapse / expand subtrees
4. Pan and zoom the whole canvas
5. Edit a leaf value inline

That's it. No drag-to-rearrange, no node merging, no custom node types. Once I wrote that list down, the case for a custom renderer wrote itself: ~5kb of code that does exactly these five things, versus 150kb of code that does many more things less directly.

The architecture

Astro (static shell, SSG)
└── React island (client:only)
    ├── CodeMirror editor on the left
    └── Custom SVG graph on the right

The whole landing page — hero, feature cards, FAQ — is plain Astro components rendered at build time. Only the workspace (editor + graph) is a React island, mounted with client:only because there's no useful SSR for it. This gets you:

• ~30kb of JS on the marketing pages (zero React there)
• Fast first paint even on slow connections
• The interactive part loads in parallel while users read the hero

If you've used Astro this is the obvious play. If you haven't: it's the single biggest perf win for a "landing page + interactive tool" site, and it's almost free to adopt.

The layout

JSON is a tree. The naive thing is to lay it out like an org chart: root at the top, children below. That works for small payloads and breaks immediately for anything realistic — a 50-key object becomes 50 boxes in a row.

The pattern I settled on:

• Objects and arrays are boxes in a left-to-right tree
• Primitive values are pinned next to their key inside the parent box, not as separate nodes
• Each level is its own column; siblings stack vertically

This collapses what would be hundreds of nodes into tens. A typical Stripe event renders as maybe 8–15 boxes instead of 80.

Layout is one pass:

function layout(node, depth = 0, y = 0) {
  node.x = depth * COLUMN_WIDTH;
  node.y = y;
  let childY = y;
  for (const child of node.children) {
    const h = layout(child, depth + 1, childY);
    childY += h + GAP;
  }
  node.height = Math.max(NODE_MIN_H, childY - y);
  return node.height;
}

That's it. No d3, no force simulation. It's deterministic, fast, and you can collapse a subtree by walking the same recursion and skipping its children.

The hard parts

I underestimated three things.

1. Inline editing that stays in sync. The editor on the left is the source of truth. The graph on the right is a view. When you click a value in the graph and edit it, the change has to propagate back to the editor's text — but the editor has cursor position, undo history, syntax highlighting. You can't just setValue on every edit because you'd nuke the user's cursor every keystroke they made elsewhere.

The fix was to make the graph send a patch (JSON pointer + new value) rather than a full document, and have the editor apply patches as small targeted dispatches. CodeMirror's transaction API makes this clean once you stop thinking of the editor as a "text input."

2. Collapsing without relayout flicker. First version: collapse a node → re-run layout for the entire tree → React re-renders everything. The result was a visible jump even on small payloads.

The fix: layout is incremental. Each subtree owns its own height. When you collapse a node, you only walk up the tree to fix the y-offsets of its later siblings, not the whole document.

3. Cycles. Most people don't realise that JavaScript objects can have cycles but JSON cannot. If you're parsing user input you don't have this problem — JSON.parse would reject it. But if you ever support eval-like input (I had this in an early version) you absolutely have to detect cycles before walking, or your renderer locks up.

What I would do differently

• I should have started with the editor → graph protocol (patches) from day one. I started with "the graph re-derives from the parsed JSON every render" and that was fine until it wasn't.
• Hand-rolled SVG was the right call for layout but a slightly less right call for the editing controls. I should have used HTML overlays positioned over the SVG for the inline editors — <input> inside <foreignObject> has just enough cross-browser jank to be a recurring annoyance.

Stack summary

• Astro for the shell
• React for the workspace island
• CodeMirror 6 for the editor
• Plain SVG + a ~200-line layout function for the graph
• No state management library — everything is local React state plus the JSON document as the single source of truth

Try it

jsonbloom.com — paste any JSON in. I'd especially love feedback on:

• Performance with your biggest real-world payloads (a few MB and up)
• Edge cases in the inline editor
• Anything that feels off when you collapse a deeply nested subtree

It's free, no signup, and your JSON never leaves your browser.