Describing access to a resource
A URL begins with a scheme and colon, with subsequent structure depending on the scheme. In a typical HTTPS address, host, optional port, path, query and fragment have different roles; the whole string is not simply a server filename.
RFC 3986 explains URL’s locating role within URI terminology. WHATWG instead standardizes browser-facing URL terminology and processing, so documents must be read in their stated context.
Parsing is more than retaining a string
Browsers parse input into a URL record and serialize that result. Host representation, default ports and encoding rules can make the output differ from the original input, with specified handling for some validation errors.
WHATWG makes stable parse-and-serialize results a goal. Applications comparing or modifying addresses therefore need semantic processing rather than arbitrary substring replacement.
A relative reference also needs a base: resolving item against https://example.test/a/b produces /a/item, not a mechanical append to the old string. Nor can every percent escape be decoded before parsing: a%2Fb in an HTTPS path is not the same as separate path segments a/b. Whether a delimiter is structure or data changes the result, so joining, decoding and comparison must follow the applicable URL rules.
Location, content and trust
How path and query correspond to content depends on the scheme and service. A filename-like path need not identify a physical file, and retrieval can involve another address or a resource representation.
Being parseable does not establish availability or trustworthiness. Display text can also differ from the actual link target; location, connection protection and information reliability remain separate questions.