The Future of URLs: Web Standards and Emerging Protocols

URLs are so fundamental to the web that most people never think about them — they just click and go. But beneath this familiar interface lies a complex standards ecosystem that is actively evolving. The URL specification that most of the web relies on, RFC 3986, was published in 2005, and while its core design has proven remarkably durable, the web has changed dramatically since then. Mobile deep links, Web URLs, decentralized identifiers, and new URI schemes are challenging the traditional URL model and creating new possibilities — and new complexities — for developers and platforms. In this guide, we will explore the evolving landscape of URL standards and what it means for the future of link management.

Evolution of URL Standards: RFC 3986 and Beyond

RFC 3986, authored by Tim Berners-Lee, Roy Fielding, and Larry Masinter, defined the generic syntax for Uniform Resource Identifiers (URIs) that underpins every URL on the web. Its design was intentionally broad — it defines a syntax (scheme://authority/path?query#fragment) that can accommodate a wide range of resource identification schemes. This generality has been both its strength and its limitation. The strength is that the same basic syntax works for http, ftp, mailto, tel, and dozens of other schemes. The limitation is that the specification leaves many details to individual scheme definitions, leading to inconsistencies in how different schemes handle encoding, normalization, and relative references.

In the years since RFC 3986, several updates and companion specifications have addressed specific issues. RFC 3987 introduced Internationalized Resource Identifiers (IRIs), which allow non-ASCII characters in identifiers. RFC 6265 standardized cookie handling, which interacts with URL-based same-origin policies. The WHATWG URL Standard, which we will discuss in detail, represents a more recent and ongoing effort to define a living standard for URL parsing that reflects how browsers actually behave, rather than prescribing how they should behave.

New URI Schemes and Protocols

The registry of URI schemes has grown significantly beyond the original http and ftp. Schemes like data (for embedding small resources directly in the URL), blob (for referencing in-memory data in browsers), and javascript (for executing code) are widely used in web applications. More recently, schemes like web+ap (for ActivityPub interactions), web+did (for decentralized identifiers), and ssb (for Secure Scuttlebutt) reflect the growing ecosystem of decentralized and federated web protocols.

Each new scheme introduces considerations for URL shortening platforms. Can the scheme be shortened? Should it be? A data URL contains the entire resource inline, so shortening it would defeat its purpose. A blob URL is scoped to a specific browser context and cannot be shared across sessions or devices. A javascript URL is executable code — shortening it raises security concerns. As new schemes emerge, URL shortening platforms must evaluate each one for compatibility, security, and user value. At yas.sh, we support shortening of any URL with a resolvable scheme (primarily http and https) while rejecting schemes that pose security risks or cannot be meaningfully redirected.

Web URLs and the WHATWG URL Standard

The WHATWG URL Standard represents a significant shift in how URL parsing is specified. Rather than the prescriptive approach of RFC 3986, the WHATWG standard takes a descriptive approach: it defines URL parsing behavior based on what browsers actually implement, treating compatibility with existing web content as a primary goal. This means the WHATWG standard sometimes contradicts RFC 3986 in edge cases — for example, in how certain characters are handled in query strings, or how backslashes are treated in URLs (the WHATWG standard treats them as forward slashes in special schemes, matching browser behavior).

For developers, the practical impact is that you should use the WHATWG URL Standard as your reference for URL parsing in web contexts, and use the URL API provided by browsers (new URL()) rather than implementing your own parser. The URL API follows the WHATWG standard and handles edge cases correctly. For non-web contexts (server-side applications, command-line tools), use a library that implements the WHATWG standard rather than one based solely on RFC 3986, as the WHATWG standard is more likely to produce results consistent with browser behavior.

Protocol-Relative URLs

Protocol-relative URLs (starting with // instead of https://) were once a popular technique for serving resources over the same protocol as the parent page — HTTP on HTTP pages, HTTPS on HTTPS pages. However, their use has declined significantly for two reasons. First, the web has moved almost entirely to HTTPS, making the protocol ambiguity unnecessary. Second, protocol-relative URLs can create security vulnerabilities: if a page is served over HTTP (perhaps due to a misconfiguration or a downgrade attack), protocol-relative URLs will also use HTTP, potentially loading insecure resources on an otherwise secure page.

Modern best practice is to always use explicit HTTPS URLs. This ensures that resources are always loaded securely, regardless of the parent page's protocol. The minor overhead of specifying https:// is negligible compared to the security benefit. URL shortening platforms should also prefer HTTPS destinations and warn users who attempt to shorten HTTP URLs about the security implications.

Deep Links and Universal Links for Mobile

Mobile deep linking — the ability for a URL to open a specific screen within a native mobile application — has become a critical part of the URL ecosystem. There are two primary mechanisms: custom URL schemes (like myapp://product/123) and universal links (iOS) / app links (Android), which use standard HTTPS URLs that the operating system intercepts and routes to the native app when it is installed. Universal links and app links are preferred because they fall back to the web URL when the app is not installed, providing a graceful degradation path that custom schemes cannot offer.

For URL shortening platforms, deep linking introduces interesting possibilities and challenges. A short link can serve as a universal entry point that routes users to the best experience for their device — a native app screen for users who have the app installed, or a mobile web page for those who do not. This requires the shortening platform to support deep link metadata (like Apple Universal Links and Android App Links configuration) alongside the standard redirect. At yas.sh, we support deep link configuration on short links, enabling seamless cross-platform experiences from a single short URL.

Web3 and Decentralized URL Systems

The emergence of Web3 and decentralized web protocols introduces fundamentally different approaches to resource identification. InterPlanetary File System (IPFS) uses content-addressed identifiers (ipfs://QmXx...), where the identifier is derived from the content itself rather than its location. This means an IPFS URL always points to the same content, regardless of where it is stored — a significant departure from the location-based addressing of traditional URLs. Ethereum and other blockchain platforms use decentralized identifiers (DIDs) that are registered on-chain and resolved through decentralized networks.

These decentralized URL systems challenge the traditional URL shortening model in several ways. Content-addressed URLs are immutable — the same content always has the same identifier, so there is nothing to redirect. However, the human-readable gateways that provide access to IPFS content (like ipfs.io/ipfs/QmXx...) are location-based and can benefit from shortening. DID URLs often include long identifier strings that benefit from shorter, more memorable aliases. As the decentralized web grows, URL shortening platforms that can bridge traditional and decentralized URL systems will provide significant value to users navigating both ecosystems.

URL Handling in Modern Browsers

Modern browsers have significantly enhanced URL handling beyond simple parsing and navigation. Chrome's Omnibox, Firefox's Awesome Bar, and Safari's Smart Search Field all blur the line between URLs and search queries — when a user types something that is not a valid URL, the browser treats it as a search query instead. This behavior means that many users never see or type explicit URLs, relying instead on search engines and bookmarks for navigation. For URL shortening platforms, this trend reinforces the importance of memorable, brandable short domains that users can recognize and trust in search results and shared content.

Browsers have also implemented significant security features around URLs. Same-site cookies restrict cross-site request forgery by limiting which cookies are sent with cross-site requests. Content Security Policy restricts which URLs a page can load resources from. Referrer-Policy controls how much URL information is shared in the Referer header. These features all use URLs as a security boundary, making URL parsing accuracy critical for security. URL shortening platforms must ensure their redirects comply with these browser security features to avoid breaking functionality or creating security vulnerabilities for their users.

Impact of New Standards on URL Shortening

The evolution of URL standards has direct implications for URL shortening platforms. The WHATWG URL Standard means that shortening platforms must parse URLs using the same algorithm as browsers to avoid subtle mismatches. Deep linking support means platforms must handle mobile-specific metadata alongside standard redirects. Decentralized URL systems may require new forms of aliasing and resolution. And increasing browser security around URLs means platforms must implement robust redirect security (checking destination safety, preventing open redirect vulnerabilities, and supporting security headers) to protect both their users and their reputation.

Conclusion

The URL is one of the most successful abstractions in computing history — a simple string that identifies any resource on the global web. But even this foundational technology is not standing still. From the WHATWG URL Standard's pragmatic approach to parsing, to mobile deep linking's bridge between web and native, to Web3's content-addressed identifiers, the URL ecosystem is richer and more complex than ever. For developers and platforms, staying current with these evolving standards is not optional — it is essential for building systems that work correctly, securely, and seamlessly in the modern web landscape.