Clerk vs NextAuth (Auth.js) in 2026: Which One Should You Choose?

If you're starting a new Next.js project in 2026, picking an auth solution isn't as simple as it used to be. NextAuth has been renamed to Auth.js, it shipped a near-complete rewrite in v5, and Clerk has kept pushing further into the "auth + user management" space rather than just sign-in forms.

A lot of comparison posts floating around are still talking about NextAuth v4 and Clerk's old pricing, neither of which reflects what's actually shipping today. This guide compares the current versions, what changed, and which one makes sense for your project.

Quick Answer

Choose Clerk if you want the fastest setup, prebuilt UI components, and built-in user management features such as organizations, session management, and administrative tooling.
Choose Auth.js v5 if you want full control over your data, no vendor lock-in, and you're comfortable building your own UI and database schema.

Now let's get into why.

What Changed: NextAuth Became Auth.js

If you haven't followed the project closely, here's the short version:

The package is still installed as next-auth on npm, but the project rebranded to Auth.js and now also supports frameworks beyond Next.js (SvelteKit, Express, etc.) through @auth/core.
v5 is a full rewrite. The old pages/api/auth/[...nextauth].ts + authOptions pattern is gone. Everything is now exported from a single NextAuth() call.
Auth.js is no longer an independent project — it's now maintained under Better Auth Inc., after Better Auth (a newer, fast-growing auth library) effectively absorbed the project.

// auth.ts
import NextAuth from "next-auth";
import GitHub from "next-auth/providers/github";

export const { auth, handlers } = NextAuth({
  providers: [GitHub],
});

// app/api/auth/[...nextauth]/route.ts
import { handlers } from "@/auth";
export const { GET, POST } = handlers;

// proxy.ts
export { auth as proxy } from "@/auth";

No more separate getServerSession() import — you just call auth() anywhere on the server.

What Changed: Clerk

Clerk hasn't rewritten its API the way Auth.js did, but a few things are different from what older tutorials show:

Middleware is now proxy.ts in Next.js 16 (it was middleware.ts in Next.js ≤15 — same code, new filename).
Clerk ships a <Show when="signed-in"> / <Show when="signed-out"> component pattern now, replacing the older <SignedIn> / <SignedOut> components in newer examples.
The free tier was raised to 50,000 monthly active users, making it viable for a lot more side projects and early-stage SaaS apps than it used to be.

// proxy.ts
import { clerkMiddleware } from "@clerk/nextjs/server";

export default clerkMiddleware();

export const config = {
  matcher: [
    "/((?!_next|[^?]*\\.(?:html?|css|js(?!on)|jpe?g|webp|png|gif|svg|ttf|woff2?|ico|csv|docx?|xlsx?|zip|webmanifest)).*)",
    "/(api|trpc)(.*)",
    "/__clerk/(.*)",
  ],
};

By default clerkMiddleware() doesn't protect anything — you opt routes into protection explicitly, which is worth knowing before you assume your dashboard is locked down.

Setup Time

This is still the biggest practical difference.

Clerk: install the package, drop your publishable/secret keys into .env, add clerkMiddleware() to proxy.ts, wrap your layout in <ClerkProvider>. You get a working sign-in/sign-up flow, hosted by Clerk's Account Portal, in well under 15 minutes — no database, no schema, no email provider setup.

npm install @clerk/nextjs

Auth.js v5: install the package, create auth.ts, set up a route handler, configure a database adapter if you want persistent sessions (Prisma, Drizzle, etc.), and build your own sign-in UI since Auth.js ships no components. Realistically an hour or more for a first-time setup, more if you're also wiring up a database.

npm install next-auth@beta

If you're optimizing purely for "ship the login screen today," Clerk wins. If you're fine writing more code in exchange for control, Auth.js works.

Customization & Branding

Clerk gives you prebuilt components (<SignIn />, <SignUp />, <UserButton />) that are themeable but still recognizably Clerk's UI unless you build fully custom flows using their lower-level APIs.
Auth.js gives you zero UI. You design every form, every error state, every redirect. More work, but your auth pages look exactly like the rest of your app with no extra effort to "de-Clerk" them.

If brand consistency matters a lot (e.g. an enterprise client app), Auth.js or a fully custom Clerk flow both work — Clerk's default components just need more styling effort to disappear into your design system.

Data Ownership & Vendor Lock-In

Clerk stores your users on its infrastructure. You get a dashboard, audit logs, and organization management for free, but your user data lives outside your own database unless you sync it via webhooks.
Auth.js stores sessions and users wherever you point your adapter — your own Postgres, MySQL, MongoDB, whatever. You own the schema and the data outright.

For SaaS products where "we never see our own user data" is a hard no from a client or compliance team, Auth.js (or self-hosted alternatives like Better Auth) is the safer default.

Security: The Middleware Caveat

Worth knowing regardless of which library you pick: middleware-only session protection in Next.js has had a documented bypass (CVE-2025-29927), where a spoofed x-middleware-subrequest header could skip middleware checks entirely. Next.js patched it, but it's a good reminder not to rely on proxy.ts alone.

Practical takeaway for both libraries:

Re-verify the session inside Server Actions and Route Handlers, not just in proxy.ts.
Treat proxy-level redirects as a UX nicety, not your only security boundary.

// inside a Server Action, regardless of auth library
const session = await auth(); // or currentUser() for Clerk

if (!session) {
  return { error: "Unauthorized" };
}

Pricing

	Clerk	Auth.js (v5)
License	Free up to 50,000 MAU, paid tiers after	Free, open source
Hosting cost	None for auth itself	You pay for your own DB/hosting
Hidden costs	Add-ons (orgs, billing) may cost extra at scale	Dev time to build what Clerk gives free

Auth.js is "free" in license terms, but you're trading subscription cost for development time — building your own password reset flow, email verification, and admin tooling isn't free, it's just paid in hours instead of dollars.

Feature Comparison

Feature	Clerk	Auth.js v5
Setup Time	⭐⭐⭐⭐⭐	⭐⭐⭐
Prebuilt UI	Yes	No
Data Ownership	Hosted by Clerk	Fully yours
Organizations / Teams	Built-in	Build it yourself
OAuth Providers	Built-in, dashboard config	Built-in, code config
Customization	Good, more work for full control	Full, by default
Best For	MVPs, SaaS, fast launches	Apps needing full data ownership
Maintenance	Low	Medium

When Should You Use Clerk?

You're building an MVP and want auth solved in an afternoon.
You need organizations/teams (B2B SaaS) without building that system yourself.
You're under the 50K MAU free tier and want to stay focused on your actual product.

When Should You Use Auth.js v5?

You're migrating an existing NextAuth v4 codebase (in which case, this is still your path forward).
Data residency or compliance requirements mean user data must live in your own database.
You want to avoid per-user authentication pricing as you scale.

Note: if you're starting completely fresh with no NextAuth history, it's worth also looking at Better Auth, since it's now the team behind Auth.js itself and is increasingly positioned as the recommended path for new self-hosted projects.

Final Recommendation

For most freelance and SaaS MVP work in 2026, Clerk remains the fastest way to ship, especially if the project needs organizations or billing-adjacent auth features later. Auth.js v5 is the right call when a client specifically needs full ownership of user data, or when you're maintaining a codebase that already has NextAuth baked in.

Neither choice is permanent — plenty of teams start with Clerk to validate an idea and migrate to a self-hosted option once they have real scale and real requirements.

Useful Resources

Continue Learning

If you'd like a full step-by-step implementation guide, check out: