The element “input” must not appear as a descendant of the “button” element.

The <button> element has a strict content model defined by the WHATWG HTML Living Standard: it accepts phrasing content, but with the explicit exclusion of interactive content. The <input> element is classified as interactive content, which means nesting it inside a <button> produces invalid HTML and triggers this W3C validator error.

Why This Is a Problem

Unpredictable browser behavior: When interactive elements are nested inside a <button>, browsers must figure out which element should receive user interactions like clicks, focus, and keyboard input. Different browsers handle this differently — some may ignore the inner <input> entirely, while others may produce confusing behavior where clicks are swallowed by the <button> before reaching the <input>.

Accessibility issues: Screen readers and other assistive technologies expect a <button> to contain descriptive text or simple phrasing content, not other form controls. Nesting an <input> inside a <button> creates a confusing and potentially unusable experience for users who rely on assistive technology. The relationship between the two controls becomes ambiguous — is the user interacting with the button or the input?

Standards compliance: Valid HTML is the foundation for consistent rendering and behavior across browsers and devices. Using invalid nesting can lead to subtle bugs that are difficult to diagnose, especially as browsers update their parsing behavior.

Other Elements You Cannot Nest Inside <button>

The restriction applies to all interactive content, not just <input>. You also cannot place these elements inside a <button>:

• <a> (with an href attribute)
• <button>
• <select>
• <textarea>
• <label>
• <audio> and <video> (with controls)
• <embed>, <iframe>, <object>
• Any element with a tabindex attribute

How to Fix It

The fix is straightforward: move the <input> out of the <button> so they are sibling elements. Wrap them in a <form>, <div>, or another suitable container, and use CSS to achieve any desired visual layout.

Examples

❌ Invalid: <input> nested inside <button>

<button>
  Submit
  <input type="text" name="example">
</button>

This triggers the error because <input> is interactive content placed inside a <button>.

✅ Fixed: <input> and <button> as siblings

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

Both elements are direct children of the <form>, making the markup valid and the controls independently accessible.

❌ Invalid: Hidden <input> inside <button>

You might think a hidden input is okay since it’s not visually interactive, but <input type="hidden"> is still an <input> element and is still prohibited inside <button>:

<button type="submit">
  Save
  <input type="hidden" name="action" value="save">
</button>

✅ Fixed: Hidden <input> moved outside <button>

<form>
  <input type="hidden" name="action" value="save">
  <button type="submit">Save</button>
</form>

❌ Invalid: Checkbox inside a <button> for a toggle effect

<button class="toggle">
  <input type="checkbox" name="darkmode"> Dark Mode
</button>

✅ Fixed: Use a <label> instead

If the intent is a clickable toggle, a <label> paired with a checkbox achieves the same visual result with valid, accessible markup:

<label class="toggle">
  <input type="checkbox" name="darkmode"> Dark Mode
</label>

Alternatively, if you truly need a button that toggles state, use JavaScript with the aria-pressed attribute instead of embedding a checkbox:

<button type="button" class="toggle" aria-pressed="false">
  Dark Mode
</button>

Keep <input> and <button> as separate, sibling elements. If you need them to appear visually grouped, use CSS for layout and styling rather than nesting one interactive element inside another.

Find issues like this automatically

Rocket Validator scans thousands of pages in seconds, detecting HTML issues across your entire site.

Start Free Trial See Pricing