Developer Tools

Why these run in your browser

Every tool here is a static page with a bit of JavaScript. Paste your JSON or click through the tsconfig presets and the work happens on your machine. Nothing gets posted to a server, nothing gets logged, and there's no account to create. That matters more than it sounds: half the online converters I've used over the years quietly ship your payload to a backend, which is a problem the moment the JSON you're debugging came out of a production response.

The trade-off is scope. A browser tool can't reach into your repo, run tsc, or read your lockfile, so these won't replace the compiler. They're for the ten-second jobs that break your flow: what does a strict config actually look like, what shape is this API response, which flag do I need for a monorepo package.

When each one earns its place

The tsconfig.json generator is for starting a package, not fixing one. Node library, browser app, monorepo leaf, bundler target: each wants a different set of module, moduleResolution, and lib values, and getting that combination wrong produces error messages that point nowhere near the actual mistake. Pick the preset that matches, toggle what you disagree with, paste the result. If you're already deep in a broken build, read the strict mode guide instead. A generator won't tell you which of your 400 existing errors to fix first.

JSON to TypeScript is the one I reach for weekly. An endpoint returns something undocumented, you need an interface for it now, and hand-typing forty fields is how typos get into a codebase. It handles nested objects, arrays, optional fields, and unions. What it can't do is guess intent, so treat the output as a first draft: a field that happened to be null in your sample will come out as null, not as the string it usually holds. Fix those by hand and you're done in under a minute.

The lint coverage audit is the odd one out: a script you download and run, not a box you paste into. It has to be, because the question it answers is about your repo rather than your config text. How many files did ESLint really open? Which plugin prefixes does the config name without ever loading them? Can the CI step fail at all? None of that is knowable from a pasted snippet, and all of it is knowable in about a minute from the command line. It reads, reports, and changes nothing.

What's coming next

The list is short on purpose. Shipping a dozen half-working tools would be easy and useless. Next up is a Zod schema generator that takes the same JSON input and emits a validator alongside the interface, because in practice you almost always want both, and keeping them in sync manually is where the bugs live. After that, probably a package.json exports-field builder, since dual ESM/CJS publishing still trips people up in 2026.

Missing something you'd use? The tools that get built are the ones people ask for, so say so on the contact page. Meanwhile the articles cover the parts a tool can't automate.