NextAuth (Auth.js) vs Clerk in 2026: Compared

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 retained 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.

What About Better Auth?

Since Better Auth now maintains Auth.js — and, as of July 2026, Vercel now owns Better Auth itself — it's worth a direct look rather than the one-line mention this comparison used to give it. For the full dedicated breakdown, see Auth.js vs Better Auth; the summary below covers how it stacks up against Clerk specifically.

What it is: an open-source, self-hosted TypeScript auth library — you run it against your own database (Postgres, MySQL, SQLite, MongoDB, or anything Drizzle/Prisma supports), and there's no third-party service holding your users at all. Framework-agnostic (Next.js, Nuxt, any Node.js backend), unlike Clerk or Auth.js which are both Next.js-first.

How it compares to the two libraries above:

Vs. Clerk: same trade-off as Auth.js — you give up prebuilt UI and a hosted dashboard in exchange for full data ownership and no per-user pricing, ever. The core library is free under the MIT license; you only pay for your own database hosting, and that cost barely moves whether you have 5,000 users or 500,000.
Vs. Auth.js v5: a materially different session model. Auth.js defaults to JWT sessions; Better Auth stores sessions directly in your database, which means instant revocation — force-logout a user and it takes effect immediately, no waiting on token expiry. (If you want the full breakdown of that trade-off, see Session vs JWT in Next.js 16.) Setup is also faster in practice — Better Auth's CLI scaffolds your database schema automatically, putting a working integration around 30 minutes rather than the hour-plus Auth.js typically takes for a first-time setup with a database adapter.

Where it's genuinely stronger: 2FA, passkeys, RBAC, and multi-tenant organizations are all available through Better Auth's official plugin system — Auth.js requires bolting these on yourself or reaching for a third-party provider. It's also the only one of the three actively gaining new features month over month as of 2026.

Where it's weaker: you inherit the full security and maintenance burden Clerk would otherwise carry for you. The one point worth knowing: on Next.js 15.1 and earlier, middleware.ts defaulted to the Edge Runtime, and Better Auth's full database-backed session check needed the (then experimental) Node.js middleware option to run there at all. That gap has closed — in Next.js 16, proxy.ts runs exclusively on the Node.js runtime for everyone, Clerk included, so this isn't a real trade-off anymore for anything built on the current version.

💡 Worth knowing before you follow the hype: Better Auth has real community momentum right now, but it's not universally smooth. One developer on r/nextjs summed up a common experience: they switched primarily because "all redditors recommended [it]," then hit missing features and unstable behavior, and concluded they "shouldn't follow the trends in Reddit too much without looking into it myself." Evaluate it against your actual requirements, not just its current popularity.

Choose Better Auth over both if: you want full data ownership and Clerk-level modern features (passkeys, 2FA, orgs) without vendor lock-in or per-user billing, and you're comfortable owning the operational and security burden that a hosted service like Clerk would otherwise take off your plate.

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 MRU, 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 MRU 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 reading the Better Auth section above before committing to Auth.js — for new self-hosted projects specifically, it's increasingly the stronger default.

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: