TypeScript to Zod

A TypeScript interface disappears at build time, so it tells you nothing about the JSON that actually arrived from an API. A Zod schema checks that data at runtime and gives you the type back through z.infer, so the shape is declared once instead of twice. Writing both by hand works until someone edits one of them, and then the type says a field exists while the payload says otherwise.

Yes. A field marked with a question mark gets .optional(), and a type written as T or null becomes .nullable() rather than a two-member union, which reads better and produces a clearer error. A union of string literals becomes z.enum, because z.enum reports the allowed values in its error message while a union of z.literal calls reports each failure separately.

It refuses them. Generics like Partial or Pick, function types, conditional and mapped types have no honest Zod equivalent, so each one becomes z.unknown() with the original type in a TODO comment, and the tool lists what it skipped above the output. A wrong schema is worse than no schema: it either rejects payloads that were fine or waves through ones that were not, and both fail in production. A TODO fails in review instead.

That is the intended path. Paste a real API response into the JSON to TypeScript generator, take the interfaces it produces, and paste them here. The result is a runtime-checked schema derived from data that genuinely came back from the API, which catches fields the documentation forgot. The tests for this tool use that tool default output as one of their fixtures.

No. Everything runs as client-side JavaScript in your own browser. Nothing you paste is uploaded, logged, or stored, there is no sign-up, and no network request is made while the tool works. Load the page, disconnect, and it still converts.