json-utils.com

The problem

Why this needed to exist

JSON tool sites usually ask you to paste sensitive payloads into a page you cannot audit, and many send the document to a server. Production payloads carry tokens, customer data, and internal URLs, so a tool that uploads them is a tool engineers cannot safely use at work.

The tools are also fragmented. Formatting lives on one site, schema validation on another, and a jq playground somewhere else, each with its own interface and its own privacy story.

What I built

The product

I built one workbench with 52 tools behind a single registry: formatting, validation, repair, diffing, merging, tree and graph views, JSONPath, a jq playground powered by WebAssembly, code generators for a dozen languages, schema generation and validation, and JSON-LD expansion and compaction.

Each tool is a registry entry, a component, engine logic, and tests. Navigation, search, the tools directory, and the sitemap all derive from the registry, so a new tool appears everywhere at once instead of being wired in by hand.

How it works

Under the hood

Pages are delivered as static assets through a Cloudflare Worker. All processing happens on the visitor's device: parsing and transformation in the main thread for small work, Web Workers and WebAssembly for heavier jobs like jq, so the interface stays responsive.

In November 2026 the site grew from 39 to 52 tools. That pace was only safe because every change shipped through a pull request with the full Playwright suite, 540 tests across desktop Chromium and mobile WebKit, running in CI before deploy.

Results

Where it stands

• 52 tools live, up from 39, shipped in reviewed batches over two weeks.
• 540 Playwright tests in CI across Chromium and WebKit, with engine unit tests on top.
• One disclosed exception, clearly labelled on the page: the JSON-LD tool can fetch a public remote context when a document names one. Your document itself is never sent.
• Zero uploads for processing across every other tool on the site.