.\n\nThe approach arose during periods of mixed content concern as sites migrated to HTTPS. As TLS adoption grew, many developers moved toward explicit https URLs or host-relative paths. Protocol-relative URLs have become less central in modern practice, and some CDNs and developers discourage their use in favor of clear https links or more explicit resource addressing.\n\nDrawbacks include dependency on the external host supporting both protocols; if the resource is unavailable over the required protocol, loading can fail. They can complicate security policies such as Content Security Policy and interactions with upgrade-insecure-requests. They can also obscure the protocol requirement, potentially leading to maintenance issues or unexpected behavior during deployment.\n\nToday, protocol-relative URLs are largely considered a legacy technique. In new development, explicit https URLs or appropriate relative paths are typically preferred, depending on deployment context.","author":{"@type":"Organization","name":"Infinite Lexicon","url":"https://infinitelexicon.com"},"publisher":{"@type":"Organization","name":"Infinite Lexicon","logo":{"@type":"ImageObject","url":"https://infinitelexicon.com/infinity.svg"}},"mainEntityOfPage":{"@type":"WebPage","@id":"https://infinitelexicon.com/Protocolrelative"}}

Protocolrelative

Protocolrelative refers to a URL that omits the scheme and begins with //, causing the browser to use the same protocol as the containing page. It is also called a protocol-relative URL. The technique allows a resource to be requested without hardcoding http or https, deferring the decision to the page that embeds it.

In practice, protocol-relative URLs are often used for external resources such as scripts, stylesheets, fonts, or images loaded from a content delivery network. For example, a URL like //cdn.example.com/library.js will be fetched with https when the page is loaded over https and with http when the page is loaded over http. A common illustration is <script src="//code.jquery.com/jquery-3.6.0.min.js"></script>.

The approach arose during periods of mixed content concern as sites migrated to HTTPS. As TLS adoption grew, many developers moved toward explicit https URLs or host-relative paths. Protocol-relative URLs have become less central in modern practice, and some CDNs and developers discourage their use in favor of clear https links or more explicit resource addressing.

Drawbacks include dependency on the external host supporting both protocols; if the resource is unavailable over the required protocol, loading can fail. They can complicate security policies such as Content Security Policy and interactions with upgrade-insecure-requests. They can also obscure the protocol requirement, potentially leading to maintenance issues or unexpected behavior during deployment.

Today, protocol-relative URLs are largely considered a legacy technique. In new development, explicit https URLs or appropriate relative paths are typically preferred, depending on deployment context.