The Difference Between a Button and a Link
The Difference Between a Button and a Link
July 28, 2026
Of the three proposals in the Triptych Project, my multi-year odyssey to add a few small-but-powerful features to HTML, the one that generates the most questions is Button Actions.<br>The proposal itself is very straightforward:<br>we want to add the action and method attributes to the button.
button action="/begin" method="GET">Startbutton><br>Button Actions are such a simple primitive that people often ask why they’re needed.<br>The answer rests on a distinction that web users intuitively understand but rarely have to think about directly:<br>the difference between a button and a link.
I added a detailed “Buttons vs Links” section to the proposal, but I think it deserves a blog-style explanation as well, because most of the existing ones miss the mark.
If you think I forgot to mention something, please give the proposal a read first, to see if I addressed it there.<br>If I didn't, definitely let me know.
Buttons have a fixed context
Links represent a destination while<br>buttons represent an action.<br>Functionally, this means that links let users control what context they open in, while buttons don’t.
Web browsers offer countless affordances for re-contextualizing a link.<br>Clicking or tapping the link will navigate the current page to that destination.<br>Mouse users can middle-click the link to open it in a new tab or hover over the link to see where it goes.<br>Context menus (right-click on desktop, long tap on mobile) have lots of link-specific options.
Web users are very familiar with the features that come with links. They know how to open them, copy them, bookmark them, share them with friends, and maintain them in an inadvisable number of browser tabs.
The semantics of a link—the notion that they represent an independently-navigable destination—make it possible for browsers to build all these features.<br>The hyperlink predates the invention of the browser tab, but when browsers added tabs, websites didn’t have to do anything to support them;<br>links represented destinations that could be re-contextualized, so browsers could simply invent a new context for them to open in.<br>Every website instantly got upgraded with a huge new feature.
We used to have to open each Wikipedia article in its own window. Imagine that!<br>Buttons have none of these features.<br>By default, they cannot be middle-clicked, control-clicked, or hovered over for more information.<br>Buttons don’t allow you to copy their action the way you can copy the href of a link.<br>Their context menus contain no affordances for saving the action or doing it somewhere else.
These are not omissions, but deliberate choices based on the button’s semantics:<br>buttons trigger actions inside a specific browsing context (almost always the current one).<br>Copying, sharing, bookmarking—these are all features for re-contextualizing the action of a link.<br>Buttons serve a complimentary purpose because they don’t allow for any of that.
When should buttons navigate?
A common misconception is that links are for navigating the page, while buttons are for everything else.<br>This is incorrect on both counts.
Buttons regularly perform navigations.<br>Clicking a logout button navigates the current page to a logged-out one;<br>clicking a “search” button navigates the current page to the query results.
And links are often used in situations where they don’t trigger navigations.<br>Relative links can jump around the current page;<br>mailto links can open email clients;<br>download links can save a file to your computer.<br>None of these are navigations, but they are all “destinations” that can be opened, saved, and shared in customizable ways.
Navigations should be represented as buttons when their action happens in a fixed context that is not available to be re-contextualized (e.g. bookmarked, shared, middle-clicked, etc.).<br>A frequent place this comes up is with forms that let you edit something you’ve already saved, like a comment on a website.<br>When you click “Edit”, the website shows you an editable text area with options like this:
I had a great day today!<br>Save<br>Save as draft<br>Cancel<br>Delete
Users will easily intuit what each button does:
“Save” updates the comment with whatever is in the
“Save Draft” saves the content of the without publishing it
“Cancel” closes the editable form
“Delete” removes the comment entirely
Should “Cancel” be a link?<br>No!<br>Its job is to close the edit view.<br>Not only does making this a link incorrectly communicate its purpose—visually and otherwise—but it saddles the form “control” with lots of features, like bookmarking and middle-clicking, that have incorrect behavior.
This is a simplified example of a basic CRUD lifecycle, but if you'd like to see a real-world one, the Django blog wrote about how a similar pattern is widespread in their codebase.
There are many plausible ways these buttons could be implemented, but none of those implementations should present themselves to the...