HTML Guides for form

HTML forms have built-in constraint validation that is enabled by default. When a user submits a form, the browser automatically checks inputs against their constraints (such as required, type="email", pattern, min, max, etc.) and prevents submission if any validation fails. There is no need to add a validate attribute to opt into this behavior because it is the default.

The HTML specification defines novalidate as a valid boolean attribute on the <form> element to disable this default validation, but it does not define a corresponding validate attribute. Using validate will trigger a W3C validation error because the browser doesn’t recognize it and will simply ignore it.

This matters for several reasons:

• Standards compliance: Invalid attributes make your HTML non-conforming, which can cause issues with automated testing and quality tools.
• Developer confusion: A validate attribute suggests it’s doing something functional, but it has no effect. Future maintainers may incorrectly believe it’s enabling validation and be reluctant to remove it.
• Accessibility and tooling: Screen readers and other assistive technologies rely on well-formed HTML. Unrecognized attributes can lead to unpredictable behavior in some user agents.

To fix this issue, determine your intent:

1. If you want form validation enabled — simply remove the validate attribute. Validation is on by default.
2. If you want form validation disabled — replace validate with novalidate.

Examples

Incorrect: using the invalid validate attribute

<form validate action="/submit">
  <label for="email">Email:</label>
  <input type="email" id="email" name="email" required>
  <button type="submit">Submit</button>
</form>

This triggers the error: Attribute “validate” not allowed on element “form” at this point.

Correct: relying on default validation (attribute removed)

Since constraint validation is enabled by default, simply remove the invalid attribute:

<form action="/submit">
  <label for="email">Email:</label>
  <input type="email" id="email" name="email" required>
  <button type="submit">Submit</button>
</form>

The browser will automatically validate the email input — checking both the required constraint and that the value matches a valid email format — before allowing submission.

Correct: using novalidate to disable validation

If your intention is to disable built-in validation (for example, because you handle validation with JavaScript), use the novalidate attribute instead:

<form novalidate action="/submit">
  <label for="city">City:</label>
  <input type="text" id="city" name="city" required>
  <button type="submit">Submit</button>
</form>

In this example, even though the input has the required attribute, the browser will not prevent form submission when the field is empty, because novalidate tells the browser to skip constraint validation on submission.

Using formnovalidate on a specific button

If you want validation enabled for normal submission but want to bypass it for a specific button (such as a “Save Draft” button), use the formnovalidate attribute on that button instead of disabling validation for the entire form:

<form action="/submit">
  <label for="name">Name:</label>
  <input type="text" id="name" name="name" required>
  <button type="submit">Submit</button>
  <button type="submit" formnovalidate formaction="/save-draft">Save Draft</button>
</form>

The “Submit” button will enforce validation, while the “Save Draft” button will skip it. This approach gives you fine-grained control without needing an invalid attribute.

The action attribute tells the browser where to send form data when the form is submitted. According to the WHATWG HTML living standard, if the action attribute is specified, its value must be a valid non-empty URL potentially surrounded by spaces. An empty string ("") does not satisfy this requirement, which is why the W3C validator flags it.

While some developers use action="" intending the form to submit to the current page’s URL, this approach is non-conforming HTML. Browsers do typically interpret an empty action as “submit to the current URL,” but relying on this behavior is unnecessary since simply omitting the action attribute achieves the same result in a standards-compliant way. When no action attribute is present, the form submits to the URL of the page containing the form — this is the defined default behavior per the HTML specification.

This issue matters for several reasons:

• Standards compliance: Non-conforming HTML can lead to unexpected behavior across different browsers or future browser versions.
• Maintainability: Using the correct approach makes your intent clearer to other developers. Omitting action explicitly signals “submit to the current page,” while action="" looks like a mistake or a placeholder that was never filled in.
• Tooling: Build tools, linters, and automated testing pipelines that rely on valid HTML may flag or break on this error.

How to Fix

You have two options:

