URL regex tester
A general regex tester makes you supply the URLs and the pattern. This one ships the patterns — the loose one that is usually what you actually want, the strict one for validation, the one that finds URLs inside prose — and tests them against your list at once, so you can see the false positives instead of discovering them in production.
Summary
How to use
- Pick a Preset to load a working pattern, then edit it — starting from something that works beats starting from a blank box.
- Choose a Mode. Test answers "is this line a URL?" and is what validation needs. Match extracts every occurrence per line, which is what you want when pulling URLs out of text.
- Set Flags.
ifor case-insensitive is on by default;gis added automatically in Match mode. - Paste your test lines — include the awkward cases deliberately: trailing punctuation, a URL in brackets, an IP address, a URL with no scheme.
- Rows are green where the pattern matched and red where it did not, so scanning for false positives and negatives is quick. Copy matching lines gives you just the hits.
Why "the" URL regex does not exist
The RFC 3986 grammar can be expressed as a regex, and the result is around 300 characters that will match things you do not consider URLs (a:b is a valid URI) while rejecting things you do (example.com/page, with no scheme). So the right pattern depends entirely on the job:
Validating user input? Do not use a regex at all — use the URL parser. try { new URL(s) } catch {} in JavaScript, urllib.parse in Python, net/url in Go. Each is the actual specification, maintained by people who read the RFCs, and it will not be defeated by an input you did not think of. Use a regex afterwards only to enforce your own extra rules — "must be https", "must be on our domain".
Finding URLs in text? A regex is the right tool, and the hard part is where to stop. A URL at the end of a sentence should not swallow the full stop; one inside parentheses should not swallow the closing bracket — but a Wikipedia URL legitimately contains balanced parentheses. The Find URLs inside prose preset ends on a character class that excludes trailing punctuation, which handles the common cases and will still occasionally be wrong. That is the nature of the problem, not a bug in the pattern.
Matching in a router or a firewall rule? Anchor with ^ and $ and be as specific as you can. An unanchored pattern in a security rule is how path-traversal and open-redirect bypasses happen: ^\/admin matches /admin but a rule for \/admin alone also matches /public/admin-preview.
One performance note: nested quantifiers over character classes that can match the same text — the classic (a+)+ shape — can take exponential time on a crafted input. If a pattern like that reaches a server-side route matcher, it is a denial-of-service vector. Keep the patterns you deploy simple and anchored.
FAQ
Which regex flavour is this?
JavaScript's, because it runs in your browser. It is close enough to PCRE for URL patterns that they usually transfer directly — the differences appear in lookbehind support (JavaScript has it in modern browsers), named groups syntax, and Unicode property escapes.
Why does my pattern with g behave oddly in Test mode?
Because a global regex carries lastIndex between calls, which makes repeated test() calls stateful. Test mode strips g for exactly that reason; Match mode adds it, since matching all occurrences needs it.
Can I see capture groups?
Yes — in Match mode the third column lists them per match, separated by ·. Groups that did not participate show as —.
Is there a limit?
The first 500 lines are shown, and each line's match loop is capped at 200 matches so a zero-width pattern cannot hang the tab.