Protocol-Relative URL Regex
Validates a protocol-relative URL that omits the scheme and starts with //, such as //example.com/path, which inherits http or https from the page that references it.
Regex Pattern
^\/\/[\w-]+(\.[\w-]+)+(:\d+)?(\/[^\s]*)?$Pattern Breakdown
Hover over a token to see what it does.
| Token | Meaning |
|---|---|
| ^ | Anchors the match to the start of the string |
| \/\/ | Literal leading double slash marking a protocol-relative URL, with no scheme in front |
| [\w-]+(\.[\w-]+)+ | Hostname made of dot-separated labels, requiring at least one dot |
| (:\d+)? | Optional port number, e.g. :8080 |
| (\/[^\s]*)? | Optional path, query string, or fragment starting with a slash |
| $ | Anchors the match to the end of the string |
Detailed Explanation
What it does
This pattern validates protocol-relative URLs: references that begin with // and a hostname but omit an explicit http: or https: scheme, letting the browser reuse the scheme of the current page. It rejects both fully-qualified URLs with a scheme and root-relative paths with only a single leading slash.
Why it works
The pattern requires the string to start with exactly two slashes and then a dotted hostname, mirroring how a browser parses a protocol-relative reference. Because there is no https?: prefix expected, a URL that includes a scheme will not match starting at position zero, and because two literal slashes are required up front, a plain single-slash relative path is also excluded.
Common use cases
- Validating third-party asset URLs (scripts, stylesheets, images) that are commonly written in protocol-relative form
- Normalizing user-submitted links before prefixing them with the current page's scheme
- Auditing a codebase for protocol-relative URLs, which are now discouraged in favor of explicit https
- Parsing legacy CDN configuration values that still use the // shorthand
Edge cases
- A protocol-relative URL with a port, like //example.com:8080/path, is matched
- A bare protocol-relative host with no path, like //example.com, is matched
- URLs with an explicit scheme, like https://example.com, are rejected because the scheme text appears where the pattern expects the second slash
- A single leading slash without a second one, like /example.com, is rejected since two literal slashes are required
- Triple slashes, like ///path, are rejected because the third slash cannot satisfy the hostname character class
Limitations
- Does not validate that the resulting URL, once a scheme is prefixed, is otherwise well-formed beyond the host and path shape
- Does not support IPv4 or IPv6 literal hosts without modification
- Cannot verify the host resolves or that the resource is reachable
- Protocol-relative URLs are a deprecated pattern in modern web development; this regex only recognizes the syntax, it does not discourage its use
Interactive Tester
Edit the pattern or text below — matching runs live in your browser.
Test Cases
Editable — add your own inputs to see if they pass.
| Input | Expected | Result | |
|---|---|---|---|
| Pass | |||
| Pass | |||
| Pass | |||
| Pass | |||
| Pass | |||
| Pass | |||
| Pass | |||
| Pass | |||
| Pass |
Language Variants
Production-ready examples in 12 languages.
const protocolRelativeUrlRegex = /^\/\/[\w-]+(\.[\w-]+)+(:\d+)?(\/[^\s]*)?$/;
console.log(protocolRelativeUrlRegex.test('//example.com/path')); // trueCommon Mistakes
Confusing a protocol-relative URL (//example.com) with a root-relative path (/example.com) and using the same pattern for both
Fix: Require exactly two leading slashes for protocol-relative URLs, and use a separate pattern with a negative lookahead for root-relative paths
Still emitting protocol-relative URLs in new code, assuming they save bytes without security tradeoffs
Fix: Prefer explicit https:// URLs today; protocol-relative URLs can silently downgrade to http on pages served without TLS
Forgetting that a bare hostname without a dot, like //localhost, is rejected by the same dot-requiring host rule as full URLs
Fix: Add a special case for known bare hosts like localhost if they need to be accepted
Performance Notes
- Anchoring with ^ and $ avoids scanning for a match at multiple positions in a longer string
- The repeated hostname group (\.[\w-]+)+ is bounded by realistic hostname lengths in practice and does not risk catastrophic backtracking
- The trailing [^\s]* is greedy but has no overlap with neighboring tokens, keeping the match linear in input length
Browser Compatibility
| Engine | Supported | Notes |
|---|---|---|
| Chrome | Yes | — |
| Firefox | Yes | — |
| Safari | Yes | — |
| Edge | Yes | — |
| Node.js | Yes | — |