Buttons vs links

We often mix up buttons and links because both are clickable and both can change the page. That confusion is bad for accessibility, for expectations, and for the browser behaviours users rely on.

This is why it matters:

• Buttons and links are not interchangeable. Each element has its own role.
• Screen readers announce buttons and links differently.
• Mouse interactions are different: links can be middle-clicked, opened in a new tab, and copied as a URL.
• Users expect links to go somewhere and buttons to do something.

Buttons should trigger actions

A button is an action control. It should do work inside the page or app:

• submit a form
• open or close a modal
• toggle a state
• call an API
• create an item

If the element is doing something, it should be a button.

Examples:

• Save draft
• Delete item
• Toggle filters
• Copy code

Buttons can also change the page, but only as a result of an action.

Links should take you somewhere

A link is a navigational control. It should take the user to a location:

• a new page
• a section on the current page
• download a file
• an anchor destination

If the element moves focus or changes the URL intentionally, a link is usually the right choice.

Examples:

• Read more
• Go to section
• View details
• Download report

Scroll-to-section / anchor navigation

Going to a section or scrolling to the top is also navigation.

Use an anchor or link for this, not a button, when the intent is to move the user through content.

Create-and-navigate

A common pattern is “create, then navigate”.

For example:

• click Create project
• UI sends data to the server
• server responds with the new item
• app navigates to the new item page

This pattern I am currently trying to figure out the best solution.

I have found guidance saying that it should usually stay a button, because the interaction is not just navigation. The click triggers a create action first, then navigation is a consequence. However, I can also think of scenarios where you would want the link behaviour.

Why the distinction matters

Accessibility

Screen readers expose roles and context from HTML elements.

• A <button> is announced as a button.
• An <a href="..."> is announced as a link.

If something looks like a link but acts like a button, users may hesitate or be confused.

Interaction expectations

Links can be opened in a new tab, copied, or shared. Buttons cannot.

If your control is expected to navigate, it should be link-marked. If it is expected to take an action, it should be button-marked.

Keyboard and focus

Buttons can be activated with space/enter, and links with enter.

A hidden navigation action disguised as a button can disrupt this expected keyboard flow.

When you need to do both

Sometimes an interaction feels like both navigation and action.

Ask:

• What is the end state of the interaction?
• Is the primary goal to move the user somewhere?
• Is the primary goal to perform an operation?

If the first result is navigation, use a link. If the first result is an action with optional follow-up navigation, use a button.

Example: create then go to the newly created page

This is a button because the primary interaction is creation. Navigation is a side effect.

Example: open a page with a parameter-changing action

If the user is simply choosing a destination, a link is better.

Special cases

Download links

<a download> is a link with specific semantics.

It is still navigation, because it targets a resource. Don’t make it a button just because it triggers a download.

Links that trigger file downloads or anchors

These are still links when the intent is resource access or location change.

Buttons that navigate within a single-page app

In a SPA, clicking a button may perform state management and then update the route.

Even then, it should remain a button if the route update is a result of the action.

Practical guidance

• Use a button for actions.
• Use a link for navigation.
• Don’t use role="button" on a link unless it truly behaves like a button.
• Don’t use onclick on an anchor to perform an action if the result is not navigation.
• Preserve native semantics whenever possible.

Summary

Buttons need to do something. Links need to take you somewhere.

That simple rule keeps interactions predictable, accessible, and easier to maintain.

When in doubt, think about the end state: is the user trying to act, or trying to move?