Why I built json-indent

The last time I needed to quickly format a JSON payload, I opened up one of the usual suspects — the kind of site with a toolbar across the top, a cookie banner, ads down the sidebar, and a “Pro” plan somewhere below the fold. I just wanted the JSON formatted. Five seconds of pasting, one click, done.

So I built json-indent.com.

What it does

Paste your JSON, get it back formatted. Indented, readable, with proper nesting. The formatter validates as you type and tells you exactly where a syntax error is. That’s it.

No account. No tracking. No upsell. The page loads in under a second because there’s nothing on it but the tool.

Why vanilla JavaScript

The stack is deliberately boring: vanilla JavaScript, no dependencies, no build step. A tool that formats JSON doesn’t need a framework. It needs to load fast and work reliably.

The browser already has JSON.parse and JSON.stringify. The whole formatter is a thin wrapper around those two functions, plus some error handling to give useful messages when parsing fails.

I spent more time on the error messages than on the UI chrome. “Unexpected token ’}’ at position 42” is fine for a developer who already knows JSON syntax. “Expected a value after the colon on line 7” is better. The latter is what I tried to ship.

What happened next

It turned out a lot of developers feel the same way about their tools. The site gets thousands of visitors a month, almost entirely from search, almost entirely people who just want to check or format a JSON blob without friction.

I built xml-indent.com and yaml-indent.com on the same idea. Each one does one thing. Each one loads fast. Each one stays out of your way.

The lesson wasn’t about JSON formatters specifically. It was that the “boring” version of a tool — the one with no features beyond what’s needed — is often the right version. Scope creep is easy to justify and hard to undo.

Build the thing. Then stop.