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: plenty of online converters quietly ship your payload to a backend (the browser's network tab shows you which ones), 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 would open first. 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.

The two newest tools exist for the same reason, one step further along. TypeScript to Zod picks up where JSON to TypeScript stops: an interface is a promise the compiler makes about your code, and a Zod schema is the check that the data really matches it at runtime. It translates the shapes it can translate with confidence (optionals, unions, enums, nested objects) and, for the ones it can't, such as Partial, Pick, function types and conditional types, it writes z.unknown() plus a TODO and lists the gaps above the output. A visible TODO fails in code review. A schema that is quietly wrong fails in production.

CSS to React style object covers the smallest UI chore that still catches people out. React drops a style key it doesn't recognise without a warning, so the failure is a rule that silently doesn't apply. Three cases cause nearly all of it: custom properties keep their dashes, vendor prefixes capitalise (WebkitLineClamp, but msFlex), and a bare number only means pixels on properties that aren't unitless. Paste a rule, read the object, and the three get handled the same way every time.

Both run as bundled modules with unit tests behind them, not as an inline script nobody checks, so a change to either converter has to pass its test file before it ships.

What's not here yet

The list is short on purpose. Shipping a dozen half-working tools would be easy and useless, and every tool tied to a library version goes stale on its own schedule. A package.json exports-field builder is the most likely next addition, 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.