Best Swagger Codegen alternatives (2026)
Last updated: September 2026
If Swagger Codegen still generates your clients, moving off it takes two steps: bring your API description up to OpenAPI 3.1, then pick the generator that fits the code you actually ship. This guide covers both, with sources for every claim.
Swagger Codegen is where OpenAPI code generation started. The repository dates from 2011, has nearly 18,000 GitHub stars, is Apache 2.0 licensed, and is still released: v3.0.82 shipped in August 2026. A lot of production code was generated by it, and some of that code will outlive this page.
We make Scalar and list it first. Where another tool is the better fit, we say so.
Why teams move off Swagger Codegen
Two version lines, and neither covers OpenAPI 3.1. Swagger Codegen maintains 2.x and 3.x independently, with different Maven group IDs. The 2.x line lives on the default master branch and supports Swagger 2.0 only. The 3.x line lives on the 3.0.0 branch and its compatibility table lists specifications up to OpenAPI 3.0. The request for OpenAPI 3.1 support has been open since August 2023, and a 2026 bug report notes that some 3.1 constructs cannot be parsed at all. If your framework now emits 3.1 by default, as ASP.NET Core does in .NET 10, Swagger Codegen cannot reliably read what your build produces.
Upgrading to 3.x can cost you languages. The 2.x README lists a long set of clients, including Rust, Elixir, Haskell and Objective-C. The 3.x client list is shorter: C#, Dart, Go, Java, JavaScript, Kotlin, PHP, Python, R, Ruby, Scala, Swift and three TypeScript flavours. Teams on a language that did not make the jump are stuck on 2.x, which means stuck on Swagger 2.0.
Community momentum moved elsewhere. In 2018 more than 40 top contributors forked the project as OpenAPI Generator, citing issues with the 3.0.0 beta and disagreement about direction. Swagger Codegen has around 3,000 open issues; some of the most requested, such as Python type hints and documenting per-language config options, have been open since 2017 and 2018.
The output shows its age. Generated code follows templates designed years ago. Modern expectations such as typed async clients, auto-pagination, retries with backoff, and typed errors are either missing or depend on the language template.
Step one: upgrade the document
Whatever you choose next, start by moving a Swagger 2.0 description to OpenAPI 3.1. Every modern generator and renderer reads 3.1, and it is the version your framework is likely to produce anyway. Scalar's open-source upgrader does it in one command:
npx @scalar/cli document upgrade swagger.json --output openapi.json
It is also available as the MIT-licensed @scalar/openapi-upgrader package if you want to run it inside a build script. Validate the result before you generate anything:
npx @scalar/cli document validate openapi.json
If your document came from a framework, the better fix is usually to regenerate it from the framework at 3.1 rather than converting an old file. Commit the result, and treat that file as the source of truth for everything below.
Step two: choose a generator
| Tool | License | Reads OpenAPI 3.1 | Languages | Best for |
|---|---|---|---|---|
| Scalar | Hosted service | Yes | TypeScript, Python, Go, CLI GA; Java, Kotlin, Ruby, C#, PHP, Rust, Swift, Dart, C++ experimental | Published SDKs with releases handled |
| OpenAPI Generator | Apache 2.0 | Beta | Dozens of clients and servers | The closest drop-in, including server stubs |
| Kiota | MIT | Check your keywords | C#, Go, Java, PHP, Python, Ruby, TypeScript | Consistent internal clients |
| NSwag | MIT | Lists 2.0 and 3.0 | C#, TypeScript | .NET shops with Swagger-era tooling |
| openapi-typescript | MIT | Yes | TypeScript | Front-end types without a JVM |
| oapi-codegen | Apache 2.0 | Yes | Go | Go clients and servers |
Checked against each project's repository, README or package page on 26 September 2026.
1. Scalar SDK generator
Scalar reads your OpenAPI 3.0 or 3.1 document (Swagger 2.0 is upgraded on load, so step one is optional for Scalar itself) and generates SDKs you publish from your own GitHub repositories. The generally available targets are TypeScript, Python, Go and a CLI; nine more languages are experimental and labelled as such. Generated SDKs include auto-paginating iterators, retries that honour Retry-After, timeouts, typed errors, and OAuth 2.0 support, with a generated README and publishing workflows. When you edit the generated code, your changes are carried forward on every regeneration instead of being overwritten, which is the problem Swagger Codegen users usually solve with .swagger-codegen-ignore files and template forks.
It is a hosted product with a free plan (one SDK for APIs up to 25 endpoints), and Pro at $150/month. The same document can also power API documentation and a hosted MCP server.
Verdict: the biggest jump in SDK quality from a Swagger Codegen baseline, for the languages it supports well today. Best for: teams whose generated clients are a product their customers install.
2. OpenAPI Generator
OpenAPI Generator is Swagger Codegen's community fork and the most natural next step. It keeps the same concepts (a JAR, Mustache templates, per-language generators, an ignore file) and adds many more generators, OpenAPI 3.x support, and a much faster release cadence (v7.25.0 in August 2026). It needs Java 11 or newer, where Swagger Codegen 3.x needs Java 8. Expect template overrides to need porting, since the two projects' templates have diverged since 2018.
Verdict: the lowest-risk move if you want to keep the same workflow. Best for: server stubs, uncommon languages, and teams with custom templates. Our OpenAPI Generator alternatives guide covers where it falls short in turn.
3. Kiota
Microsoft's Kiota generates clients in seven languages that all follow the same model, backed by a small core library per language. It can generate a client for only the endpoints you need.
Verdict: a clean, free, well-maintained option for clients you consume. Best for: calling large third-party APIs from several internal codebases.
4. NSwag
If your Swagger Codegen use was a C# or TypeScript client for an ASP.NET API, NSwag does document generation and client generation in one .NET toolchain, including NSwagStudio for people who prefer a GUI. Its README describes it as a Swagger 2.0 and OpenAPI 3.0 toolchain, which is fine for older documents but worth checking if you are moving to 3.1.
Verdict: familiar ground for .NET teams. Best for: C# and TypeScript clients generated next to an ASP.NET Core API. See also Swashbuckle alternatives.
5. openapi-typescript
openapi-typescript turns an OpenAPI 3.0 or 3.1 document into TypeScript types, and its companion openapi-fetch gives you a small typed client on top. It replaces the typescript-fetch and typescript-axios generators for most front-end use without generating classes you then have to keep in sync.
Verdict: a far smaller footprint than any template generator for TypeScript. Best for: web apps calling their own backend.
6. oapi-codegen
oapi-codegen generates Go types, clients and server interfaces for common routers, and describes support for OpenAPI 3.0 and 3.1. It replaces Swagger Codegen's go and go-server generators with more idiomatic output and no JVM.
Verdict: the default recommendation for Go. Best for: Go services and clients.
When to stay on Swagger Codegen
- Your API description is Swagger 2.0 and will stay that way. A frozen legacy API with a frozen client does not need a new generator.
- Your build depends on the Maven plugin and a Java 8 toolchain. If upgrading the JVM is harder than living with old output, stay until that changes.
- You rely on a 2.x-only language and nothing else on this page covers it. Check OpenAPI Generator's list first, because it probably does.
- Your generated code is checked in and hand-edited. Regenerating with a different tool will produce a large diff. Plan it as a deliberate major version, not a tooling tweak.
A migration checklist
- Record the Swagger Codegen version, language, and every
--additional-propertiesflag you pass today. - Upgrade and validate the document as shown above.
- Generate with the new tool into a separate directory and diff the public surface: package names, class and method names, model names.
- Pin method names where they changed. Most generators derive them from
operationId; Scalar also lets you set the resource tree explicitly. - Ship the new SDK as a major version with a short upgrade note for your users.
Frequently asked questions
Does Swagger Codegen support OpenAPI 3.1?
Not as of September 2026. The 3.x line lists compatibility up to OpenAPI 3.0, and the feature request for 3.1 has been open since 2023. OpenAPI Generator lists 3.1 as beta; Scalar, openapi-typescript and oapi-codegen read 3.1 documents.
Is Swagger Codegen deprecated?
No. Both the 2.x and 3.x lines still get releases. It is maintained, but slower-moving than OpenAPI Generator and without OpenAPI 3.1 support.
What is the difference between Swagger Codegen 2 and 3?
They are separate version lines with different Maven group IDs (io.swagger for 2.x, io.swagger.codegen.v3 for 3.x). Version 2.x reads Swagger 2.0 only. Version 3.x adds OpenAPI 3.0 but ships a shorter list of language generators, so some 2.x languages have no 3.x equivalent.
How do I convert a Swagger 2.0 file to OpenAPI 3.1?
Run npx @scalar/cli document upgrade swagger.json --output openapi.json, or use the @scalar/openapi-upgrader npm package in code. Then validate the output with npx @scalar/cli document validate openapi.json before generating anything from it.
Can I migrate from Swagger Codegen to OpenAPI Generator without changing my code?
Often the change is small, because OpenAPI Generator started as a fork and kept the same concepts. Generator names, options and templates have changed since 2018, though, so generate into a separate folder and compare the output before replacing anything.
Related
- Learn: OpenAPI vs Swagger · Generate an SDK from OpenAPI
- Docs: OpenAPI Upgrader
- Product: Scalar SDK Generator — modern SDKs from the OpenAPI document your Swagger Codegen setup already relies on.
This page is based on Swagger Codegen's public GitHub repository, README, version documentation and issue tracker, and on the public repositories and documentation of every other tool listed, as of 26 September 2026. Code generation tools change quickly. We have made a genuine effort to be accurate and fair. If you find something wrong or out of date, please open an issue and we will correct it.