1. Remove the action attribute if you want the form to submit to the current page URL.
2. Provide a valid URL if the form should submit to a specific endpoint.

Examples

❌ Invalid: Empty action attribute

<form action="" method="post">
  <label for="email">Email:</label>
  <input type="email" id="email" name="email">
  <button type="submit">Subscribe</button>
</form>

This triggers the error: Bad value “” for attribute “action” on element “form”: Must be non-empty.

✅ Fixed: Remove the action attribute

If you want the form to submit to the current page, simply omit action:

<form method="post">
  <label for="email">Email:</label>
  <input type="email" id="email" name="email">
  <button type="submit">Subscribe</button>
</form>

✅ Fixed: Provide a valid URL

If the form should submit to a specific endpoint, supply the URL:

<form action="/subscribe" method="post">
  <label for="email">Email:</label>
  <input type="email" id="email" name="email">
  <button type="submit">Subscribe</button>
</form>

✅ Fixed: Use a hash as a placeholder for JavaScript-handled forms

If your form is entirely handled by JavaScript and should not navigate anywhere, you can use a # as the action or, preferably, omit action and prevent submission in your script:

<form method="post" id="js-form">
  <label for="query">Search:</label>
  <input type="text" id="query" name="query">
  <button type="submit">Search</button>
</form>

document.getElementById('js-form').addEventListener('submit', function(e) {
  e.preventDefault();
  // Handle form data with JavaScript
});

In this case, omitting action is the cleanest solution. The JavaScript preventDefault() call stops the browser from actually submitting the form, so the action value is never used.

In URLs, certain characters must be percent-encoded — a process where a character is replaced by % followed by exactly two hexadecimal digits representing its byte value. For example, a space becomes %20, a hash becomes %23, and an ampersand becomes %26. The % character itself is the escape prefix, so when a URL parser encounters %, it expects the next two characters to be valid hexadecimal digits (0–9, A–F, a–f). If they aren’t, the URL is malformed.

This validation error typically arises in a few scenarios:

• A literal % is used in the URL without encoding. For instance, a filename or path segment contains a % sign that wasn’t converted to %25.
• An incomplete or corrupted percent-encoding sequence. Someone may have partially encoded a URL, leaving behind sequences like %G5 or %2 that don’t form valid two-digit hex codes.
• Copy-paste errors. A URL was pasted from a source that stripped characters or introduced stray % symbols.

This matters because browsers may interpret malformed URLs inconsistently. One browser might try to “fix” the URL by encoding the stray %, while another might pass it through as-is, leading to broken form submissions or unexpected server-side behavior. Ensuring valid URLs in the action attribute guarantees predictable behavior across all browsers and complies with both the WHATWG URL Standard and the HTML specification.

How to Fix

1. Locate every % in the URL. Check whether each % is followed by exactly two hexadecimal digits (e.g., %20, %3A, %7E).
2. Encode literal % characters. If a % is meant to appear as a literal character in the URL (not as part of a percent-encoding sequence), replace it with %25.
3. Fix incomplete sequences. If a sequence like %2 or %GZ exists, determine the intended character and encode it correctly, or remove the stray %.
4. Use proper encoding tools. In JavaScript, use encodeURIComponent() or encodeURI() to safely encode URLs. Most server-side languages have equivalent functions (e.g., urlencode() in PHP, urllib.parse.quote() in Python).

Examples

Literal % not encoded

This triggers the error because %d is not a valid percent-encoding sequence (d is only one character, and what follows may not be hex):

<!-- ❌ Bad: bare % not followed by two hex digits -->

<form action="/search?discount=20%off">
  <button type="submit">Search</button>
</form>

Encode the % as %25:

<!-- ✅ Good: literal % encoded as %25 -->

<form action="/search?discount=20%25off">
  <button type="submit">Search</button>
</form>

Incomplete percent-encoding sequence

Here, %2 is missing its second hex digit:

<!-- ❌ Bad: %2 is an incomplete sequence -->

