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" />

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

These may look similar, but they are defined differently in HTML.

Why this matters in real programming:

• Buttons are used in forms, dialogs, modals, menus, and interactive UI.
• Choosing the wrong element can cause accidental form submission.
• Some designs need icons or nested markup inside the button, which only <button> supports cleanly.
• Accessibility and semantics are easier to maintain when the element matches its purpose.

A very important point: you do not combine <button> and <input type="button"> into one control. They are alternative elements, not elements meant to wrap each other.

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</button>

<input type="button" id="openDialogInput" value="Open dialog" />

<script>
  document.getElementById('openDialogBtn').addEventListener('click', () => {
    alert('Button clicked');
  });

  document.getElementById('openDialogInput').addEventListener('click', () => {
    alert('Input button clicked');
  });
</script>

Both work for JavaScript-triggered actions.

Example: richer button content

<button type="button" class="save-btn">
  💾 <span>Save changes</span>
</button>

This is easy with <button>, but not possible with <input type="button"> because it cannot contain nested HTML.

Example: form behavior

<form>
  <input type="text" name="username" />
  <button>Submit form</button>
</form>

In this case, the button submits the form because the default type is submit.

Safer version:

<form>
  <input type="text" name="username" />
  <button type="button">Just a normal button</button>
  <button type="submit">Submit form</button>
</form>

This makes the intention explicit.

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('submit', (event) => {
    event.preventDefault();
    alert('Form submitted');
  });
</script>

What happens step by step

1. The page renders a text input and two buttons.
2. The Preview button has type="button".
3. When the user clicks Preview, only its click handler runs.
4. The form is not submitted.
5. The Save button has type="submit".
6. When the user clicks Save, the form tries to submit.
7. The submit event listener runs.
8. event.preventDefault() stops the browser from navigating away.
9. The alert shows Form submitted.

Why this example matters

It shows the key distinction:

• type="button" is for actions like opening a dialog, previewing, toggling UI, or running JavaScript.
• type="submit" is for sending form data.

If you used:

<button>Preview</button>

inside the form without a type, it would behave like type="submit", which often surprises beginners.

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:

<input type="button" value="Calculate" onclick="runCalculation()" />

When not to use either

If the action is actually navigation to another page, use an anchor:

<a href="/pricing">View pricing</a>

Use a button for actions and a link for navigation.

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

<button type="button" id="deleteBtn">Delete</button>

const deleteBtn = document.getElementById('deleteBtn');

deleteBtn.addEventListener('click', () => {
  const confirmed = window.confirm('Are you sure?');
  if (!confirmed) return;

  console.log('Item deleted');
});

This pattern keeps button logic clear.

4. Disabled states during async work

<button type="button" id="saveBtn">Save</button>

const saveBtn = document.getElementById('saveBtn');

async function saveData() {
  saveBtn.disabled = true;
  saveBtn.textContent = 'Saving...';

  try {
    await new Promise(resolve => setTimeout(resolve, 1000));
  } finally {
    saveBtn.disabled = false;
    saveBtn.textContent = 'Save';
  }
}

saveBtn.addEventListener('click', saveData);

This is much easier with <button> because changing its text content is straightforward.

5. Styling systems and component libraries

In design systems, button components are almost always built on top of <button> because it supports:

• nested icons
• loading spinners
• screen-reader-friendly labels
• flexible styling hooks

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" value="💾 Save" />

This works only for plain text-like labels. You cannot add structured markup such as:

• an icon wrapper
• a loading spinner element
• visually hidden helper text

Better:

<button type="button">
  <span aria-hidden="true">💾</span>
  <span>Save</span>
</button>

3. Using a button for navigation

Broken semantics:

<button type="button" onclick="location.href='/about'">About</button>

Usually better:

<a href="/about">About</a>

Use links to move between pages and buttons to trigger actions.

4. Trying to combine <button> and <input>

Incorrect:

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

These are separate controls and should not be nested this way.

5. Assuming <button> has poor browser support

This is outdated for modern web development. <button> is widely supported.

The real issue is not compatibility in current browsers, but understanding its default form behavior and using it intentionally.

Related input types

Which should you choose?

• Choose <button> for most modern cases.
• Choose <input type="button"> only when you specifically want a very simple input-style button or are working in an older or already established pattern.
• Always specify the type on <button> when used inside or near forms.

<!-- 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

• Need icon or custom markup? Use <button>.
• Need a form submit control? Usually use <button type="submit">.
• Need a plain JS-triggered control? Prefer <button type="button">.
• Maintaining older simple markup? <input type="button"> may still be acceptable.

JavaScript text updates

button.textContent = 'Saving...';
input.value = 'Saving...';

Safe habit

Always write button types explicitly:

<button type="button">Open</button>
<button type="submit">Save</button>

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.

Can I combine <button> and <input type="button">?

No. They are alternative elements and should not be nested together as one control.

• 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.