URLS & ROUTING

URL pattern testersee where the match fails

Test one pattern against a URL on each line. Choose URLPattern or the path-only route adapter below.

URL pattern tester

Pattern

Candidate URLs

URLs and patterns are processed in this browser. Entered URLs are never requested.

Matching results

Enter at least one candidate URL.

Matching options

URLPattern: * matches any value; an empty field matches an empty component. Details show independent component captures, even if the whole URL misses.

Base URL resolves relative candidates and relative string patterns. It does not constrain component-mode patterns.

Limits: 512 units per pattern/component, 200 URLs, 2,048 per URL/base, 131,072 total UTF-16 units; 2-second worker budget.

Results are outdated or being calculated.

A route looks correct until a different host, encoded parameter or trailing slash changes the result. This URL pattern tester keeps successful and failing cases together, so changing one component gives you evidence about the actual boundary.

Use the URLPattern API tester for whole addresses and the route pattern tester for pathname rules. Both run the selected dependency directly. A URL route matcher cannot tell you whether an endpoint exists or which handler a server will choose.

Why use this URL pattern tester

Pinpoint the component that disagrees

The URL pattern tester separates an overall match from eight independent component diagnostics. A host can fail while the pathname still captures an id. That partial capture remains diagnostic evidence; it is not reported as a successful whole-URL exec result.

A pattern connected to three candidate rows, with one component failing in the middle row.

Distinguish whole addresses from paths

A URLPattern hostname restriction excludes another origin. The route adapter reads only pathname, so the same path on that origin can match. Keeping both cases makes the engine choice visible before a pattern reaches an application.

Two identical candidate lists: full-address matching rejects the different host, while path-only matching accepts both.

Choose the semantics before changing the pattern

01

Start with explicit components

The default component mode gives every field a value. Use * for any value; clearing a field requires an empty component. The base resolves candidate URLs here and does not silently supply host restrictions.

02

Choose a route engine deliberately

Select path-to-regexp v8 for Express 5 path syntax. It exposes end, trailing and parameter decoding separately. A mode switch preserves your stored pattern and component inputs; it does not translate between grammars.

03

Export only a current run

Automatic testing waits 350 ms after edits. Disable it to use the button or Ctrl/Cmd + Enter. Editing immediately disables old exports. Expand component details on a miss, then copy the report when testing finishes.

Inspect the parts behind each result

Versioned matching engines

The URL pattern tester uses urlpattern-polyfill 10.1.0 and path-to-regexp 8.4.2. The report records engine, version, inputs and options. All browsers use the pinned polyfill, so this is not a probe of the browser’s native URLPattern implementation.

Captures retain their structure

URLPattern groups stay grouped by URL component and preserve encoded values. Optional captures are exported as null. The route engine normally decodes parameters; named wildcards return arrays, while disabling decoding preserves their raw strings.

Resolved addresses remain inspectable

Relative candidates use the explicit base URL. Results show the original input beside its normalized address when they differ, including default-port removal and dot-segment resolution. Changing the base can change a candidate before any matching happens.

Failures remain separate from misses

Invalid URLs and parameter decoding errors retain their original line numbers, while valid rows continue. Pattern compilation errors stop the run. Results appear 50 at a time; JSON export includes every row, including errors and negative cases.

What this experiment includes

Two grammars, no automatic conversion
URLPattern supports optional :id? groups and regex constraints such as :id(\d+). Version 8 route patterns use braces for optional parts and named wildcards such as *path. Old route syntax can produce a compilation error instead of a miss.
Query matching is ordered
URLPattern search checks a string without the leading question mark; hash excludes its leading #. Parameters are not sorted or compared as maps. The route adapter ignores both query and fragment, along with every component except pathname.
Normalization comes before matching
The URL parser canonicalizes candidate hosts, default ports and dot segments. URLPattern captures are not additionally decoded. A route parameter containing malformed percent encoding produces a row error when decoding is enabled; disable decoding to inspect the encoded value.
One rule, finite candidate text
Blank lines are skipped; duplicates, spaces and original line numbers remain in the report. Control characters and malformed Unicode are rejected. The URL parser may normalize surrounding spaces, which stays visible through the original and resolved forms.
Bounded computation
Each pattern or component is limited to 512 UTF-16 units, with 200 nonempty URLs of up to 2,048 units each and 131,072 combined input units. The base shares the 2,048-unit URL limit. A worker exceeding 2 seconds is stopped, with no partial success report.
No framework or server simulation
Only the listed route dependency is implemented. HTTP methods, middleware, route order and other frameworks are outside this test. There is no URL fetching, rewriting, file import, saved history or sharing of input through page links.

URL pattern tester questions

Does the order of search parameters matter?

Yes. The search component is a sequence, so a=1&b=2 and b=2&a=1 are different strings. Use a pattern that describes the order you expect; this tool does not turn the query into an unordered parameter map.

Is matching case-sensitive?

The tool starts with ignoreCase off. Enable it to change path and other pattern comparisons. Hostnames are already canonicalized by URL parsing, so an uppercase hostname alone is not a useful test of case-sensitive pathname matching.

Why is the default port missing from captures?

A URL such as https://example.com:443/users/42 is normalized with an empty port. A required named port group cannot capture 443 from that empty component. Inspect the normalized address and the effective port pattern.

How does URLPattern differ from path-to-regexp v8?

URLPattern checks eight URL components and uses its own standard grammar. The v8 adapter checks pathname only, uses braces for optional segments and requires names after wildcard stars. Selecting it does not simulate an Express request or application configuration.

Why does adding a trailing slash change a match?

URLPattern does not add an optional slash to a literal pathname. For example, /users/:id does not match /users/42/. The route adapter allows a trailing delimiter by default; switch that option off to require a stricter ending.

Have an unexpected route case?

Try a positive and a negative case

Keep a URL you expect to match beside one you expect to fail. Change one constraint and inspect both rows before saving the report.