A URL scheme is the protocol identifier at the very beginning of a URL: the characters before the colon and double slash that specify how the resource should be accessed. In https://example.com/page the scheme is https: instructing the browser to use the HyperText Transfer Protocol Secure to retrieve the resource. In http://example.com/page the scheme is http. In ftp://files.example.com/document.pdf the scheme is ftp. The scheme is the first thing a browser reads in a URL, it determines which protocol to use, which port to connect on by default, and what security and communication characteristics to expect.

The scheme is separated from the rest of the URL by ://: a colon followed by two forward slashes. The colon marks the end of the scheme, and the double slash introduces the authority component, the domain and optional port that follow. Some schemes use a single colon without double slashes, mailto:address@example.com for email addresses and tel:+15551234567 for telephone numbers, because these schemes do not identify network-accessible resources with an authority component.

URL schemes define the universe of possible resource access methods on the internet. Each scheme specifies its own rules, the protocol used, the default port, the security characteristics, and what kinds of resources it addresses. Understanding URL schemes is important for web development, security configuration, and redirect management, particularly for ensuring that all web resources use the secure https scheme and that HTTP-to-HTTPS redirects correctly upgrade the scheme for all incoming requests.

How URL schemes work

The scheme is the first component parsed by any URL-processing system, it determines everything about how the URL is subsequently handled.

Protocol determination: the scheme specifies which protocol the client should use to communicate with the server. https specifies TLS-encrypted HTTP communication, the browser establishes a TLS connection before sending any HTTP data. http specifies unencrypted HTTP communication, the browser connects directly on port 80 and communicates in plaintext. ftp specifies File Transfer Protocol communication on port 21. The scheme is the protocol specification, it is the client’s instruction manual for how to establish the connection.

Default port assignment: each scheme has an associated default port number. https defaults to port 443. http defaults to port 80. ftp defaults to port 21. ws: WebSocket, defaults to port 80. wss: WebSocket Secure, defaults to port 443. When a URL does not include an explicit port the client uses the scheme’s default port. An explicit port in the URL overrides the default, https://example.com:8443/page connects to port 8443 rather than the default 443.

Security characteristics: the scheme determines the security properties of the connection. https requires TLS encryption, providing confidentiality, authentication, and integrity. http provides none of these, the connection is plaintext and unauthenticated. wss provides encrypted WebSocket communication. sftp provides encrypted file transfer. The scheme is the first indicator of connection security, a browser that sees https knows to enforce TLS; one that sees http knows the connection will be unencrypted.

Browser handling: browsers handle different schemes through different built-in mechanisms. https and http are handled by the browser’s HTTP engine, the request is fetched and rendered. ftp is handled by the browser’s FTP client or passed to an external handler, modern browsers have largely removed FTP support. mailto launches the system’s default email client. tel initiates a phone call on mobile devices. Unknown schemes may trigger a prompt to open an associated application or may be rejected entirely.

Common URL schemes

The web ecosystem uses a defined set of URL schemes, each serving specific purposes.

https, HyperText Transfer Protocol Secure: the standard scheme for all modern web pages, APIs, and web resources. https://example.com/page. Requires TLS encryption, providing confidentiality, server authentication, and data integrity. All public-facing websites should use HTTPS, browsers flag HTTP as insecure and search engines treat HTTPS as a ranking signal. HTTPS is not just the secure alternative to HTTP, it is the baseline expectation for all web communication.

http, HyperText Transfer Protocol: the original web protocol. http://example.com/page. Unencrypted and unauthenticated, all data transmitted in plaintext, server identity unverified. Modern browsers display “Not Secure” warnings for HTTP pages. HTTP should only appear in URLs as a redirect source, every HTTP URL should 301 redirect to its HTTPS equivalent. HTTP URLs in canonical tags, sitemaps, or internal links are technical SEO mistakes.

ftp, File Transfer Protocol: used for file transfer. ftp://files.example.com/document.pdf. Largely obsolete for web browsing, modern browsers have removed or severely restricted FTP support. File distribution that previously used FTP has generally migrated to HTTPS, file downloads served over HTTPS are more secure and more universally accessible than FTP.

