TypeScript to JS

Yes. The converter only removes things that are erased at compile time anyway: type annotations (`: string`, `: User[]`), interfaces, type aliases, generic type parameters (`<T>`), `as` casts, non-null assertions (`!`), and declaration-only constructs (`declare`, ambient `.d.ts` content). Anything that has runtime effects — control flow, expressions, function bodies, async/await, decorators if you have them enabled — passes through unchanged. Run the input under TS and the output under Node and you'll get identical behavior, identical exceptions, identical performance characteristics.

TypeScript enums become real JavaScript objects via the standard tsc transpilation: `enum Color { Red, Green, Blue }` produces a runtime object `var Color; (function (Color) { Color[Color['Red'] = 0] = 'Red'; ... })(Color || (Color = {}));`. This preserves both the forward lookup (`Color.Red === 0`) and the reverse lookup (`Color[0] === 'Red'`) that TypeScript enums provide. Const enums (`const enum`) are inlined at their use sites in TS-to-JS compilation, but since the converter operates on a single file at a time, const enums are handled like regular enums to keep the output self-contained.

Yes. Upload a `.tsx` file and JSX syntax is preserved as JSX in the output (since JSX is a separate transform from type-stripping, and most React build pipelines handle JSX separately via Babel or esbuild). If you want fully transpiled JavaScript with `React.createElement` calls instead of JSX, run the output through Babel with `@babel/preset-react`. For most use cases — sharing a component snippet, inlining a React file, or converting a TSX file for a Vite/Next.js project that handles JSX itself — leaving JSX intact is what you want.

Functionally for type-stripping, very little — the converter uses the same TypeScript compiler API under the hood. The differences are environmental: `tsc` needs Node.js installed, a tsconfig.json, and possibly project-wide type resolution to handle imports. This tool runs in your browser with zero setup, perfect for one-off conversions or when you don't have Node handy. The trade-off is that this tool processes a single file at a time and doesn't do cross-file type checking — it assumes your TypeScript is already valid and just strips the types. For full project compilation with type errors reported, use `tsc` locally; for quick conversions, use this.

A few reasons. First, distribution: when publishing a small library or example, JavaScript runs without a build step in any browser, Node.js, Deno, or Bun, while TypeScript needs compilation. Second, debugging the output: sometimes you want to see exactly what tsc produces from a tricky bit of TypeScript to understand the runtime cost (especially for enums, decorators, or down-leveling features). Third, sharing code with a JS-only colleague or in a JS-only context like a CodePen demo. Fourth, embedding scripts inline in HTML where a build pipeline doesn't fit. For active development, TypeScript is almost always the better choice — but the output JavaScript has its place.