External Links and Web Resources

Linking to external websites and online resources is one of the most fundamental tasks in HTML authoring, yet it involves a surprising amount of nuance. Beyond simply wrapping text in an anchor tag, you must choose the correct form of URL, decide whether the link should open in a new tab, protect your users from security vulnerabilities introduced by that behavior, communicate clearly to all users — including those using assistive technology — where the link leads, and understand how search engines interpret the relationships you declare between your page and the destination. Each of these concerns is explored in depth below.

Absolute URLs for External Links

Every hyperlink in HTML is created with the <a> element and its href attribute. When you link to a page or resource on a different website, you must supply an absolute URL — a complete, self-contained address that the browser can resolve without any additional context. An absolute URL has three essential parts: the protocol, the domain name, and optionally a path to a specific resource.

<!-- A well-formed absolute URL linking to an external page -->
<a href="https://developer.mozilla.org/en-US/docs/Web/HTML">
  MDN HTML Documentation
</a>

Breaking this down: https:// is the protocol, developer.mozilla.org is the domain, and /en-US/docs/Web/HTML is the path to the specific article. All three pieces together make the URL absolute — the browser knows exactly where to go without referencing the current page's location at all.

Always prefer https:// over http:// whenever the destination supports it, which the vast majority of modern websites do. The s stands for "secure" and indicates that the connection is encrypted using TLS (Transport Layer Security). Linking to an http:// resource from an https:// page triggers a mixed content warning in many browsers and may be blocked entirely, degrading both security and user experience.

A critical mistake to avoid is omitting the protocol entirely or supplying only a domain name:

<!-- WRONG: browser treats this as a relative path -->
<a href="developer.mozilla.org/en-US/docs/Web/HTML">MDN</a>

<!-- WRONG: still treated as a relative path -->
<a href="www.example.com">Example</a>

Without https://, the browser interprets the value as a path relative to the current document. If your page lives at https://mysite.com/articles/, the first broken example would resolve to https://mysite.com/articles/developer.mozilla.org/en-US/docs/Web/HTML — a URL that almost certainly returns a 404 error. Always include the full protocol.

Opening Links in a New Tab with target

The target attribute on an anchor element controls where the linked document is displayed. Setting target="_blank" instructs the browser to open the destination in a new tab (or a new window, depending on the browser and user settings).

<a href="https://www.example.com" target="_blank">
  Visit Example.com
</a>

The primary benefit is that your own website remains open in the original tab. This is particularly valuable when you want the user to consult an external reference without losing their place in your content — for instance, linking to official documentation from a tutorial, or linking to a PDF that supplements the current page.

However, target="_blank" should be used with restraint. Automatically opening new tabs for every external link removes the user's ability to decide how they want links to open, which is considered a violation of user autonomy in web accessibility guidelines. Many power users consciously choose to open links in new tabs themselves using middle-click or keyboard shortcuts, and having the browser do it automatically can multiply tabs unexpectedly. Reserve target="_blank" for situations where leaving the current page would genuinely cause a problem — external websites, downloadable files, or interactive tools that would break a multi-step workflow if the user navigated away.

Security Risks of target="_blank" and the rel Attribute

Opening a link in a new tab introduces a non-obvious but serious security vulnerability known as reverse tabnapping. When a page is opened via target="_blank", the newly opened page gains access to the opener's browsing context through the JavaScript property window.opener. A malicious destination page can exploit this to execute:

// Malicious code on the destination page
window.opener.location = "https://phishing-site.com/fake-login";

This silently redirects the original tab — the one with your website open — to a phishing page while the user is looking at the newly opened tab. The user returns to what they think is your site and may enter credentials into a convincing fake.

The solution is the rel attribute with specific values:

• rel="noopener" — Instructs the browser to open the new tab without giving it access to window.opener. The opened page cannot reference or manipulate the originating page's context. Modern browsers also apply a separate process to the new tab when this is present, which improves performance.
• rel="noreferrer" — Provides all the protections of noopener and additionally suppresses the HTTP Referer header that browsers normally send to the destination server. Without the referrer header, the destination site cannot determine which page sent the user there, which has privacy advantages.

Best practice is to combine both values every time you use target="_blank":

<a href="https://www.example.com" target="_blank" rel="noopener noreferrer">
  Visit Example.com
</a>

Multiple values in the rel attribute are separated by spaces, not commas. This single combination addresses both the tabnapping vulnerability and referrer leakage. While modern browsers have partially addressed window.opener access by defaulting to noopener behavior for cross-origin target="_blank" links, explicitly declaring rel="noopener noreferrer" ensures consistent, secure behavior across all browsers including older ones.