mailto, email address: specifies an email address rather than a network resource. mailto:contact@example.com. Clicking a mailto link opens the system’s default email client with the specified address pre-filled. Not a network URL in the same sense as HTTP, the scheme has no authority component, no path in the network sense. Can include query-string-like parameters for subject and body, mailto:contact@example.com?subject=Hello&body=Message.

tel, telephone number: specifies a phone number. tel:+15551234567. On mobile devices clicking a tel link initiates a phone call. On desktop browsers the behaviour varies, some prompt to open a VoIP application, others do nothing. Used in HTML for click-to-call functionality on contact pages.

ws and wss, WebSocket: real-time bidirectional communication protocol. ws://example.com/socket for unencrypted WebSocket, wss://example.com/socket for encrypted WebSocket over TLS. Used for applications requiring real-time communication, chat applications, live data feeds, collaborative tools. Like HTTP and HTTPS the secure wss scheme is strongly preferred, ws connections are unencrypted.

data, inline data: embeds data directly in the URL rather than referencing an external resource. data:image/png;base64,iVBORw0KGgo... embeds a base64-encoded PNG image directly in the URL. Used for small inline resources, tiny images, inline SVGs. Data URLs are not traditional network URLs, there is no server request, the data is included in the URL itself.

javascript, inline JavaScript: embeds JavaScript code in a URL. javascript:void(0) is a common usage, a click target that executes JavaScript without navigating. Security-sensitive, browsers restrict javascript: URL usage due to XSS risks. Generally avoided in modern web development in favour of event handlers.

blob, binary large object: references an object URL created in the browser’s memory. blob:https://example.com/uuid. Blob URLs reference in-memory data created by JavaScript, used for file downloads, canvas exports, and media streams created client-side. Not shareable or persistent, blob URLs are only valid within the browser session that created them.

URL schemes and redirects

URL scheme management is central to redirect management: the most universal redirect pattern on the web is the HTTP-to-HTTPS scheme upgrade.

HTTP to HTTPS scheme upgrade, the universal redirect: every domain serving HTTPS content should redirect all HTTP URLs to their HTTPS equivalents, upgrading the scheme in the redirect. http://example.com/page redirects to https://example.com/page: a 301 permanent redirect that changes only the scheme while preserving the authority and path.

The scheme upgrade redirect must cover all URL variants, every path on the domain, with and without trailing slash, with and without query strings. A redirect that covers only the homepage while leaving other paths accessible over HTTP is incomplete, any HTTP URL not redirected remains accessible in plaintext.

Server-side implementation of the scheme upgrade redirect, in Nginx, Apache, or a redirect management platform, ensures all HTTP requests are upgraded to HTTPS. The redirect fires for every HTTP request regardless of path, converting the entire domain from HTTP to HTTPS at the redirect layer.

Scheme preservation in redirect destinations: when configuring redirect destinations the destination URL should use the https scheme, never http. A redirect destination specifying http://new-domain.com/page would redirect users to an HTTP page, creating a security downgrade and triggering the browser’s Not Secure warning at the destination. All redirect destinations should be https:// URLs, the scheme in the destination specifies the final connection protocol.

Redirect chains from scheme mismatches: a common redirect chain source is scheme inconsistency in redirect rules. A redirect from http://example.com/page to http://example.com/new-page: changing the path but preserving the HTTP scheme, followed by a separate HTTP-to-HTTPS redirect creates a two-hop chain. Redirect rules should simultaneously upgrade the scheme and change the path, collapsing both transformations into a single 301 redirect directly to the HTTPS destination.

Scheme canonicalisation in canonical tags: canonical tags should always specify the https scheme, <link rel="canonical" href="https://example.com/page">. A canonical tag using the http scheme, <link rel="canonical" href="http://example.com/page">: on an HTTPS page creates a contradictory signal, the page is served over HTTPS but the canonical tag points to the HTTP version. Search engines receive mixed signals about which scheme is canonical.

URL schemes and security

The URL scheme is the primary security indicator in a URL, it determines whether the connection provides encryption and authentication.

HTTPS as the security baseline: HTTPS is not a security optional extra, it is the baseline expectation for all web communication. The https scheme guarantees three security properties, confidentiality through TLS encryption, server authentication through SSL certificate verification, and data integrity through TLS message authentication. Users on HTTPS know their connection is encrypted, the server is who it claims to be, and the data has not been modified in transit.

