Regex for URL Validation — Test Your Patterns Online Before Shipping

URL validation is one of those things that looks simple until you test it. A pattern that matches https://example.com fails on https://example.co.uk/path?query=1#anchor. The one that handles that fails on ftp:// or data: URIs or international domain names.

This guide gives you tested URL regex patterns ranked by use case, explains the tradeoffs, and shows you how to verify them against your actual input before shipping. All patterns are ready to paste into the online tester.

Why URL Regex Is Hard to Get Right

URLs are defined by RFC 3986 and cover a huge space of valid inputs. A complete URL-matching regex is hundreds of characters long and still cannot handle every edge case. The right approach is to choose the strictest pattern that covers your actual use case.

The common failure modes:

• Too loose: matches garbage like http://, https://, or anything with a dot
• Too strict: rejects valid URLs with ports, query strings, anchors, or unusual TLDs like .museum
• Missing protocols: only matches http and https, breaking ftp, mailto, or data URLs
• Missing internationalized domains: fails on münchen.de or Punycode versions

For most web form validation, you want to catch obvious errors (no domain, missing protocol) without rejecting valid URLs from unusual domains or paths. Pick the right tier of strictness from the patterns below.

Tier 1: Basic http/https URL Validation

Use this when you need to validate that the user entered a web URL starting with http or https. Handles paths, query strings, and anchors. Rejects everything else.

^https?:\/\/(www\.)?[-a-zA-Z0-9@:%._+~#=]{1,256}\.[a-zA-Z0-9()]{1,6}\b([-a-zA-Z0-9()@:%_+.~#?&\/=]*)$

Test — should match:

• https://example.com
• http://www.example.co.uk/path/to/page
• https://sub.domain.example.com/path?query=1&other=2#section
• https://example.com:8080/path

Test — should NOT match:

• example.com (no protocol)
• http:// (no domain)
• ftp://example.com (not http/https)
• not a url at all

Sell Custom Apparel — We Handle Printing & Free Shipping

Tier 2: Looser Validation — Any Protocol

Use this when you need to accept ftp, mailto, or other protocol URLs alongside http/https.

^[a-zA-Z][a-zA-Z0-9+\-.]*:\/\/.+

This is intentionally loose — it validates the protocol format and requires :// followed by something. It will match ftp://files.example.com, mailto:[email protected] (actually, mailto does not use :// — see Tier 4), and even made-up protocols like custom://anything.

Good for: internal tools where you control the input and just need to block obvious non-URLs. Not good for: public-facing forms where users submit arbitrary text.

Tier 3: Domain-Only Validation (No Protocol Required)

Sometimes users enter just the domain without https://. This pattern validates domain format without requiring a protocol:

^(https?:\/\/)?(www\.)?[a-zA-Z0-9][a-zA-Z0-9\-]{0,61}[a-zA-Z0-9]\.[a-zA-Z]{2,}(\.[a-zA-Z]{2,})?(\/.*)?$

Matches: example.com, www.example.com, https://example.com, example.co.uk

Does not match: localhost, 192.168.1.1, just words

Use this on forms where you accept domain input and normalize it by prepending https:// if missing. Test extensively with your actual user data — domain validation patterns are notorious for edge cases.

How to Test Your URL Regex Against Real Edge Cases

Good URL regex testing requires intentional edge cases, not just obvious examples. Paste this test set into the tester and run your pattern against all of them:

Valid URLs to include:

• https://example.com — basic
• http://sub.domain.example.com/path/to/resource — subdomain + path
• https://example.co.uk/path?query=1&other=2#section — country TLD + query + fragment
• https://example.com:8080/api/v1 — port number
• https://user:[email protected] — credentials (if you need to support these)
• https://example.museum — unusual long TLD

Invalid inputs to reject:

• http:// — no domain
• https://.com — no domain before TLD
• example — single word
• just random text
• javascript:alert(1) — XSS attempt (check your pattern blocks this)

Frequently Asked Questions

Should I use regex or a URL parser for validation?

For most backend validation, use a URL parser library (the URL() constructor in JavaScript, urllib.parse in Python, System.Uri in C#). Parsers handle edge cases that regex cannot. Use regex for quick client-side checks or when a parser is not available.

Why does my URL regex fail on URLs with ports or query strings?

Most simple URL patterns do not account for port numbers (:8080), query strings (?key=value), or URL fragments (#anchor). Test your pattern against URLs with all of these components — the patterns in this guide include them.

How do I block javascript: URLs to prevent XSS?

Add a negative lookahead at the start: ^(?!javascript:)... This prevents any URL starting with javascript: from matching. Test with javascript:alert(1) and data:text/html, — both are common XSS vectors.