MediumWeb4 min read

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.

#url#web#protocol#http#validation

Regex Pattern

^\/\/[\w-]+(\.[\w-]+)+(:\d+)?(\/[^\s]*)?$

Pattern Breakdown

Hover over a token to see what it does.

^\/\/[\w-]+(\.[\w-]+)+(:\d+)?(\/[^\s]*)?$

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.

Open in Playground →

//example.com //example.com/path?q=1 //example.com:8080/path

3 matches· capture groups: 3

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')); // true

Common 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	—

Work with this pattern

Take this expression further — test it against your own data, adapt it in the builder, or read up on the syntax behind it.

Regex Tester

Test a regular expression against sample text and see every match highlighted live.

Regex Generator

Build a pattern by clicking blocks — no syntax memorisation required.

Regular Expressions Guide

What regex is, how the syntax works, and the mistakes that trip people up.

Regex Cheat Sheet

Every token, quantifier, and assertion on one printable page.

Python Regex Guide

The re module end to end — search, match, findall, groups, and substitution.

Regex Pattern Library

100+ ready-to-use patterns for email, URLs, dates, IPs, and more.