Default behavior and core types
The HTML button element has a default type of submit, which means a button inside a form will submit the form when activated. There are three standardized values: submit (sends the form data), reset (resets controls to initial values), and button (intentionally does not submit). Explicitly declaring the type prevents ambiguity, avoids unintended form submissions, and improves maintainability across scripts and frameworks.
Values and semantics
submit: Form submission
type="submit" is used for actions that commit data, such as saving or progressing through a workflow. A form can have multiple submit buttons, each with a distinct name and value to indicate which action was requested. Use formaction to override the endpoint on a per-button basis when necessary. This value is appropriate for primary and secondary submission controls inside or near forms.
reset: Resetting form values
type="reset" restores all successful controls within the same form to their initial values. It is most useful in multi-step or complex forms where users may want to undo changes. Consider confirmation or careful UX design, because destructive resets can remove entered data without warning. Prefer saving drafts or providing undo flows instead of relying heavily on reset behavior.
button: Neutral action
type="button" declares that the element is a control without implicit form submission or reset behavior. It is commonly paired with JavaScript to trigger custom interactions, open dialogs, or drive progressive enhancement. Using this value explicitly avoids accidental submits when scripts are absent or delayed, which supports robustness and progressive enhancement.
Behavior differences by context
Outside a form, button elements have no default submission behavior; they rely entirely on scripts. Inside a form, the implicit default type is submit unless overridden. This can cause unexpected navigation or data submission if authoring tools or legacy code do not declare the type. Variations in legacy browsers and server configurations may affect how form data is encoded and submitted; testing across environments is important for reliability.
Accessibility and internationalization
Buttons should have meaningful accessible names via visible text or an accessible name API (such as aria-label or title) so users of assistive technologies understand their purpose. The disabled attribute can prevent interactions when actions are unavailable. Right-to-left languages do not change type semantics, but layout and associated icon positioning may require attention to maintain clarity across locales.
Implementation best practices and examples
Always specify the type attribute to make behavior predictable and future-proof. Use submit for data submission, reset only when intentional and confirmed safe, and button for scripted controls. Coordinate naming and value attributes on submit buttons to identify which action occurred, and avoid ambiguous or redundant controls. Validate and secure server-side, because client-side controls can be bypassed.
Quick guidance for common patterns
- Standalone form submit: <button type="submit">Save changes</button>
- Cancel or secondary action to form endpoint: <button type="reset">Reset</button>
- Dialog or UI trigger handled by JavaScript: <button type="button">Open settings</button>
Browser compatibility and notes
All modern browsers support the three standardized types consistently. Legacy user agents may exhibit minor differences in default rendering or handling of omitted types, but the semantic and functional distinctions remain stable. Maintain type declarations and avoid relying on defaults to reduce cross-browser variability. Well-formed markup with explicit types contributes to stable behavior across rendering engines and assistive technologies.
Key attributes at a glance
| Attribute | Verified detail | Source type |
|---|---|---|
| type | submit | reset | button | HTML specification |
| default when omitted inside form | submit | HTML specification |
| form-associated behavior | submits or resets the closest form based on type | HTML specification |
| formaction override | applies when type="submit" | HTML specification |
Common pitfalls and validation
Relying on implicit defaults can lead to accidental submissions, particularly when forms are generated by editors or when markup is refactored. Validate that each button’s type matches its intended purpose and test scenarios with and without JavaScript. Use server-side checks to confirm authorization and data integrity, because client-side attributes do not enforce security. Automated checks can catch missing types and invalid values during development and deployment.
SEO and maintainability considerations
Correct semantics reduce runtime errors and improve usability, which indirectly supports SEO by lowering bounce rates and supporting structured interactions. Explicit types make behavior predictable across crawlers, testing tools, and frameworks. Keep markup consistent and documented so teams and component libraries can reuse patterns safely. Pair accessible labels with clear naming for submit buttons to support analytics and server-side logging of conversions.