Communicating Link Destination to Users

Opening a link in a new tab without warning users — especially keyboard and screen reader users — is a well-documented accessibility failure. The Web Content Accessibility Guidelines (WCAG) recommend that users be informed of behaviors that change their context. There are several practical techniques:

• Visible icon with accessible text — A common pattern is to display a small "external link" icon next to the anchor. When using an image or SVG for this, include an aria-label or visually hidden text so screen readers announce it.
• Parenthetical text in the link — You can add a short note directly in the link text, though this can feel verbose if overused.
• The title attribute — Adds a tooltip visible on hover and announced by some screen readers, though it is not reliably surfaced by all assistive technologies and should not be your only warning mechanism.

<!-- Parenthetical approach -->
<a href="https://www.example.com" target="_blank" rel="noopener noreferrer">
  Visit Example.com (opens in new tab)
</a>

<!-- title attribute as supplementary hint -->
<a href="https://developer.mozilla.org/en-US/docs/Web/HTML"
   target="_blank"
   rel="noopener noreferrer"
   title="Opens MDN HTML documentation in a new tab">
  MDN HTML Documentation
</a>

Equally important is the quality of the link text itself. Search engines and screen readers both rely on anchor text to understand a link's purpose. Generic phrases like "click here," "read more," or "this page" give no information when encountered out of context — for example, when a screen reader user navigates through a list of all links on the page.

Descriptive link text improves usability for all users, helps search engines understand page relationships, and is a requirement for WCAG 2.1 Level A compliance (Success Criterion 2.4.4).

Linking to Specific Online Resources

Absolute URLs are not limited to HTML pages. You can link directly to any publicly accessible resource on the web: PDFs, images, audio files, spreadsheets, or any other file type. The browser will either display the file inline (if it can render it, as with images or PDFs in modern browsers) or prompt the user to download it.

<!-- Linking directly to a PDF hosted on an external server -->
<a href="https://www.w3.org/WAI/WCAG21/wcag21.pdf"
   target="_blank"
   rel="noopener noreferrer">
  Download WCAG 2.1 Guidelines (PDF, opens in new tab)
</a>

One important practice to avoid is hotlinking — embedding or linking directly to assets (images, videos, stylesheets) stored on a third party's server without permission. When you hotlink an image, every time a visitor loads your page, their browser makes a request to the other server to fetch that image. This consumes the other server's bandwidth at no cost to you, which many hosting providers prohibit. Some servers actively block hotlinking by checking the HTTP Referer header and serving a substitute image (sometimes an embarrassing one) when the referrer is not their own domain. The correct approach is to download the asset (if licensing allows), host it yourself, and link to your own copy.

External links also require ongoing maintenance. Unlike your own pages, external resources can disappear, move to a new URL, or be replaced with unrelated content at any time — a phenomenon sometimes called link rot. It is good practice to periodically audit your external links using automated tools (such as a link checker script or browser extension) to identify and fix broken or redirected URLs before users encounter dead ends.

The rel Attribute for Link Relationships

Beyond the security-focused noopener and noreferrer values, the rel attribute communicates the semantic relationship between your page and the linked destination, primarily for the benefit of search engine crawlers.

• rel="nofollow" — Tells search engine crawlers not to follow this link for the purposes of PageRank or authority passing. This does not hide the link from users; it only signals to crawlers that your site is not endorsing the destination. Originally intended for any untrusted external link, it remains useful when you must link to content you cannot vouch for.
• rel="sponsored" — Introduced by Google to specifically identify links that exist as part of paid arrangements: advertisements, affiliate links, or sponsored content. Using this value instead of nofollow for paid links provides more precise information to search engines and aligns with Google's webmaster guidelines.
• rel="ugc" — Short for "user-generated content," this value is appropriate for links appearing inside comments, forum posts, or other user-submitted content where you cannot curate or vouch for every URL a user might post.

Because multiple rel values can be combined in a single attribute (space-separated), you can address both security and SEO concerns simultaneously:

<!-- External affiliate link: new tab + security + SEO relationship -->
<a href="https://www.affiliate-store.com/product/123"
   target="_blank"
   rel="noopener noreferrer sponsored">
  Buy the recommended camera (affiliate link)
</a>

<!-- User comment link: security + ugc signal -->
<a href="https://some-user-posted-url.com"
   target="_blank"
   rel="noopener noreferrer ugc nofollow">
  User's linked resource
</a>

The following table summarizes the most commonly used rel values for external links, their purposes, and their primary audiences:

Understanding and correctly applying these attributes makes your external links safer for users, respectful of other servers' resources, compliant with search engine guidelines, and accessible to all visitors regardless of how they interact with the web.