Anchor links1 may have a target attribute which controls what happens when that link is clicked. One of the possible values of that attribute is _blank , which tells the browser to open a new window (or tab, if that’s the user’s preference) when that link is clicked.

This used to be “invalid” in HTML (maybe only XHTML?) but people used it anyway since it worked. It’s now perfectly valid in HTML5. But are there good reasons to do so?

A Bad Reason: Because you like it that way.

Like it or not, target="_blank" is a change in default behavior. Links opening within the same page is the default behavior (as if the link had target="_self" on it).

Perhaps you’ve developed a personal taste for opening all links in new windows/tabs. That’s wonderful for you, but it is safe to assume most users are most comfortable with the default behavior. And thus less comfortable with your forcing of a different behavior.

If it’s an internal tool just for you, do whatever you want. If other people use the site, leave it be.

It is also worth noting that users can force a link to open in a new window/tab by [Meta Key]-clicking a link. That means both behaviors are available to them for links. That also means that if you like opening new tabs, you can, and you don’t have to impart that behavior on anyone else.

By using target="_blank" , only that behavior is available.

A Bad Reason: Just because you want users to never leave your page.

Branding branding branding! Eyeballs baby. Metrics. ENGAGEMENT.

Other sites should have normal-style links, but our site is special. Our site is more important and should never be left behind.

A Bad Reason: “Internal” links and “External” links are different.

We’ll have “internal” links (links that point to our own site) behave normally, but “external” links (links that point to other sites) open in a new window/tab.

This is related to the above two reasons, only perhaps worse. You understand that normal style links are ideal, but if that means a user leaves your site, you’re willing to break that ideal.

I’ve heard from a lot of people that this is “a convention.” As in the way it’s supposed to be done. It’s not.

A Bad Reason: The link is to a PDF

Or any other type of non-web resource. Why should that be so different? You can still use the back button to come back from it. If you want to help users download it without actually opening it, that’s a worthy UX goal but can be approached differently. For starters, using the download attribute.

A Bad Reason: My client wants it that way

I get the “I don’t want to pick this fight” thing, since we only have so much energy. But it’s weird this has to be a fight at all. If they don’t trust you with this, what do they trust you about?

I might approach it like this:

The default behavior is for links to open normally. There are some reasons why we might want to break that behavior, and we can go over those, but for most links, we don’t. We don’t want to force our desires on users and potentially frustrate them for such a small thing. We want our users to feel good about us.

And hopefully, your calm and educated approach will help your client feel good about you.

A Bad Reason: It’s on an infinite-scroll page

Infinite scrolling is tricky. It can be good UX in one sense because it can deliver content without interruption. It can be bad UX if not handled well. Coming “back” to an infinite scroll page should take you to where you left off in most cases. Handling that tricky problem is your job. Just forcing links to open in new tabs so that problem never comes up is avoiding your job.

A Good Reason: There is user-initiated media playing

For instance: music, video, a podcast…

The user started it. Moving pages would stop it. At that point, either have links open in new tabs or ask them if they are sure they want to leave the page. At that point, you are trying to do right by them and have them not leave their place.

We’ve covered this idea before here. If the media is playing, handle links in a special way. When the media isn’t playing, links are in their normal state.

Although as I say that, I check YouTube, and they don’t bug you about it2 when changing videos.

A Good Reason: The user is working on something on the page, that might be lost if the current page changed.

Perhaps a user is writing something. Or arranging something. Doing any kind of work. Clicking a link and changing pages can be a heart-pounding, awful moment on the web. Did I just lose everything I was doing?

Even if you do something to ensure they don’t lose that work, putting someone through that panic may as well be avoided.

I think of CodePen where users are often writing code. We do several things to help:

Links that go to other pages that are explicitly “learn more” style links (e.g. [?]), that you only see while interacting with the editor, open in a new tab.

Normal links (e.g. links in the footer) have normal behavior, but we detect if you have unsaved changes in the editor and prompt you to save them before you leave.

If you do leave to another site (or your browser crashes), we save the state of the editors in localStorage so you don’t lose work.

Checkout is another case here. Of course, you don’t want to lose customers during their checkout process. A link to something like “shipping information” should be openable without them losing their place in checkout.

“Reading an article”, in my opinion, doesn’t qualify here. Since it’s (generally) so easy to get back to (most browsers even scroll down to where you were), there is no risk of real loss, and readers are really skimmers anyway.

A Good Reason: Some technologically obscure point

I’m building an email where people in Outlook Kangaroo 2009 Enterprise Edition need to open it but links need to have target="blank" on them otherwise they open in the sidebar viewing panel and …

Fine.

Tech

In case you have to…

Forcing user to verify they want to leave page:

window.onbeforeunload = function() { return "Two buttons will be below this message asking if the user wants to stay on this page or leave."; }

Correct HTML

If you are going to do it, not only do you need the target attribute for the functionality, you need to rel attribute for security.

<a href="http://website.com" target="_blank" rel="noopener">Link Opens in New Tab</a>

Read more about the security issue.

Drama

I realize I’ve been pretty opinionated here. This is one of those topics where everyone has an opinion. Feel free to share those opinions of course but let’s keep things cool and focus on situations, solutions, and data if we can.

1 <form> s can have target="_blank" too. I would think it’s a more uncommon use case, but the same type of thinking in this article would hold true.