My company is using some rather bizarre download buttons associated with documents that can be downloaded:

enter image description here

It looks like these are abused anchor (<a>) elements which show up in a browser as javascript:void(0). If you left-click on them, something magical happens and the document is downloaded. If you right-click on them, you get a browser popup dialog saying

Right click is disabled for this asset! You can still download via direct/left click.

I find this abhorrent (as compared to plain old hyperlinks) but I can't put my finger on why, and I would like to pass along some reputable article that talks about pros/cons of plain hyperlinks vs. "magical" action-on-click.

Could someone help me find a reputable source for when/why to use plain links or "magic" buttons? The best I could find is https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a which says

onclick events

Anchor elements are often abused as fake buttons by setting their href to # or javascript:void(0) to prevent the page from refreshing, then listening for their click events .

These bogus href values cause unexpected behavior when copying/dragging links, opening links in a new tab/window, bookmarking, or when JavaScript is loading, errors, or is disabled. They also convey incorrect semantics to assistive technologies, like screen readers.

Use a <button> instead. In general, you should only use a hyperlink for navigation to a real URL.

So MDN suggests a <button>... but if someone is downloading a document, why/when should that be the case instead of a plain hyperlink?

Similar content on https://www.30secondsofcode.org/articles/s/javascript-void-links

Finally, when creating an empty link, one should always consider more semantically appropriate alternatives, such as a , or tag. After all, a link should always behave like a link and hijacking it with JavaScript or any other means is bound to run into some accessibility problems sooner or later.

Again, the advice is use a button or other element... but why use a button? what is the advantage of doing so?

other references I've found:

  • I guess If you can use both in your design in a way to make it look minimal, clean, and elegant from a design perspective and also functionally useful then you're good to go. Check this design how I used buttons here kultarsingh.dribbble.com Commented Aug 19, 2021 at 12:50
  • 5
    I find that kind of URL obfuscation really annoying, as I often download files to another machine than the one my browser is on, or use a download manager for large files (especially as browsers sometimes transparently decompress files, altering the checksum). Commented Aug 19, 2021 at 15:33
  • @SimonRichter luckily a vast majority of people have ample storage space. Download the file and email it to yourself. If it's too large, copy and paste the URL hosting the 'button' and send that to your other machine. I can see how it may be annoying.. but really, it's quite trivial.
    – TCooper
    Commented Aug 19, 2021 at 23:05
  • 5
    @TCooper, usually the download page will be at the end of a wizard, so copying the URL doesn't work, and downloading a 6 GB file (oddly specific, I know) over LTE just to copy it back to my server over LTE is not a solution. Commented Aug 20, 2021 at 8:20
  • @SimonRichter fair enough, I’ve never run into that issue specifically, but does sound like a huge pain
    – TCooper
    Commented Aug 20, 2021 at 14:05

5 Answers 5


Buttons denotes important actions, therefore they are scarce and noticeable.

Links are common, and you may have a lot of them, since they are supposed to take you to an anchor, whether it's on the same page or another page (hence the <a> tag for anchor).

You can style an element to look like a button. As a matter of fact it's pretty common. However, it's not the same in terms of semantic code and accessibility. For example, if you use a screen reader, you can use the space or enter keys on buttons, but <a> tags only react to enter key. Therefore, if you see an <a> element disguised as a button and you press the space key and nothing happens, you'll be quite confused.

Additionally, using a button (when correctly used), provides a hint to user about an important action with just a quick scan, something very difficult to achieve with a text link

So, in this particular case you mention, a button is the right choice, there's nothing bad about it.

You can read more in the article "Proper Use of Buttons and Links" and the book "Don't make me think" by Steve Krug has a section about this subject when it talks about affordances

  • 7
    A big problem here is that the publisher often has a different-from-the-user (i.e. wrong) view of what constitutes an "important action". For example, from their standpoint "downloading a document" may be an "important action", while to the user it's ordinary navigation of the web. Commented Aug 19, 2021 at 16:21
  • 5
    "Important action" should correspond roughly to what would merit a POST operation rather than a GET: operations which have side effects (change the state of something). Commented Aug 19, 2021 at 16:31
  • 3
    @R..GitHubSTOPHELPINGICE Arguably a button that initiates a download does change something - but locally rather than on the server. Commented Aug 19, 2021 at 17:01
  • 3
    @manassehkatz-Moving2Codidact: It doesn't. The act of choosing to save the document rather than just view it in the browser, which takes place after clicking the button, is the only place "state" (the filesystem storage) changes. And indeed that involves a button, but it's a button in a user interface element controlled by the browser/OS, not the site, as it must rightly be since the site does not have authority to change your local computer's state. Commented Aug 19, 2021 at 17:53
  • 10
    @R..GitHubSTOPHELPINGICE From a pure standpoint, you are 100% correct. But your average (non-programmer/developer) user, if you tell them "Here's a neat thing about web sites: Links go places, buttons make things change." Your typical user (at least in my experience) will consider "download a file to my computer" to be "make things change" and won't distinguish that they have to click/acknowledge an additional local browser dialog box to make it happen - those dialog boxes are "automatic" in the eyes of many users. Commented Aug 19, 2021 at 18:09

So MDN suggests a ... but if someone is downloading a document, why/when should that be the case instead of a plain hyperlink?

Right from your quote:

These bogus href values cause unexpected behavior when copying/dragging links, opening links in a new tab/window, bookmarking, or when JavaScript is loading, errors, or is disabled. They also convey incorrect semantics to assistive technologies, like screen readers.

