Next.js Middleware is a function that runs before a request is processed — intercepting it at the network edge before it reaches your pages, layouts, or API routes. It can rewrite, redirect, modify headers, or short-circuit requests entirely. Unlike API routes which run after routing is resolved, Middleware runs at the Edge Runtime — closer to the user — making it faster and more powerful for request interception logic.
Middleware sits between the incoming request and your application. It runs on every matched request before Next.js resolves which page or route handler to serve. Because it runs at the Edge — on Vercel's global edge network or a Node.js edge-compatible runtime — it executes with extremely low latency, often before the request ever reaches your server. This makes it the perfect place for auth checks, redirects, rewrites, locale detection, A/B testing, and bot protection.
Runs at the Edge Runtime — NOT in the Node.js server runtime by default
Executes BEFORE the request reaches pages, layouts, or route handlers
Runs on every request that matches the middleware matcher config
On Vercel — runs on the global edge network closest to the user
Self-hosted — runs in a lightweight V8 isolate before the Next.js server
Executes after the cache check — cached responses bypass middleware
Middleware runs BEFORE routing — API routes run AFTER routing is resolved
Middleware runs on Edge Runtime — API routes run on Node.js runtime by default
Middleware cannot use Node.js APIs (fs, crypto, etc) — API routes can
Middleware cannot connect to databases directly — API routes can
Middleware runs on EVERY matched request automatically — API routes only on explicit calls
Middleware can rewrite and redirect requests — API routes cannot change routing
Middleware can modify request headers before they reach route handlers — API routes cannot
Middleware has no access to request body — API routes can read full request body
Middleware is ideal for cross-cutting concerns — API routes are for business logic
Middleware response time is critical (must be fast) — API routes can be slower
Cannot use Node.js built-in modules (fs, path, crypto, Buffer)
Cannot make database connections (no Prisma, Mongoose, pg directly)
Cannot read the request body — only headers, cookies, and URL
Cannot use most npm packages that rely on Node.js APIs
Cannot exceed the 1MB size limit for the middleware bundle
Cannot run long or async operations — must respond quickly
Cannot access the file system
Cached pages may bypass middleware depending on cache configuration
Authentication and session validation before serving protected pages
Redirects and rewrites based on URL, headers, cookies, or geo data
A/B testing — serving different page variants without URL change
Locale and i18n detection — redirecting to correct language route
Security headers — adding CSP, X-Frame-Options on every response
Bot detection and basic rate limiting
Feature flags — routing users to different variants
Injecting request context (user ID, tenant ID) into headers for downstream use