<form action="/path/to%2file.html">
  <button type="submit">Submit</button>
</form>

If the intent was to encode a / character (%2F), complete the sequence:

<!-- ✅ Good: complete percent-encoding for "/" -->

<form action="/path/to%2Ffile.html">
  <button type="submit">Submit</button>
</form>

Invalid hex characters after %

The characters G and Z are not hexadecimal digits:

<!-- ❌ Bad: %GZ is not valid hex -->

<form action="/data%GZprocess">
  <button type="submit">Go</button>
</form>

If %GZ was never intended as encoding, escape the % itself:

<!-- ✅ Good: literal % properly encoded -->

<form action="/data%25GZprocess">
  <button type="submit">Go</button>
</form>

Using JavaScript to encode safely

When building URLs dynamically, use built-in encoding functions to avoid this issue entirely:

const query = "20% off";
const safeURL = "/search?q=" + encodeURIComponent(query);
// Result: "/search?q=20%25%20off"

This ensures every special character — including % — is properly percent-encoded before it’s placed in the action attribute.

An empty value for the name attribute on the form element is invalid and should be removed or replaced with a valid non-empty string.

The name attribute on a form element provides a way to reference forms via scripts and images, and it must not be empty. According to the HTML standard, if the name attribute is present, it must have a non-empty value. An empty string is considered invalid and will trigger HTML validator errors.

Invalid example:

<form name="">
<!-- form elements here -->

</form>

How to fix:

• Remove the empty name attribute if you don’t need it.
• Replace the empty value with a meaningful, unique name if you require it for scripting or identification.

Valid examples:

<form>
<!-- form elements here -->

</form>

<form name="registrationForm">
<!-- form elements here -->

</form>

Avoid using empty attribute values, as they do not provide any benefit and result in validation errors.

Understanding Boolean Attributes in HTML

In HTML, boolean attributes work differently from regular attributes. A boolean attribute’s presence on an element represents true, and its absence represents false. According to the HTML specification, a boolean attribute may only have three valid forms:

• The attribute name alone: novalidate
• The attribute with an empty value: novalidate=""
• The attribute with a value matching its own name (case-insensitive): novalidate="novalidate"

Any other value — such as "true", "false", "1", "0", or "yes" — is invalid and triggers this validation error. This is a common source of confusion, especially for developers coming from frameworks like React (which uses noValidate={true}) or from languages where boolean attributes accept explicit true/false strings.

Why This Matters

• Standards compliance: Using invalid values violates the HTML specification and will cause W3C validation failures.
• Unexpected behavior: While most browsers are lenient and treat any value of novalidate as “present” (meaning even novalidate="false" would disable validation, not enable it), relying on this behavior is unreliable and misleading to other developers reading your code.
• Maintainability: Writing novalidate="false" suggests the form should be validated, but the opposite is true — the attribute is present, so validation is skipped. This creates confusing, error-prone code.

About the novalidate Attribute

The novalidate attribute tells the browser to skip its built-in constraint validation when the form is submitted. Without it, the browser checks required fields, input patterns, email formats, and other constraints before allowing submission.

If novalidate is not set on the form, individual submit buttons can still bypass validation on a per-button basis using the formnovalidate attribute on a <button>, <input type="submit">, or <input type="image"> element.

Examples

❌ Invalid: Arbitrary value on novalidate

<form method="post" novalidate="true">
  <label>Email:
    <input type="email" name="email" required>
  </label>
  <button>Submit</button>
</form>

This triggers the error because "true" is not a valid value for a boolean attribute. Other invalid variations include:

<form method="post" novalidate="1">
<form method="post" novalidate="yes">
<form method="post" novalidate="false">

Note that novalidate="false" is especially dangerous — it does not enable validation. Because the attribute is present, the browser disables validation regardless of the value.

✅ Valid: Attribute name alone (recommended)