When I download a PDF, I never know if it's going to download itself as a file, or open right there. Often times, I want to keep using the website to look for other info. I'll often always open links in a new tab by using middle click. If the link is a "fake" one that goes to some worthless URL, that just sends me to the page I came from.

could you point me at any reputable references

MDN, as you cited, sure is one! It's the preferred source of documentation by Mozilla, Google, Microsoft, the W3C, and Samsung. But here's straight from the W3C spec:

An HTML <a> element is defined as:

If the a element has an href attribute, then it represents a hyperlink (a hypertext anchor) labeled by its contents.

What is a hyperlink?

These are links to other resources that are generally exposed to the user by the user agent so that the user can cause the user agent to navigate to those resources, e.g. to visit them in a browser or download them.

javascript:void(0) is not a place that anyone would like to "visit...in a browser or download", while an actual link to the download sure would be.

Also, here's a university (NC State), and from Ancestry.com's design team.


I like Devin's summary that "buttons denote important actions". I would pair that with a statement that applies more to the current generation of Internet users than yours & mine: "Links denote locations." In fact, following modern Internet norms, I might assume that such a link is likely to lead to one of those "Your download should start in 5 seconds..." pages.

For those like you and I who know how the Internet works or used to work, a file is a location. But to a younger user, there's actually something quite sketchy about the idea of linking directly to a file. (In fact, I just asked my younger brother about hyperlinks for downloading, and he spotaneously used the phrase "less credible".)

This generation is not used to actual file locations being exposed, but rather handled and often obfuscated programmatically. For example, to download your digital goods or get a PDF of a receipt may be an API call rather than a file sitting on the server. That said, there are certainly exceptions, including big-name ones like Amazon, which gives a hyperlink for downloading your receipt...

As for the actual button behaviour, that's a slightly different question. First of all, it's indisputable that JS void action links are anti-user. They defeat several interactions you can otherwise do with links, as you noted. There are two reasons to use them:

  1. You can't figure out how to implement the behaviour as an actual link. For example, perhaps you download the file via some sort of download manager–like behaviour.

  2. You want to disable the additional interactions, ensuring that direct button activation is the only way. For example, perhaps you want to obscure the mechanism by which it's downloaded.

If neither of those conditions apply, I would say the button is a step in the right direction, but it should be implemented as an <a> tag with some CSS styling, thus retaining the additional interactions.

Incidentally, note that the design of your company's button is not the most attractive or modern. Here are a few options in a continuum from plainest to most semantically rich and easy to identify. (The reason I include this is because we're talking partly about the user's interpretation of download links and buttons, and I consider that the format & symbology contributes to that interpretation.)

download button options

  • I agree with your assertions and think they are well thought out... but could you point me at any reputable references that state the same philosophy? I really want some information I can forward to the appropriate people in my company, and a stackexchange answer doesn't have as much weight as something published by a well-known authority.
    – Jason S
    Commented Aug 19, 2021 at 17:08
  • I disagree with all of this. The average user wants to click somewhere and download a file. They don't care what the thing looks like (as long as it's not an advertisement) and they definitely don't care whether you are trying to obfuscate the download URL! Commented Aug 20, 2021 at 8:41
  • 2
    @user253751 One of our basic assumptions in UX is that people do care what things look like, whether they consciously think about it or not. Of course they don't care whether I'm trying to obfuscate the URL — unless they want to download the file in an alternative manner :) — the obfuscation is simply correlated with location vs. action insofar as it influences whether you can use a direct link (and hence better suited to the UX idiom of hyperlink). Commented Aug 20, 2021 at 14:05
  • 1
    @HappyDog It's definitely not central to the point. Moved to the bottom and added a note of explanation. Commented Aug 20, 2021 at 14:11
  • 1
    @HappyDog sure but kinda pedantic... you know what i mean. if it's dynamically generated based on data specific to a certain thing (transaction, user etc.) it doesn't always make sense to have it at (a GET request at) a fixed url. anyway, my point is that conceptually links should be for static data (do note that whether it is "dynamically generated makes zero difference to the end user whether it appears static or not) and forms/buttons should be for dynamic data
    – user
    Commented Aug 31, 2021 at 2:11

There are other good answers about the issues around javascript:void(0) but for me, the question about whether or not it is more appropriate to use a link or a button comes down to whether the download is simply a URL (in which case a link should be used) or something more complex (POST request, API action, etc.) in which case a button is more appropriate.

Basically, if I can access the file simply by pasting a URL into my address bar, then I would expect to see a link to that file, rather than obfuscating it via JavaScript.

I think it is reasonable to use styling to stop it looking like a standard link and more of a call to action - even to the extent that it looks like a button, if that is more intuitive for your audience - but you should ensure the underlying semantics are appropriate, first.

(FWIW I've also done it the other way round, e.g. where - for technical reasons - I've needed to implement 'cancel' as a button. However, as it is conceptually just a link back to some other page, I styled it to look like a normal anchor tag.)


Another factor here--it's an anti-hotlink defense. If no URL pointing to the file exists nobody can hotlink it. It's also hidden from robots.

  • 2
    Not really; it turns into a download and if I go to the downloads window in my browser I can find it. But yeah, it's obscured. Which is not really what my company wants; the downloads in question are public documentation which we want people to find.
    – Jason S
    Commented Aug 21, 2021 at 16:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.