middleware.js
API reference for the middleware.js file.
The middleware.js|ts
file is used to write Middleware and run code on the server before a request is completed. Then, based on the incoming request, you can modify the response by rewriting, redirecting, modifying the request or response headers, or responding directly.
Middleware executes before routes are rendered. It's particularly useful for implementing custom server-side logic like authentication, logging, or handling redirects.
Use the file middleware.ts
(or .js) in the root of your project to define Middleware. For example, at the same level as app
or pages
, or inside src
if applicable.
Exports
Middleware function
The file must export a single function, either as a default export or named middleware
. Note that multiple middleware from the same file are not supported.
Config object (optional)
Optionally, a config object can be exported alongside the Middleware function. This object includes the matcher to specify paths where the Middleware applies.
Matcher
The matcher
option allows you to target specific paths for the Middleware to run on. You can specify these paths in several ways:
- For a single path: Directly use a string to define the path, like
'/about'
. - For multiple paths: Use an array to list multiple paths, such as
matcher: ['/about', '/contact']
, which applies the Middleware to both/about
and/contact
.
Additionally, the matcher
option supports complex path specifications through regular expressions, such as matcher: ['/((?!api|_next/static|_next/image|.*\\.png$).*)']
, enabling precise control over which paths to include or exclude.
The matcher
option accepts an array of objects with the following keys:
source
: The path or pattern used to match the request paths. It can be a string for direct path matching or a pattern for more complex matching.regexp
(optional): A regular expression string that fine-tunes the matching based on the source. It provides additional control over which paths are included or excluded.locale
(optional): A boolean that, when set tofalse
, ignores locale-based routing in path matching.has
(optional): Specifies conditions based on the presence of specific request elements such as headers, query parameters, or cookies.missing
(optional): Focuses on conditions where certain request elements are absent, like missing headers or cookies.
Configured matchers:
- MUST start with
/
- Can include named parameters:
/about/:path
matches/about/a
and/about/b
but not/about/a/c
- Can have modifiers on named parameters (starting with
:
):/about/:path*
matches/about/a/b/c
because*
is zero or more.?
is zero or one and+
one or more - Can use regular expression enclosed in parenthesis:
/about/(.*)
is the same as/about/:path*
Read more details on path-to-regexp documentation.
Good to know:
- The
matcher
values need to be constants so they can be statically analyzed at build-time. Dynamic values such as variables will be ignored. - For backward compatibility, Next.js always considers
/public
as/public/index
. Therefore, a matcher of/public/:path
will match.
Params
request
When defining Middleware, the default export function accepts a single parameter, request
. This parameter is an instance of NextRequest
, which represents the incoming HTTP request.
Good to know:
NextRequest
is a type that represents incoming HTTP requests in Next.js Middleware, whereasNextResponse
is a class used to manipulate and send back HTTP responses.
NextResponse
The NextResponse
API allows you to:
redirect
the incoming request to a different URLrewrite
the response by displaying a given URL- Set request headers for API Routes,
getServerSideProps
, andrewrite
destinations - Set response cookies
- Set response headers
To produce a response from Middleware, you can:
rewrite
to a route (Page or Edge API Route) that produces a response- return a
NextResponse
directly. See Producing a Response
Execution order
Middleware will be invoked for every route in your project. Given this, it's crucial to use matchers to precisely target or exclude specific routes. The following is the execution order:
headers
fromnext.config.js
redirects
fromnext.config.js
- Middleware (
rewrites
,redirects
, etc.) beforeFiles
(rewrites
) fromnext.config.js
- Filesystem routes (
public/
,_next/static/
,pages/
,app/
, etc.) afterFiles
(rewrites
) fromnext.config.js
- Dynamic Routes (
/blog/[slug]
) fallback
(rewrites
) fromnext.config.js
Runtime
Middleware defaults to using the Edge runtime. As of v15.2 (canary), we have experimental support for using the Node.js runtime. To enable, add the flag to your next.config
file:
Then in your middleware file, set the runtime to nodejs
in the config
object:
Note: This feature is not yet recommended for production use. Therefore, Next.js will throw an error unless you are using the next@canary release instead of the stable release.
Advanced Middleware flags
In v13.1
of Next.js two additional flags were introduced for middleware, skipMiddlewareUrlNormalize
and skipTrailingSlashRedirect
to handle advanced use cases.
skipTrailingSlashRedirect
disables Next.js redirects for adding or removing trailing slashes. This allows custom handling inside middleware to maintain the trailing slash for some paths but not others, which can make incremental migrations easier.
skipMiddlewareUrlNormalize
allows for disabling the URL normalization in Next.js to make handling direct visits and client-transitions the same. In some advanced cases, this option provides full control by using the original URL.
Examples
Conditional Statements
Using Cookies
Cookies are regular headers. On a Request
, they are stored in the Cookie
header. On a Response
they are in the Set-Cookie
header. Next.js provides a convenient way to access and manipulate these cookies through the cookies
extension on NextRequest
and NextResponse
.
- For incoming requests,
cookies
comes with the following methods:get
,getAll
,set
, anddelete
cookies. You can check for the existence of a cookie withhas
or remove all cookies withclear
. - For outgoing responses,
cookies
have the following methodsget
,getAll
,set
, anddelete
.
Setting Headers
You can set request and response headers using the NextResponse
API (setting request headers is available since Next.js v13.0.0).
Good to know: Avoid setting large headers as it might cause 431 Request Header Fields Too Large error depending on your backend web server configuration.
CORS
You can set CORS headers in Middleware to allow cross-origin requests, including simple and preflighted requests.
Producing a response
You can respond from Middleware directly by returning a Response
or NextResponse
instance. (This is available since Next.js v13.1.0)
Negative matching
The matcher
config allows full regex so matching like negative lookaheads or character matching is supported. An example of a negative lookahead to match all except specific paths can be seen here:
You can also bypass Middleware for certain requests by using the missing
or has
arrays, or a combination of both:
waitUntil
and NextFetchEvent
The NextFetchEvent
object extends the native FetchEvent
object, and includes the waitUntil()
method.
The waitUntil()
method takes a promise as an argument, and extends the lifetime of the Middleware until the promise settles. This is useful for performing work in the background.
Unit testing (experimental)
Starting in Next.js 15.1, the next/experimental/testing/server
package contains utilities to help unit test middleware files. Unit testing middleware can help ensure that it's only run on desired paths and that custom routing logic works as intended before code reaches production.
The unstable_doesMiddlewareMatch
function can be used to assert whether middleware will run for the provided URL, headers, and cookies.
The entire middleware function can also be tested.
Platform support
Deployment Option | Supported |
---|---|
Node.js server | Yes |
Docker container | Yes |
Static export | No |
Adapters | Platform-specific |
Learn how to configure Middleware when self-hosting Next.js.
Version history
Version | Changes |
---|---|
v15.2.0 | Middleware can now use the Node.js runtime (experimental) |
v13.1.0 | Advanced Middleware flags added |
v13.0.0 | Middleware can modify request headers, response headers, and send responses |
v12.2.0 | Middleware is stable, please see the upgrade guide |
v12.0.9 | Enforce absolute URLs in Edge Runtime (PR) |
v12.0.0 | Middleware (Beta) added |