The HTTP scheme provides none of these properties, connections are observable, the server identity is unverified, and data can be modified in transit. Any website that handles user data, logins, forms, personal information, payment details, and uses HTTP is exposing that data to potential interception.

Browser security indicators based on scheme: browsers communicate connection security to users through visual indicators that are directly tied to the URL scheme. https URLs show a padlock icon, or simply the domain without a warning, indicating a secure connection. http URLs show a “Not Secure” indicator, warning users that the connection is unencrypted. These browser-level security signals affect user trust, click-through rates, and conversion rates, providing practical business motivation to use HTTPS alongside the security motivation.

Mixed content and scheme consistency: a page served over HTTPS that loads resources over HTTP, images, scripts, stylesheets, creates mixed content issues. The page URL uses the https scheme but resource URLs use the http scheme, creating an inconsistency that browsers flag as a security concern. Active mixed content, scripts and iframes from HTTP sources, is blocked by modern browsers. Passive mixed content, images from HTTP sources, triggers security warnings.

Maintaining scheme consistency, all resources on HTTPS pages using https resource URLs, is an essential component of a complete HTTPS implementation. Every absolute URL used to load resources, in HTML src attributes, CSS url() values, JavaScript fetch calls, should use https not http.

Scheme downgrade attacks: SSL stripping attacks attempt to downgrade HTTPS connections to HTTP by intercepting the initial HTTP request before the HTTPS redirect fires. HSTS: HTTP Strict Transport Security, defends against scheme downgrade attacks by instructing browsers to only connect over HTTPS, the browser never makes an HTTP request to an HSTS-protected domain, eliminating the interception window. The HSTS header is set by the HTTPS server, Strict-Transport-Security: max-age=31536000: and is cached by browsers for the specified duration.

URL schemes in different contexts

URL schemes appear across web development contexts, each requiring appropriate scheme usage.

HTML hyperlinks: anchor elements in HTML use URL schemes in href attributes. Internal links typically use root-relative URLs, omitting the scheme, which inherit the current page’s scheme. External links use absolute URLs with explicit schemes, https://external-site.com/page. All absolute URLs in HTML should use https://.

CSS resource references: CSS url() values reference images, fonts, and other resources. Absolute URLs in CSS should use https://. Relative URLs in CSS are resolved relative to the stylesheet’s URL, appropriate for resources hosted alongside the stylesheet.

JavaScript fetch and XMLHttpRequest: JavaScript code making HTTP requests specifies the URL including the scheme. Requests from HTTPS pages to HTTP endpoints are blocked by browsers as mixed content. All programmatic HTTP requests from HTTPS pages must use HTTPS destination URLs.

API endpoints: REST API and GraphQL endpoint URLs should use https://. APIs served over HTTP transmit request and response data, including authentication tokens and sensitive data, in plaintext. All production APIs should be HTTPS-only.

Webhooks: webhook delivery URLs registered with third-party services should use https://. Webhook deliveries carry event data that may be sensitive, HTTPS ensures the data is encrypted in transit and the receiving server is authenticated.

Common URL scheme mistakes

HTTP canonical tags on HTTPS pages: specifying http:// in canonical tags on HTTPS pages. The canonical tag points to the HTTP version of the URL while the page is served over HTTPS, contradictory canonical signals. Always use https:// in canonical tags.

HTTP redirect destinations: configuring redirect rules with HTTP destination URLs. Users following the redirect arrive at an HTTP page, insecure and potentially triggering browser warnings. All redirect destinations should use https://.

Mixed scheme internal links: some internal links using http:// while others use https://: or using absolute HTTP URLs on HTTPS pages. Each HTTP internal link creates an unnecessary redirect hop as the HTTP-to-HTTPS redirect fires. Use consistent https:// absolute URLs or root-relative URLs, which inherit the page’s HTTPS scheme.

HTTP API calls from HTTPS pages: JavaScript making fetch or XMLHttpRequest calls to HTTP API endpoints from HTTPS pages. Browsers block these as mixed content. Ensure all API endpoints are HTTPS and all programmatic requests use HTTPS URLs.

Not enforcing HTTPS for all paths: implementing the HTTP-to-HTTPS scheme upgrade redirect for the homepage but not for all paths, leaving some pages accessible over HTTP. The scheme upgrade redirect must cover every path on the domain, not just the homepage.