I keep a tab with a JSON formatter open roughly 300 days a year. And roughly 300 days a year, that tab tries to sell me something.
So I built jsonkit.tools — 24 browser-based dev tools under one roof. The browser tools run client-side. No signup, no upload. You paste, you get the result.
What's actually in there
JSON formatter with tree view, validators, converters between JSON/CSV/YAML/XML (both directions), Base64 and URL encoding, JSON diff, JSON-to-TypeScript, UUID and hash generators, and a timestamp converter. Each tool is its own page with its own URL — no SPA tab-switching.
The less common part: a REST API
Most browser tool sites stop at the browser. I added api.jsonkit.tools — 28 endpoints with the same operations you get in the UI. The endpoints follow the same input/output contract.
Why? Because if you're building automation or working with LLM agents, you want deterministic transformations — not a model guessing how to reformat your payload. One HTTP call, stable output, no surprises.
curl -X POST https://api.jsonkit.tools/v1/json/format \
-H "Content-Type: application/json" \
-d '{"input": "{\"a\":1,\"b\":2}", "indent": 2}'
Stack
Astro with static generation. Each tool compiles to its own HTML page — fast to load, easy for search engines to index, and with zero client-side routing overhead. Dark theme by default.
The tools themselves are vanilla JS components. No heavy framework runtime, no hydration penalty for what is essentially a text box and a function call.
jsonkit.tools — feedback welcome.
Top comments (1)
The client-side approach is the strongest part for me. JSON often contains customer records, tokens, or internal API responses that should not be uploaded to an unknown formatter. Giving every tool its own static URL also improves usability and discoverability. The deterministic API endpoints make this particularly useful for automation and LLM workflows where predictable transformations matter more than generated guesses.