<form method="post" novalidate>
  <label>Email:
    <input type="email" name="email" required>
  </label>
  <button>Submit</button>
</form>

✅ Valid: Empty string value

<form method="post" novalidate="">
  <label>Email:
    <input type="email" name="email" required>
  </label>
  <button>Submit</button>
</form>

✅ Valid: Value matching the attribute name

<form method="post" novalidate="novalidate">
  <label>Email:
    <input type="email" name="email" required>
  </label>
  <button>Submit</button>
</form>

✅ Valid: Removing the attribute to enable validation

If you want the form to be validated, simply remove the novalidate attribute entirely:

<form method="post">
  <label>Email:
    <input type="email" name="email" required>
  </label>
  <button>Submit</button>
</form>

✅ Using formnovalidate on a specific button

If you want validation on the primary submit but want to skip it for a “Save Draft” button, use formnovalidate on the button instead:

<form method="post">
  <label>Email:
    <input type="email" name="email" required>
  </label>
  <button>Submit</button>
  <button formnovalidate>Save Draft</button>
</form>

This pattern keeps validation active for the main submission while allowing drafts to bypass it — without needing novalidate on the form at all.

Many HTML elements come with built-in (implicit) ARIA roles that browsers and assistive technologies already recognize. The <form> element natively maps to the form ARIA role, meaning screen readers and other tools already understand it as a form landmark without any extra attributes. When you explicitly add role="form" to a <form> element, you’re telling the browser something it already knows.

This redundancy is problematic for several reasons:

• Code clarity: Unnecessary attributes make your HTML harder to read and maintain. Other developers may wonder if the explicit role is there to override something or if it serves a special purpose.
• Misleading intent: Explicit ARIA roles are typically reserved for cases where you need to override or supplement the default semantics of an element. Using them unnecessarily can signal to future maintainers that something unusual is happening when it isn’t.
• ARIA best practices: The first rule of ARIA is “do not use ARIA if you can use a native HTML element or attribute with the semantics and behavior you require.” Adding redundant ARIA roles goes against this principle.

It’s worth noting that the <form> element’s implicit form role only exposes it as a landmark when the form has an accessible name (e.g., via aria-label or aria-labelledby). If you need your form to appear as a landmark region, provide an accessible name rather than adding a redundant role.

To fix this issue, simply remove role="form" from any <form> element. If you want the form to function as a named landmark for assistive technology users, add an accessible name instead.

Examples

❌ Incorrect: redundant role="form"

<form role="form" action="/subscribe" method="post">
  <label for="email">Email:</label>
  <input type="email" id="email" name="email">
  <button type="submit">Subscribe</button>
</form>

This triggers the validator warning because role="form" duplicates the element’s implicit role.

✅ Correct: no explicit role

<form action="/subscribe" method="post">
  <label for="email">Email:</label>
  <input type="email" id="email" name="email">
  <button type="submit">Subscribe</button>
</form>

The <form> element already communicates its role natively. No ARIA attribute is needed.

✅ Correct: form with an accessible name for landmark navigation

<form action="/subscribe" method="post" aria-label="Newsletter subscription">
  <label for="email">Email:</label>
  <input type="email" id="email" name="email">
  <button type="submit">Subscribe</button>
</form>

If you want the form to be discoverable as a named landmark by screen reader users, provide an aria-label or aria-labelledby attribute — not a redundant role.

Other elements with implicit roles

The same principle applies to many other HTML elements. Avoid adding redundant roles like these:

<!-- ❌ Redundant roles -->

<nav role="navigation">...</nav>
<main role="main">...</main>
<header role="banner">...</header>
<footer role="contentinfo">...</footer>
<button role="button">Click me</button>

<!-- ✅ Let native semantics do the work -->

<nav>...</nav>
<main>...</main>
<header>...</header>
<footer>...</footer>
<button>Click me</button>

Trust the native semantics of HTML elements. Only use explicit ARIA roles when you genuinely need to change or supplement an element’s default behavior.