HTML <button> vs <input type="button">: Differences, Use Cases, and Best Choice

By the end of this page, you will understand how <button> and <input type="button"> differ in HTML, how they behave in forms, when each is appropriate, and why <button> is usually the more flexible choice. You will also learn common pitfalls, browser considerations, and practical patterns used in real codebases.

<button> and <input type="button"> are both clickable form-related HTML elements, but they are not identical.

The biggest differences are:

• Content support: <button> can contain HTML content such as text, icons, and spans. <input type="button"> cannot; its label comes from the value attribute.
• Default behavior in forms: <button> defaults to type="submit" if used inside a form and no type is specified. <input type="button"> does not submit a form unless you use type="submit" instead.
• Flexibility: <button> is more customizable and is generally preferred for modern interfaces.
• Simplicity: <input type="button"> is simpler but more limited.

Examples:

<input type="button" value="Save" />

Think of these two elements as two kinds of labeled switches:

• <input type="button"> is like a pre-printed plastic button. You can change the label, but only in a simple way.
• <button> is like a custom display button. You can put text, an icon, or extra styling hooks inside it.

Both can be clicked, but one is much more flexible.

Another useful way to think about it:

• Use <input> when the control is a simple single-purpose form input.
• Use <button> when you want a general clickable UI control with richer content or clearer semantics.

Basic syntax

<input type="button">

<input type="button" value="Click me" />

• The visible label comes from value.
• It cannot contain child elements.
• By itself, it does not submit a form.

<button>

<button type="button">Click me</button>

• The visible label comes from the content between the opening and closing tags.
• It can contain text, icons, and other inline HTML.
• If type is omitted inside a form, it defaults to submit.

Example: simple action button

<button type="button" id="openDialogBtn">Open dialog</>

Consider this example:

<form id="profileForm">
  <input type="text" name="name" value="Ava" />
  <button id="previewBtn" type="button">Preview</button>
  <button id="saveBtn" type="submit">Save</button>
</form>

<script>
  const form = document.getElementById('profileForm');
  const previewBtn = document.getElementById('previewBtn');

  previewBtn.addEventListener('click', () => {
    alert('Previewing without submitting');
  });

  form.addEventListener(,  {
    event.();
    ();
  });

Common cases for <button>

• Buttons with icons
  • Save, delete, edit, download buttons
• Modal and dialog controls
  • Open modal, close modal, confirm, cancel
• Toolbar actions
  • Bold, italic, refresh, filter
• Form submit buttons
  • Login, register, checkout
• Loading states
  • Buttons that change text to Saving...

Example:

<button type="submit" class="primary-btn">
  <span>Sign in</span>
</button>

Common cases for <input type="button">

• Very simple legacy forms
• Old codebases where form controls are consistently built with <input> elements
• Small one-off actions with a plain text label

Example:

In real projects, developers usually prefer <button> for most interactive controls.

Common patterns

1. Explicit button types

Developers often always write the type to avoid bugs:

<button type="button">Open menu</button>
<button type="submit">Save</button>
<button type="reset">Reset</button>

This avoids accidental form submissions.

2. Buttons for JS actions

<button type="button" id="loadMoreBtn">Load more</button>

Used for:

• opening menus
• toggling filters
• showing hidden content
• retrying failed API requests

3. Guard clauses in event handlers

1. Forgetting the type on <button>

Broken example:

<form>
  <button id="openHelp">Help</button>
</form>

Problem:

• Inside a form, this defaults to submit.
• Clicking it may submit the form unexpectedly.

Better:

<form>
  <button type="button" id="openHelp">Help</button>
</form>

2. Using <input type="button"> when rich content is needed

Broken idea:

<input type="button" = />

<!-- Simple action button -->
<button type="button">Click me</button>

<!-- Simple input-based button -->
<input type="button" value="Click me" />

<!-- Form submit -->
<button type="submit">Submit</button>
<input type="submit" value="Submit" />

Key rules

• <button> can contain HTML.
• <input type="button"> cannot contain HTML.
• <button> inside a form defaults to type="submit".
• <input type="button"> does not submit a form.
• Use links for navigation, not buttons.
• Do not nest <button> and <input>.

Quick decision guide

Is <button> better than <input type="button">?

Usually yes for modern interfaces, because <button> is more flexible and can contain HTML such as icons and spans.

Why does my <button> submit the form unexpectedly?

Because inside a form, <button> defaults to type="submit" unless you specify type="button".

Does <input type="button"> submit a form?

No. It only acts as a clickable button unless you use type="submit" instead.

Can I put an icon inside <input type="button">?

No. It only displays the text from its value attribute. Use <button> if you need richer content.

Is <button> supported in modern browsers?

Yes. It is widely supported and commonly used in modern web development.

Should I use a button or a link?

Use a button for actions like saving, opening, deleting, or toggling. Use a link for navigation to another page or route.

• HTML forms — Buttons often live inside forms, so form behavior is directly related.
• type="submit", type="button", and type="reset" — These determine how button-like controls behave.
• DOM event handling — Buttons are commonly connected to JavaScript click and submit handlers.
• Accessibility semantics — Choosing the correct interactive element improves usability and screen-reader behavior.
• Anchor (<a>) vs button (<button>) — A common related decision: navigation versus action.
• Form validation — Submit buttons are closely tied to browser validation and form submission flow.
• Disabled state — Real interfaces often disable buttons during invalid or loading states.