TL;DR
The biggest decision is not API shape. It is whether you want authentication as infrastructure you own or as a product you buy.
Better Auth is the strongest choice for new self-hosted TypeScript apps that want modern features like passkeys, organizations, and better end-to-end typing without paying a hosted-auth premium. Clerk is the fastest route to polished production auth when you want hosted UI, tenant features, and a managed identity layer. Auth.js remains the safest conventional answer for teams already invested in Next.js and provider-driven OAuth flows.
Quick Comparison
| Product | npm package | Weekly downloads | Latest | Bundlephobia min+gz | Best for | Biggest tradeoff |
|---|---|---|---|---|---|---|
| Better Auth | better-auth | ~2.3M/week | 1.6.9 | ~162.2 KB | TypeScript-first teams that want self-hosted auth with modern built-in capabilities. | You still own the auth system, database, migrations, and operational details. |
| Clerk | @clerk/nextjs | ~1.1M/week | 7.2.5 | ~36.4 KB | Teams that want managed auth, polished components, and faster time to production. | Vendor dependency and pricing become real architecture factors over time. |
| Auth.js | @auth/core | ~2.6M/week | 0.34.3 | ~41.3 KB | Next.js and multi-provider OAuth setups that want a familiar self-hosted path. | The core is flexible, but customization and typing still feel less integrated than Better Auth. |
Auth.js package adoption is split across packages. next-auth still does roughly ~3.7M weekly downloads on its own, so the real Auth.js footprint is larger than the core package number suggests.
Why this matters in 2026
Auth requirements are more demanding now than they were a few years ago. Basic email/password is table stakes. Teams increasingly need passkeys, social login, organization membership, device/session management, B2B SSO, and revocation behavior that does not become a security liability later.
That is why the old "just pick whatever login package works with my framework" advice is not enough anymore. The 2026 choice is really about product boundaries:
- Do you want identity to be an internal capability or an external service?
- Do you need B2B features now or later?
- Is your team comfortable debugging auth behavior at the database and cookie layer?
- Are you optimizing for velocity this quarter or ownership over multiple years?
Those questions matter more than minor API differences.
What actually changes the decision
- If you want hosted auth with polished built-in UX, Clerk is the clearest answer.
- If you want to self-host and still get modern auth ergonomics, Better Auth is the most compelling new default.
- If you are already deep in Next.js and your team understands the NextAuth/Auth.js model, Auth.js remains practical.
- If organizations, teams, or admin workflows are core product requirements, Clerk and Better Auth are easier starting points than Auth.js.
- If minimizing vendor lock-in is a hard requirement, Better Auth or Auth.js make more sense.
- If implementation speed is the most important thing, Clerk usually wins.
Package-by-package breakdown
Better Auth
Package: better-auth | Weekly downloads: ~2.3M | Latest: 1.6.9 | Bundlephobia: ~162.2 KB min+gz
Better Auth has become the most interesting self-hosted auth option because it feels like it was designed after developers had already accumulated years of frustration with older JavaScript auth libraries. The key improvement is not just features. It is that the features feel integrated instead of bolted on.
Why teams are moving to it:
- Strong TypeScript ergonomics across server and client APIs
- Built-in support for modern auth flows like passkeys and magic links
- Better story for organizations, roles, and product-style auth requirements
- Clearer fit for teams using Drizzle, modern app frameworks, and edge-friendly runtimes
Where the cost remains:
- You still own the persistence layer and runtime behavior
- Self-hosted auth is never actually low-complexity at scale
- Package size is larger than the other two options because it is doing more in-library
Better Auth is not "free Clerk." It is a better self-hosted foundation for teams that are willing to own auth as part of their application.
Clerk
Package: @clerk/nextjs | Weekly downloads: ~1.1M | Latest: 7.2.5 | Bundlephobia: ~36.4 KB min+gz
Clerk wins when you want auth to behave like a product purchase, not a custom subsystem. That includes prebuilt flows, session management, hosted identity primitives, user management UI, and product capabilities that would otherwise take a team weeks or months to assemble cleanly.
Why teams pick it:
- Fastest path from zero to production-ready auth
- Excellent onboarding and prebuilt UI for common flows
- Good fit for multi-tenant apps and account-centric SaaS products
- Lower operational burden than self-hosting auth state yourself
Where it becomes a strategic choice rather than a coding convenience:
- Pricing matters once your user base grows
- Migration away from a managed auth provider is never trivial
- Some teams will not want core identity concerns outside their own boundary
Clerk is usually the highest-velocity choice. It is not the highest-control choice.
Auth.js
Package: @auth/core | Weekly downloads: ~2.6M | Latest: 0.34.3 | Bundlephobia: ~41.3 KB min+gz
Auth.js remains highly relevant because it is the most established self-hosted auth solution in the React and Next.js ecosystem. It still has the deepest provider coverage, the most historical usage, and the largest body of examples. For many teams, that matters more than having the newest abstraction.
It is especially strong when OAuth is the center of your auth story and you want the broadest adapter and integration support. It is weaker when you want auth to feel like a modern product system with organizations, passkeys, or richer built-in account features.
Why teams still choose it:
- Huge community and long operational history
- Very broad OAuth provider ecosystem
- Strong default fit for existing Next.js codebases
- Reasonable self-hosted path with adapters and familiar deployment patterns
Where it feels older than the competition:
- Typing and session customization still require more manual work than Better Auth
- Product-level features often require more custom implementation
- The architecture is flexible, but not always elegant for new greenfield apps
Auth.js is still a good answer. It is just no longer the only serious self-hosted answer.
Which one should you choose?
- Choose Better Auth if you want self-hosted auth and your team cares a lot about TypeScript, modern features, and minimizing auth glue code.
- Choose Clerk if you want to move fastest and are comfortable treating auth as a managed vendor dependency.
- Choose Auth.js if you are already on Next.js, need deep provider support, and prefer the most established self-hosted ecosystem.
- Choose Clerk for product velocity.
- Choose Better Auth for modern self-hosted architecture.
- Choose Auth.js for continuity and ecosystem depth.
Final recommendation
For new self-hosted TypeScript apps in 2026, Better Auth is the best default.
For teams that want authentication solved as a product capability rather than engineered as an internal system, Clerk is the better choice. For established Next.js teams already comfortable with the NextAuth/Auth.js model, staying on Auth.js is still rational. The wrong move is treating all three as equivalent. They optimize for different ownership models, and that is the decision that really matters.
Related reading
How to Add Authentication to Any React App in 2026 · better-auth vs Lucia vs NextAuth 2026 · Compare Clerk vs NextAuth