Route Pattern to Regex Converter

Turn a web route pattern into a regular expression. Path placeholders in the Express/Laravel style — :id and {slug} — become capture groups, an optional ? marks a segment optional, and * becomes a catch-all. A built-in tester lets you type a URL path and see instantly whether it matches and what each parameter captures. Everything runs in your browser.

How to use the Route Pattern to Regex Converter

Type a route pattern in the top box and the matching regular expression appears below, updating as you type. Use the same placeholder syntax routers use: :name or {name} for a single-segment parameter, a trailing ? such as :id? or {id?} to make that segment optional, and * for a catch-all that matches the rest of the path. Everything else is treated as literal text and is escaped so characters like dots match themselves.

Three options shape the output. Named groups emits (?<name>...) so captures are accessible by name; turn it off for plain numbered groups. Anchor with ^ and $ wraps the expression so it must match the whole path rather than just part of it. Allow optional trailing slash lets a path match with or without a final /. Use the Copy button on the result to grab the regex.

The Test a path box runs the generated regex against a sample URL path live: it tells you whether the path matches and lists every captured parameter with its value, so you can confirm the pattern behaves before you paste it into your router or code. It all runs in your browser — instant, offline, and nothing is uploaded.

Route patterns and the regex behind them

Web frameworks let you describe a URL with a route pattern rather than a raw regular expression. A pattern like /users/:id/posts/:slug is far easier to read and write than its regex equivalent, and almost every framework — Express, Laravel, Ruby on Rails, Flask, ASP.NET, and others — offers some version of this shorthand. Under the hood, though, the router compiles that friendly pattern into a regular expression and uses it to match incoming request paths and to pull out the variable parts. This tool performs that same compilation in the open, so you can see exactly what your pattern becomes and reuse the regex anywhere a route abstraction is not available — a redirect rule, a log parser, an API gateway, or a quick script.

The core idea is that a pattern is mostly literal text with a few special placeholders punched into it. The literal parts must match exactly, so they are escaped: a dot in /file.json becomes \. so it matches a real dot and not "any character". The placeholders are where the variation lives. A named parameter — written :id in the colon style or {id} in the brace style — stands for a single path segment and compiles to a capture group like ([^/]+), meaning "one or more characters that are not a slash". The negated slash is important: it stops one parameter from greedily swallowing the segments meant for the next, so /users/:id/posts/:slug splits the path cleanly at each boundary. With named groups enabled the capture becomes (?<id>[^/]+), letting your code read match.groups.id instead of counting positions.

Two more constructs handle common routing needs. An optional segment, marked with a trailing question mark, has to make the preceding slash optional too — otherwise a missing segment would leave a dangling separator — so /users/:id? compiles to /users(?:/([^/]+))?, matching both /users and /users/42. A wildcard * becomes (.*), a catch-all that, unlike a normal parameter, does cross slashes; it is how frameworks express "serve any file under this prefix" or a 404 fall-through. Finally, anchoring with ^ and $ decides whether the path must match in full. Routers always anchor, because /users should not accidentally match /users-admin; this tool anchors by default but lets you turn it off when you want a partial match. Seeing all of this spelled out — and testing it against real paths — demystifies what is otherwise hidden inside the framework.

Common use cases

  • Redirects and rewrites. Turn a route into the regex an Nginx, Apache, or CDN rule expects.
  • Outside the framework. Reuse a route's matching logic in a script, log parser, or gateway.
  • Learning and debugging. See exactly what your framework compiles a pattern into.
  • Validation. Test sample paths against a pattern to confirm parameters capture correctly.

Frequently asked questions

Which placeholder styles are supported?
Both the colon style (:id) and the brace style ({id}) for named single-segment parameters, a trailing ? to make a segment optional, and * for a catch-all that matches the rest of the path. Everything else is treated as literal text.

Why does a parameter use [^/] instead of a dot?
A route parameter matches one path segment, so it must stop at the next slash. Using [^/]+ ("anything but a slash") keeps each parameter from swallowing later segments. A * wildcard, by contrast, compiles to (.*) and does cross slashes.

What does an optional segment compile to?
A trailing ? pulls the preceding slash into an optional group, so /users/:id? becomes /users(?:/([^/]+))? and matches both /users and /users/42. Without that, a missing segment would leave a stray slash.

Is the regex compatible with my language?
The output uses standard constructs that work in JavaScript, PCRE, Python, and most engines. Named groups use the (?...) syntax; if your engine prefers (?P...), turn named groups off or adjust the prefix.