The link works on your website but not when shared
Resolve a relative path to a complete address, check its destination with WikiURL and test the received link before creating a short address or QR.
Recognize what is missing before forwarding
On your website you click the programme for an event and it opens correctly. Then you copy agenda.pdf or a path starting with a slash into an email and the recipient cannot reach the file. The consulted questions show this problem and surprise when building an address loses part of its base path. Before blaming email or a shortener, inspect what was copied: a relative reference needs context to obtain a complete destination. It can be entirely valid inside a website. To share outside that context, prepare a complete, checked web URL. This guide separates resolving an address from establishing that the document exists and is what the audience needs.
Identify the base that gives the path meaning
MDN explains that resolution uses a base URL, rather than simply joining two strings. In an HTML document the base normally depends on its location, but a base element with href can change it. If the code shows only a path, do not guess the missing domain or folder. Prefer the browser's copy-link-address function and inspect its result instead of manually transcribing an attribute. If you maintain the website, compare the document's actual base with the expected destination before fixing a link. Do not add a base tag across the page as a quick repair: it can change resolution of other references as well as the one under investigation. Establish the context first.
Check what the example slashes do
The three expressions illustrate resolution with the URL constructor. The example.invalid domain and filename are fictional; they do not establish that a downloadable programme exists. With a base ending in event/, agenda.pdf produces an address within that folder. A reference beginning/agenda.pdf instead starts at the same origin's root. If the base ends in event without a final slash, resolving agenda.pdf replaces that last segment, producing a root-level result again. MDN and RFC3986 describe these resolution differences. Do not add or remove slashes by habit. Choose the address matching the actual resource and inspect the complete output, rather than only the filename at its end. Construction alone provides no availability evidence.
Record the example outputs: first https://example.invalid/event/agenda.pdf, then https://example.invalid/agenda.pdf and again https://example.invalid/agenda.pdf. Two expressions producing the same address do not establish whether the event folder exists or should be omitted on your website. In a real test record the calculated address, opened document and audience access separately. Leave unobserved stages unverified. These outputs describe local string resolution, not a download or server availability check.
new URL("agenda.pdf", "https://example.invalid/event/").href
new URL("/agenda.pdf", "https://example.invalid/event/").href
new URL("agenda.pdf", "https://example.invalid/event").hrefValidate the resource after resolution
Check that the resulting URL has the domain and path you expected. A constructor can produce a syntactically valid address to the wrong resource; it grants no permissions and checks no content. For a public destination without secrets or personal information, enter the complete address in Wiki URL's checker and record the HTTP response and final URL. Also open the resource to confirm the correct programme and access for the intended audience. A200 response alone establishes neither. If redirects occur, examine the final destination before approving it. For private documents, use authorized means and avoid sending them to external tools. Keep the technical response separate from content and audience checks.
Distribute the approved address and test what arrives
After checking the complete URL, use it in the final email or document. If the editor supports named links, retain the approved destination even when the label says Event programme. Do not replace the actual address with an incomplete path merely to make the displayed text shorter. If a short address or QR is needed, create it in Wiki URL from the approved complete destination and test that exact version. Shortening does not guess the missing website or folder of a relative reference and does not publish the file for you. Reopen the link from the received or exported version, not just the editor preview. This exposes differences between the original and distributed material.
Keep context, destination and evidence together
Save the original reference, chosen base, resolved URL and shared version. You can then reproduce the case after changing folders, templates or the website location. Do not indiscriminately replace every relative reference on a site: the issue is carrying a link outside its context, not banning a valid technique within pages. If a file moves, review references and circulating material and agree with its maintainer how access will continue. Do not promise automatic updates to an earlier QR. A useful conclusion combines a complete address pointing to the expected document with a test of the actual journey. Wiki URL helps check and distribute the address; resolving it does not replace content review or access permissions.