Stop hand-translating your redirects between platforms.
Paste your next.config.js redirects, headers, or rewrites block and get the equivalent config for Netlify, Vercel, or Nitro instantly.
How RedirectConverter works
- 1
Paste your next.config.js block
Paste the full async function (e.g. async redirects() { return [...] }) or just the returned array. The tool accepts redirects, headers, and rewrites blocks. Comments and trailing commas are handled automatically.
- 2
Select the rule type
Choose Redirects, Headers, or Rewrites, or leave it on "Auto-detect." The tool detects the type from the function name or from the shape of the objects (presence of a headers array, permanent field, etc.).
- 3
Pick your target format
Choose between netlify.toml (Netlify), vercel.json (Vercel), or nitro.config.ts (Nitro, used by TanStack Start, Nuxt, and other Nitro-based frameworks).
- 4
The parser extracts your rules
A restricted JavaScript object literal parser (not eval) tokenizes your input, handles unquoted keys and single-quoted strings, and produces a structured array of rule objects.
- 5
Path patterns are translated
Next.js path patterns like :path* are converted to the target format's equivalent: * and :splat for Netlify, ** for Nitro. Named parameters like :slug are preserved where the target supports them.
- 6
Output, mapping table, and warnings
You get the complete converted config with a copy button, a per-rule mapping table showing how each input rule translated, and warnings for any rules that don't convert cleanly (e.g. conditional 'has' matching).
What each target format looks like
The same redirect rule produces different syntax depending on the target platform. Here is how a simple permanent redirect from /old to /new looks in each format.
[[redirects]]
from = "/old"
to = "/new"
status = 301{
"redirects": [
{
"source": "/old",
"destination": "/new",
"permanent": true
}
]
}export default defineNitroConfig({
routeRules: {
'/old': { redirect: { to: '/new', statusCode: 301 } },
},
})Path pattern translation reference
Next.js, Netlify, and Nitro use different syntax for dynamic path segments and wildcards. This table shows how RedirectConverter maps each pattern.
| Next.js pattern | Netlify | Vercel | Nitro |
|---|---|---|---|
| /blog/:slug | /blog/:slug | /blog/:slug | /blog/* |
| /docs/:path* | /docs/* | /docs/:path* | /docs/** |
| /(.*) | /* | /(.*) | /** |
| /static/file | /static/file | /static/file | /static/file |
Vercel uses the same path syntax as Next.js (both are Vercel products), so redirect rules transfer with minimal changes. Netlify uses * for catch-all and :splat in the destination. Nitro uses ** for recursive glob matching.
When to use RedirectConverter
| Scenario |
|---|
| Migrating from Next.js to TanStack Start |
| Moving from Vercel to Netlify hosting |
| Moving from Netlify to Vercel hosting |
| Consolidating security headers for a Nitro deploy |
| Verifying manual translation of redirect rules |
| API proxy migration (rewrites to Nitro proxy) |
What does not convert cleanly between platforms
Next.js, Netlify, Vercel, and Nitro do not share a redirect model, so some rules have no exact equivalent. The converter flags these rather than guessing, because a silently wrong redirect is worse than one you were told to check.
Regex path matching
Next.js supports full regex constraints on a segment. Netlify's _redirects and netlify.toml use splats and placeholders with no regex support at all. Anything relying on a character class or a quantifier has to be rewritten as a broader rule plus a check in the handler.
Conditional rules based on headers or cookies
The has and missing conditions in Next.js map onto Netlify's conditions only for a narrow set of cases, mostly language and country. Cookie-value and arbitrary-header conditions generally need edge middleware on the target platform instead of a static rule.
Rule ordering and specificity
Every platform evaluates top to bottom, but they disagree about whether a more specific later rule can win. After converting, check that a catch-all near the bottom has not swallowed a specific rule that used to match first.
Status codes beyond 301 and 302
permanent: true and false cover the common pair. If you rely on 307, 308, or a 200-with-rewrite to preserve the request method, confirm the generated rule kept it, since a method-changing redirect will break POST requests in a way that is easy to miss in testing.
Frequently Asked Questions
What is RedirectConverter and how does it work?
RedirectConverter is a free browser tool that converts redirect, header, and rewrite rules from Next.js's next.config.js format into the equivalent config for Netlify (netlify.toml), Vercel (vercel.json), or Nitro (nitro.config.ts, used by TanStack Start and Nuxt).
Paste your config block, select a target format, and the tool parses the JavaScript object literal, maps each rule to the target platform's syntax (including path pattern translation), and generates the complete output with a per-rule mapping table.
How do Next.js redirects differ from Netlify redirects?
| Next.js (next.config.js) | Netlify (netlify.toml) | |
|---|---|---|
| Format | JavaScript objects in an async function | TOML key-value pairs |
| Path params | :slug, :path* | :slug works, :path becomes / :splat |
| Status codes | permanent: true/false or statusCode | Explicit status field (301, 302, 200) |
| Conditional matching | has/missing (header, cookie, query) | Not supported in standard redirects |
| Rewrites | Separate rewrites() function | Redirect with status = 200 |
Does RedirectConverter send my config anywhere?
No. All parsing and conversion runs in JavaScript inside your browser. Nothing leaves your machine. The tool has no backend, no API calls, and no analytics on the config you paste.
How do I convert Next.js redirects to Nitro routeRules for TanStack Start?
Select 'nitro.config.ts' as the target format and paste your next.config.js redirects block. RedirectConverter converts each rule to Nitro's routeRules syntax, translating path patterns (e.g. :path becomes *) and status codes.
export default defineNitroConfig({
routeRules: {
'/old-path': { redirect: { to: '/new-path', statusCode: 301 } },
'/docs/**': { redirect: { to: '/new-docs/**', statusCode: 302 } },
},
})What happens to 'has' and 'missing' conditions during conversion?
Next.js supports conditional redirects that only trigger when a specific header, cookie, query parameter, or host matches. Not all platforms support this.
| Platform | Condition support |
|---|---|
| Vercel (vercel.json) | Full support: has/missing fields carry over directly |
| Netlify (netlify.toml) | Not supported: conditions are stripped with a warning |
| Nitro (nitro.config.ts) | Not supported: conditions are stripped with a warning |
When converting to Netlify or Nitro, RedirectConverter includes a warning for every rule that uses conditions, so you know exactly which rules need manual attention.
What input formats does RedirectConverter accept?
You can paste any of these formats and the tool will extract the rules array automatically:
- The full async function:
async redirects() { return [...] } - Just the returned array:
[{ source: '...', destination: '...' }] - Config with comments: single-line (//) and multi-line (/ /) comments are stripped
- Single-quoted or double-quoted strings
- Trailing commas (standard in most JS configs)
Can I convert vercel.json to netlify.toml?
Yes, indirectly. Vercel's redirect format is nearly identical to Next.js's format (same source/destination/permanent fields). Paste the 'redirects' array from your vercel.json, select 'Redirects' as the rule type, choose netlify.toml as the target, and convert.
The same approach works for headers and rewrites arrays from vercel.json.