Understanding the rel='noopener noreferrer' Attribute

If you have ever opened a code editor's link dialog or glanced at a linter warning about target="_blank", you have seen this attribute combination: rel="noopener noreferrer". It appears so routinely that most developers add it by reflex without being entirely sure what each word does. That reflex is mostly correct, but understanding the mechanics is worth the five minutes — especially if you ever need to decide whether to omit one of the values on purpose.

This post unpacks each value, explains the security risk that motivated them, covers how modern browser behavior has changed the picture, and clarifies the real cost of noreferrer on your analytics.

The problem: what target="_blank" exposes

When a browser opens a link in a new tab via target="_blank", it gives the newly opened page a JavaScript reference back to the tab that opened it. That reference is window.opener. By default — without any rel attribute — the new page can run JavaScript like this:

// Executed from the newly opened (external) page
window.opener.location.href = "https://evil.example.com/fake-login";

This is the basis of an attack called reverse tabnabbing. The sequence looks like this:

1. A user is on your page and clicks an external link, which opens in a new tab.
2. The external page (which you do not control) uses window.opener to silently redirect your original tab to a phishing page that looks identical to yours.
3. The user switches back to the original tab, sees a login prompt, and enters credentials — now on the attacker's server.

Because the redirect happens in a background tab while the user is reading the new page, they rarely notice. The OWASP Foundation documents this as a real-world attack vector, not a theoretical one.

What noopener does

rel="noopener" tells the browser not to set window.opener on the new browsing context. The opened page gets its own process, and the JavaScript bridge between tabs is simply absent. There is nothing to exploit.

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

noopener has no effect on the HTTP request itself — it is purely a browser-level process isolation instruction. The destination site receives the full Referer header and all normal request headers; it just cannot reach back into the opener tab via JavaScript.

There is also a subtle performance benefit: without noopener, some browsers share the same renderer process between the two tabs to allow the window.opener bridge. With noopener, the browser is free to place the new tab in its own process, which can improve the performance of your original tab if the linked page is heavy.

The browser default change (Chrome 88, Firefox 79, Safari 12.1)

This is where the picture got more nuanced. Starting around 2019–2021, major browsers changed their default behavior so that any target="_blank" link implicitly behaves as if rel="noopener" is set, even when you do not write it. Chrome shipped this in version 88 (early 2021); Firefox shipped it in version 79 (mid-2020); Safari shipped it even earlier in version 12.1 (2019).

The HTML specification was updated to match: target="_blank" now implies noopener behavior by default. If you need the old behavior — a genuine cross-tab opener reference — you have to opt in explicitly with rel="opener".

In practice this means that for fully modern browser targets, writing noopener is redundant (though harmless). The reason you should still write it explicitly is straightforward: it communicates intent, it is a no-cost signal to other developers reading the code, and it guards against any edge cases in older or non-standard environments.

What noreferrer does

rel="noreferrer" does two things:

1. It suppresses the HTTP Referer header on the request to the destination. The linked page receives the request but cannot see which URL sent the visitor.
2. It also implies noopener behavior. If you use only noreferrer, the browser will still sever the window.opener bridge.

<!-- These are equivalent in terms of opener isolation: -->
<a href="https://example.com" target="_blank" rel="noopener noreferrer">Link</a>
<a href="https://example.com" target="_blank" rel="noreferrer">Link</a>

<!-- But this only suppresses the Referer, not the opener: -->
<!-- (rel="noreferrer" without target="_blank" has no opener to worry about anyway) -->
<a href="https://example.com" rel="noreferrer">Link</a>

Because noreferrer implies noopener, writing both is technically redundant for the security goal. The convention of writing both together persists because they address different concerns — security (noopener) and privacy (noreferrer) — and listing both makes the intent explicit.

The analytics cost of noreferrer

This is the practical trade-off developers most often miss. When a user clicks a link marked noreferrer and lands on the destination site, that site's analytics (Google Analytics, Plausible, Fathom, etc.) cannot read the Referer header. The session is recorded as direct traffic instead of referral traffic.

For the site you are linking to, this means they lose attribution data — they cannot tell that your site sent them a visitor. For most external links this is either neutral or slightly considerate of the linked site's users' privacy. For links to sites you operate or co-own, it can distort your own referral reporting.

The consequence for your own site's outgoing links is smaller: you are not losing any data about your own visitors, just preventing the destination from seeing where they came from. Whether that matters depends on your relationship with the destination.

When to omit noreferrer deliberately

There are legitimate scenarios where you want to pass referrer information:

• Links between your own properties (e.g., a blog linking to your main storefront) where referral attribution matters for your own analytics.
• Affiliate or partnership links where the destination needs referral data to credit you properly.
• Links to your own documentation, changelog, or subdomain where you want accurate source data in analytics dashboards.

In these cases, use only noopener and omit noreferrer:

<a href="https://docs.yourdomain.com/guide" target="_blank" rel="noopener">
  Read the docs
</a>

The opener security is still handled; the Referer header is still sent.

The complete picture in one example

<!-- External link you do not control: use both -->
<a href="https://github.com/some/repo" target="_blank" rel="noopener noreferrer">
  View on GitHub
</a>

<!-- Link to your own subdomain: noopener is enough -->
<a href="https://shop.example.com/themes" target="_blank" rel="noopener">
  Browse themes
</a>

<!-- Same-tab link: neither attribute is needed (no opener exists) -->
<a href="/about">About us</a>

SEO: no effect on rankings

One common question is whether these attributes affect link equity or rankings. They do not. Neither noopener nor noreferrer is a signal that a link should not be followed or credited by search engines — that is what rel="nofollow" does. The noopener and noreferrer values are purely browser-side privacy and security instructions that search engine crawlers ignore for ranking purposes.

If you want to signal to Google that a link should not pass ranking signals, you need rel="nofollow" (or the more specific rel="ugc" / rel="sponsored"). You can combine all of these: rel="nofollow noopener noreferrer" is valid and common for user-generated content.

Quick reference

• noopener — severs the window.opener JavaScript bridge. Prevents reverse tabnabbing. No effect on HTTP headers. Now the browser default for target="_blank", but still worth writing explicitly.
• noreferrer — suppresses the HTTP Referer header. Also implies noopener. Causes destination analytics to see the visit as direct traffic instead of referral.
• Both together — the safe default for external links you do not control. Each value is redundant in part (since noreferrer implies noopener, and modern browsers treat target="_blank" as noopener anyway), but the combination is clear, explicit, and universally understood.
• Neither needed — for same-tab links and internal links. Applying them to internal navigation is unnecessary and can slightly distort your own referral analytics.

The short version: reach for rel="noopener noreferrer" on any target="_blank" link pointing to an external site. Use just rel="noopener" when the referrer header matters (your own properties, affiliate links). Skip both entirely for same-tab links. That covers the vast majority of cases you will encounter when building any site.