Opening Links in a New Tab Safely

Opening every external link in a new tab can look helpful. The reader keeps your page, whilst the destination appears beside it. It can also be surprising. The Back button no longer returns to the page they came from, the browser may open a separate window rather than a tab, and keyboard or screen‑reader users may not immediately know that the context has changed.

Start with an ordinary link:

<a href="https://example.com/report">Read the report</a>

That leaves the decision with the reader. They can follow it normally, open it in a new tab from the browser menu, or use their usual mouse or keyboard shortcut. Only add a new‑context instruction when there is a genuine product reason for doing so.

“

October 2018 note: The browser guidance in this article describes the position on 25 October 2018. Please don't read it as an undated compatibility statement.

Do You Need a New Tab?

A new browsing context can be justified. A user may need to compare two documents, keep an unfinished form open, or refer to instructions whilst completing a separate task. Even then, the interface should make the behaviour clear before the link is followed.

This is not only a security question. The W3C's guidance on opening new windows only when necessary treats the user's ability to choose as the starting point. If the requirement does not survive that discussion, remove target="_blank" and there is no opener problem to solve.

The Opener Relationship in 2018

Consider the common 2018 pattern:

<a href="https://example.com/report" target="_blank">  Read the report (opens in a new window)</a>

The browser creates another browsing context for the destination. In the stable browsers of the period, that new page could receive a reference to the original page through window.opener.

Cross‑origin rules restrict what the destination may inspect, but the relationship is still more authority than an ordinary link needs. In particular, period browsers could allow the destination to navigate its opener. The WHATWG discussion opened on 10 October 2018 records this exact default and the proposal to reverse it.

That does not make every _blank link an attack. It means the link has created a relationship that should be deliberate rather than accidental.

Severing the Relationship

For browsers that support it, noopener tells the browser to create the new context without an opener:

<a  href="https://example.com/report"  target="_blank"  rel="noopener">  Read the report (opens in a new window)</a>

By October 2018, noopener was available in Chrome 49 and later, Firefox 52 and later, and Safari 10.1 and later. It was not supported by Edge 18 or Internet Explorer 11. The browser versions are recorded in the HTML `noopener` compatibility reference.

The default was beginning to move. WebKit landed an experimental implicit‑`noopener` change during October 2018, but an experiment is not a stable cross‑browser baseline. Code written for the period should still state its intent explicitly.

If Edge or Internet Explorer is part of the support contract, there is no honest reason to pretend the noopener token fixes those engines. Prefer ordinary navigation, or test a separately justified noreferrer policy in the exact browsers you support.

noopener and noreferrer Are Different Decisions

These two relationship tokens are often copied together:

<a  href="https://example.com/report"  target="_blank"  rel="noopener noreferrer">  Read the report (opens in a new window)</a>

They do not describe the same requirement. noopener removes the opener relationship. It does not hide where the visit came from. noreferrer suppresses referrer information and, in supporting browsers, also has the opener‑severing effect.

That privacy change may be wanted for a sensitive source page. It may also remove useful information from the destination's analytics or logs. Do not add noreferrer as a mysterious second half of a security incantation. Decide whether referrer suppression is part of the requirement, then test the result.

Inspecting the Result Safely

The destination page can report whether it received an opener without trying to use it:

<p id="opener-status"></p><script>  var message = window.opener === null    ? 'No opener relationship'    : 'An opener relationship exists';  document.getElementById('opener-status').textContent = message;</script>

Link to that local page from three fixtures: unqualified _blank, _blank with noopener, and _blank with a deliberately chosen noreferrer. In a period browser without an implicit default, the first reports an opener and the mitigated links report no opener where their tokens are supported.

The fixture should never navigate, read from, or modify the originating page. The boolean relationship is enough to verify the contract.

CMS and Component Review

A CMS field called "Open in new tab" is only the beginning of the implementation. Inspect the rendered anchor, not merely the field or component name.

Check that:

• ordinary links remain ordinary anchors with useful href values;
• the new context is a real editorial or product requirement;
• target, rel, and any referrer decision are rendered together;
• the link's visible purpose still makes sense;
• a context change is warned about in visible text or another tested, perceivable form; and
• the target‑browser matrix includes the actual legacy engines the site supports.

The W3C technique for warning users about a new window is useful here. A title attribute alone is a weak warning because it is not consistently visible or announced across input methods and assistive technology.

Wrapping Up

The safest new‑tab link is often the one you do not force. When a 2018 requirement genuinely needs a new browsing context, make that change clear, sever the opener relationship explicitly in supporting browsers, and treat referrer suppression as its own decision.

Small attributes can express quite different contracts. Review them as engineering choices, not as a snippet to paste into every external link.