HTML Guides for input

The autocomplete attribute tells the browser whether it can assist the user in filling out a form field, and if so, what type of data is expected. The generic values "on" and "off" control whether the browser should offer autofill suggestions to the user. Since type="hidden" inputs are never displayed and never receive direct user input, these values don’t apply — there’s no user interaction to assist with.

According to the HTML specification, hidden inputs can have an autocomplete attribute, but only with specific named autofill detail tokens (like "transaction-id" or "cc-number"). These tokens serve a programmatic purpose by providing hints about the semantic meaning of the hidden value, which can be useful for form processing. The generic "on" and "off" values, however, are explicitly disallowed because they only relate to the user-facing autofill behavior.

This validation error matters for standards compliance and can indicate a logical mistake in your markup. If you added autocomplete="off" to a hidden input hoping to prevent the browser from caching or modifying the value, it won’t have that effect. Hidden input values are controlled entirely by the server or by JavaScript, not by browser autofill.

How to fix it

1. Remove the autocomplete attribute if it’s not needed — this is the most common fix.
2. Use a specific autofill token if you need to convey semantic meaning about the hidden value (e.g., autocomplete="transaction-id").
3. Reconsider the input type — if the field genuinely needs autofill behavior controlled, it probably shouldn’t be type="hidden".

Examples

Incorrect: using autocomplete="off" on a hidden input

<form action="/submit" method="post">
  <input type="hidden" name="token" value="abc123" autocomplete="off">
  <button type="submit">Submit</button>
</form>

Incorrect: using autocomplete="on" on a hidden input

<form action="/submit" method="post">
  <input type="hidden" name="session-id" value="xyz789" autocomplete="on">
  <button type="submit">Submit</button>
</form>

Correct: removing the autocomplete attribute

<form action="/submit" method="post">
  <input type="hidden" name="token" value="abc123">
  <button type="submit">Submit</button>
</form>

Correct: using a specific autofill token

If the hidden input carries a value with a well-defined autofill semantic, you can use a named token:

<form action="/checkout" method="post">
  <input type="hidden" name="txn" value="TXN-001" autocomplete="transaction-id">
  <button type="submit">Complete Purchase</button>
</form>

This is valid because "transaction-id" is a specific autofill detail token recognized by the specification, unlike the generic "on" or "off" values.

Hidden inputs are designed to carry data between the client and server without any user interaction or visual presence. The browser does not render them, screen readers do not announce them, and they are entirely excluded from the accessibility tree. Because aria-* attributes exist solely to convey information to assistive technologies, adding them to an element that assistive technologies cannot perceive is contradictory and meaningless.

The HTML specification explicitly prohibits aria-* attributes on input elements with type="hidden". This restriction exists because WAI-ARIA attributes — such as aria-label, aria-invalid, aria-describedby, aria-required, and all others in the aria-* family — are meant to enhance the accessible representation of interactive or visible elements. A hidden input has no such representation, so these attributes have nowhere to apply.

This issue commonly arises when:

• JavaScript frameworks or templating engines apply aria-* attributes indiscriminately to all form inputs, regardless of type.
• A developer changes an input’s type from "text" to "hidden" but forgets to remove the accessibility attributes that were relevant for the visible version.
• Form libraries or validation plugins automatically inject attributes like aria-invalid onto every input in a form.

To fix the issue, simply remove all aria-* attributes from any input element that has type="hidden". If the aria-* attribute was meaningful on a previously visible input, no replacement is needed — the hidden input doesn’t participate in the user experience at all.

Examples

Incorrect: hidden input with aria-invalid

<form action="/submit" method="post">
  <input type="hidden" name="referer" value="https://example.com" aria-invalid="false">
  <button type="submit">Submit</button>
</form>

Correct: hidden input without aria-* attributes

<form action="/submit" method="post">
  <input type="hidden" name="referer" value="https://example.com">
  <button type="submit">Submit</button>
</form>

Incorrect: hidden input with multiple aria-* attributes

<form action="/save" method="post">
  <input
    type="hidden"
    name="session_token"
    value="abc123"
    aria-label="Session token"
    aria-required="true"
    aria-describedby="token-help">
  <button type="submit">Save</button>
</form>

Correct: all aria-* attributes removed

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

Correct: aria-* attributes on a visible input (where they belong)

If the input is meant to be visible and accessible, use an appropriate type value instead of "hidden":

<form action="/login" method="post">
  <label for="username">Username</label>
  <input
    type="text"
    id="username"
    name="username"
    aria-required="true"
    aria-invalid="false"
    aria-describedby="username-help">
  <p id="username-help">Enter your registered email or username.</p>
  <button type="submit">Log in</button>
</form>

The label element represents a caption for a form control. There are two ways to associate a label with its control:

1. Implicit association — Place the form control directly inside the label element. No for attribute is needed because the browser automatically pairs the label with the nested control.
2. Explicit association — Use the for attribute on the label, setting its value to the id of the target form control. The control doesn’t need to be nested inside the label in this case.

Both methods are valid on their own. The problem occurs when you combine them incorrectly: you nest an input inside a label that has a for attribute, but the input either has no id or has an id that doesn’t match the for value. This creates a contradiction — the for attribute points to a specific id, yet the nested input doesn’t fulfill that reference. Browsers may handle this inconsistently, and assistive technologies like screen readers could fail to announce the label correctly, harming accessibility.

Why this matters

• Accessibility: Screen readers rely on the for/id pairing to announce labels for form controls. A mismatched or missing id can leave the control unlabeled for users who depend on assistive technology.
• Standards compliance: The HTML specification requires that when a for attribute is present, it must reference the id of a labelable element. A mismatch violates this rule.
• Browser behavior: Some browsers will fall back to the implicit association when for doesn’t resolve, but others may prioritize the broken explicit association, leaving the control effectively unlabeled.

How to fix it

You have two options:

1. Remove the for attribute if the input is already nested inside the label. The implicit association is sufficient on its own.
2. Add or correct the id on the nested input so it matches the for attribute value exactly.

Examples

❌ Nested input with no matching id

The for attribute says "email", but the input has no id at all:

<label for="email">
  Email
  <input type="email" name="email">
</label>

❌ Nested input with a mismatched id

The for attribute says "email", but the input‘s id is "user-email":

<label for="email">
  Email
  <input type="email" name="email" id="user-email">
</label>

✅ Fix by removing the for attribute (implicit association)

Since the input is nested inside the label, the association is automatic:

<label>
  Email
  <input type="email" name="email">
</label>

✅ Fix by adding a matching id (explicit association)

The for value and the id value are identical:

<label for="email">
  Email
  <input type="email" name="email" id="email">
</label>

✅ Fix by using explicit association without nesting

If you prefer to keep the for attribute, the input doesn’t need to be nested at all:

<label for="email">Email</label>
<input type="email" name="email" id="email">

In most cases, choosing either implicit or explicit association — rather than mixing both — is the simplest way to avoid this error. If you do combine them, just make sure the for value and the id value match exactly.

The maxlength attribute provides built-in client-side validation that caps the number of characters a user can type into a field. Browsers enforce this by preventing further input once the limit is reached. However, this behavior only makes sense for input types that accept arbitrary text strings. Input types like number, date, range, and checkbox have their own value formats and constraints — a number input’s value is controlled by min, max, and step, not by character count.

When you place maxlength on an unsupported input type, browsers will ignore the attribute. This means it provides no actual validation while giving a false sense of security. It also produces invalid HTML, which can cause issues with assistive technologies that may try to interpret the attribute and relay incorrect information to users. Keeping your markup valid ensures predictable behavior across browsers and a better experience for all users.

How to fix it

1. Remove maxlength from any <input> whose type is not email, password, search, tel, text, or url.
2. Use the correct constraint attributes for the input type in question. For number inputs, use min and max. For date inputs, use min and max with date strings.
3. If you genuinely need character-length validation, consider whether a text-based input type is more appropriate for your use case, or implement the constraint in JavaScript.

Examples

❌ Invalid: maxlength on a number input

<label for="quantity">Quantity</label>
<input type="number" id="quantity" name="quantity" maxlength="3">

The number type does not support maxlength. Browsers will ignore it, and the HTML is invalid.

✅ Fixed: using min and max for a number input

<label for="quantity">Quantity</label>
<input type="number" id="quantity" name="quantity" min="0" max="999">

If the goal was to limit the value to three digits, min and max are the correct constraints.

❌ Invalid: maxlength on a date input

<label for="start-date">Start date</label>
<input type="date" id="start-date" name="start-date" maxlength="10">

Date inputs have a browser-provided date picker, and their values are always in YYYY-MM-DD format. The maxlength attribute has no effect here.

✅ Fixed: using min and max for a date input

<label for="start-date">Start date</label>
<input type="date" id="start-date" name="start-date" min="2020-01-01" max="2030-12-31">

❌ Invalid: maxlength on a checkbox

<label>
  <input type="checkbox" name="agree" maxlength="1"> I agree
</label>

A checkbox is a boolean toggle — character length is meaningless here.

✅ Fixed: removing the invalid attribute

<label>
  <input type="checkbox" name="agree"> I agree
</label>

✅ Valid: maxlength on supported text-based types

<label for="username">Username</label>
<input type="text" id="username" name="username" maxlength="30">

<label for="user-email">Email</label>
<input type="email" id="user-email" name="email" maxlength="254">

<label for="user-phone">Phone</label>
<input type="tel" id="user-phone" name="phone" maxlength="15">

<label for="site-url">Website</label>
<input type="url" id="site-url" name="website" maxlength="2048">

<label for="user-pass">Password</label>
<input type="password" id="user-pass" name="password" maxlength="128">

<label for="query">Search</label>
<input type="search" id="query" name="q" maxlength="100">

All six of these input types support maxlength because they accept free-form text where limiting character count is meaningful.

The minlength attribute defines the minimum number of characters (as UTF-16 code units) that a user can enter into a text-based input field. It provides built-in client-side validation without requiring JavaScript. However, it only makes sense on input types where the user is typing free-form text. For input types like number, date, color, range, or checkbox, the concept of a minimum character length doesn’t apply — these inputs have their own constrained value formats or use other attributes like min and max for validation.

When the W3C validator encounters minlength on an unsupported input type, it flags the attribute as invalid. Browsers will typically ignore the attribute silently, meaning your intended validation won’t actually work. This can lead to a false sense of security where you believe the input is being validated when it isn’t.

The minlength value must be a non-negative integer (0 or higher) and must be less than or equal to maxlength if both are specified. The minlength attribute also works on <textarea> elements.

Examples

❌ Incorrect: minlength on a number input

The number input type doesn’t support minlength. If you want to enforce a minimum value, use the min attribute instead.

<label for="age">Enter your age</label>
<input type="number" minlength="1" id="age">

✅ Fixed: Using min for number inputs

<label for="age">Enter your age</label>
<input type="number" min="1" id="age">

❌ Incorrect: minlength on a date input

<label for="start-date">Start date</label>
<input type="date" minlength="10" id="start-date">

✅ Fixed: Remove minlength from date inputs

Date inputs have a browser-controlled format, so character length constraints don’t apply. Use min and max to constrain the date range.

<label for="start-date">Start date</label>
<input type="date" min="2024-01-01" id="start-date">

✅ Correct: minlength on supported input types

Here are valid uses of minlength across all supported input types:

<label for="username">Username (at least 3 characters)</label>
<input type="text" minlength="3" id="username">

<label for="email">Email</label>
<input type="email" minlength="5" id="email">

<label for="pass">Password (at least 8 characters)</label>
<input type="password" minlength="8" id="pass">

<label for="phone">Phone number</label>
<input type="tel" minlength="7" id="phone">

<label for="query">Search</label>
<input type="search" minlength="2" id="query">

<label for="website">Website URL</label>
<input type="url" minlength="10" id="website">

✅ Correct: minlength with maxlength on a textarea

<label for="bio">Bio (between 10 and 200 characters)</label>
<textarea minlength="10" maxlength="200" id="bio"></textarea>

Quick Reference

The pattern attribute provides a powerful way to add client-side form validation directly in HTML without relying on JavaScript. It accepts a regular expression that the browser uses to validate user input before the form is submitted. However, the HTML specification restricts pattern to input types where the user enters free-form text. Input types like number, date, range, color, and checkbox have their own built-in validation mechanisms (such as min, max, and step), so applying a regex pattern to them is meaningless and invalid.

When you add pattern to an unsupported input type, browsers will simply ignore it. This means you might think you have validation in place when you actually don’t, which can lead to unexpected invalid data being submitted. Removing the invalid attribute also keeps your markup clean and standards-compliant, which benefits accessibility tools and future browser behavior.

Why certain types don’t support pattern

• number — Values are constrained by min, max, and step. The browser enforces numeric input natively.
• date, time, datetime-local, month, week — These use date/time pickers with their own format and range constraints.
• range — A slider control already constrained by min, max, and step.
• checkbox, radio — These are toggled on/off or selected from a group; a regex pattern doesn’t apply.
• file — File selection is handled by the OS file picker; use the accept attribute instead.
• color — Uses a color picker with a fixed hex format.
• hidden — Not user-editable, so client-side validation is irrelevant.

How to fix it

1. Remove the pattern attribute if the input type already provides sufficient validation through its native controls.
2. Change the input type to one of the six supported types (email, password, search, tel, text, or url) if you genuinely need regex-based validation.
3. Use alternative attributes like min, max, step, or accept that are designed for the specific input type.
4. Use JavaScript validation if you need custom validation logic that goes beyond what native attributes offer.

Examples

❌ Incorrect: pattern on a number input

<label for="qty">Quantity (multiples of 5):</label>
<input type="number" id="qty" name="qty" pattern="[0-9]+" min="0" max="100">

The pattern attribute is not allowed on type="number". Since min, max, and step already handle numeric constraints, pattern is unnecessary here.

✅ Correct: using step instead of pattern for number validation

<label for="qty">Quantity (multiples of 5):</label>
<input type="number" id="qty" name="qty" min="0" max="100" step="5">

❌ Incorrect: pattern on a date input

<label for="dob">Date of birth:</label>
<input type="date" id="dob" name="dob" pattern="\d{4}-\d{2}-\d{2}">

The date input type already enforces a date format through its native picker, so pattern is invalid here.

✅ Correct: removing pattern from date input

<label for="dob">Date of birth:</label>
<input type="date" id="dob" name="dob" min="1900-01-01" max="2025-12-31">

❌ Incorrect: pattern on a checkbox input

<label>
  <input type="checkbox" name="agree" pattern=".+"> I agree to the terms
</label>

✅ Correct: using required instead of pattern for checkbox

<label>
  <input type="checkbox" name="agree" required> I agree to the terms
</label>

✅ Correct: pattern on a supported text input

<label for="zip">ZIP code:</label>
<input type="text" id="zip" name="zip" pattern="[0-9]{5}" title="Five digit ZIP code" required>

When using pattern on a supported input type, always include a title attribute that describes the expected format. Browsers display the title text as part of the validation error message, helping users understand what input is expected.

The step attribute specifies the granularity that an input’s value must adhere to. It controls the increment when a user clicks the up/down spinner buttons on a number input, moves a slider on a range input, or adjusts date and time inputs. The browser also uses this value during constraint validation to determine which values are considered valid based on the stepping base (typically the min value or the input’s default).

When the HTML specification defines the step attribute, it requires the value to be a valid floating-point number greater than zero. A value of "0" is explicitly invalid because a step of zero means no increment at all — it’s logically meaningless. You can’t step through values in increments of nothing. The W3C validator flags this as an error because "0" fails the requirement of being a positive number.

Why this matters

• Standards compliance: The WHATWG HTML living standard explicitly requires step to parse as a number greater than zero. A value of "0" violates this rule.
• Browser behavior: While browsers may not crash on step="0", the behavior becomes unpredictable. Spinner buttons may stop working, and form validation may not function as expected.
• Accessibility: Assistive technologies rely on correct step values to communicate valid input ranges to users. An invalid step can lead to a confusing experience.

How to fix it

Choose the appropriate fix depending on your intent:

1. If you want specific increments (e.g., whole numbers, cents, tenths), set step to the desired interval like "1", "0.01", or "0.1".
2. If you want to allow any value with no stepping constraint, use the special keyword step="any". This tells the browser that no stepping is implied and any floating-point value is acceptable.
3. If you don’t need the attribute at all, simply remove it. Each input type has a default step value (e.g., 1 for type="number").

Examples

❌ Invalid: step set to zero

<label for="price">Price:</label>
<input id="price" name="price" type="number" step="0" min="0">

This triggers the validation error because "0" is not a valid positive floating-point number.

✅ Fixed: using a specific step value

If you want the input to accept values in increments of one cent:

<label for="price">Price:</label>
<input id="price" name="price" type="number" step="0.01" min="0">

Valid values would include 0, 0.01, 0.02, 1.50, 99.99, and so on.

✅ Fixed: using step="any" for unrestricted precision

If you want to allow any numeric value without stepping constraints:

<label for="price">Price:</label>
<input id="price" name="price" type="number" step="any" min="0">

This permits any floating-point value, such as 3.14159 or 0.007.

✅ Fixed: using a whole number step with a non-zero minimum

<label for="quantity">Quantity:</label>
<input id="quantity" name="quantity" type="number" step="2" min="1.3">

With step="2" and min="1.3", valid values include 1.3, 3.3, 5.3, 7.3, and so on. The stepping base is 1.3, and each valid value is an even multiple of 2 away from it.

✅ Fixed: removing the attribute entirely

If the default step behavior is sufficient, simply omit the attribute:

<label for="amount">Amount:</label>
<input id="amount" name="amount" type="number" min="0">

The default step for type="number" is 1, so valid values are whole numbers (0, 1, 2, etc.).

The role attribute value combobox is not valid on an input element according to the W3C HTML standard.

The role="combobox" is valid only when applied to an element that acts as a container for the combo box widget, usually a div or similar element, and not directly to a native HTML input. Native input elements of type "text" or "search" already have implicit roles and accessibility semantics. To create an accessible combobox, wrap the input inside a container element with role="combobox" and use appropriate ARIA attributes.

Incorrect Implementation:

<input type="text" role="combobox" aria-autocomplete="list">

Correct Implementation:

<div role="combobox" aria-haspopup="listbox" aria-owns="suggestions" aria-expanded="false">
  <input type="text" aria-autocomplete="list" aria-controls="suggestions">
</div>
<ul id="suggestions" role="listbox">
  <li role="option" id="option1">Option 1</li>
  <li role="option" id="option2">Option 2</li>
</ul>

Explanation of attributes:

• role="combobox": Applied to the container (<div>) to define the accessible widget.
• aria-haspopup="listbox": Indicates the presence of a list of suggestions.
• aria-owns / aria-controls: Connects the input and suggestion list.
• aria-expanded: Denotes whether the suggestion list is visible.
• aria-autocomplete: Defines the autocomplete behavior.

This markup ensures better accessibility and passes W3C validation.

type="datetime" is obsolete; it was removed from HTML and is not valid in modern browsers or validators.

Explanation

The input element’s type attribute accepts specific keywords defined by the HTML Living Standard. The keyword datetime was dropped; use either:

• type="datetime-local" for a local date and time without timezone.
• type="date" or type="time" when collecting them separately.
• type="text" with a pattern or a JS widget when timezone-aware datetime is required.

Relevant attributes that still apply include name, value, min, max, and step (e.g., seconds for datetime-local).

HTML examples

Example reproducing the error

<!DOCTYPE html>
<html lang="en">
<head>
  <title>Invalid input type</title>
</head>
<body>
  <form>
    <label>
      Meeting:
      <input type="datetime" name="meeting">
    </label>
  </form>
</body>
</html>

Valid fix with datetime-local

<!DOCTYPE html>
<html lang="en">
<head>
  <title>Valid input type</title>
</head>
<body>
  <form>
    <label>
      Meeting:
      <input type="datetime-local" name="meeting" step="60">
    </label>
  </form>
</body>
</html>

The HTML <input> element’s type attribute only accepts a specific set of predefined values defined in the HTML specification. These include values like text, password, email, number, date, datetime-local, checkbox, radio, and others. The value dob — presumably short for “date of birth” — is not among them.

When a browser encounters an invalid type value, it doesn’t throw an error or prevent the page from loading. Instead, it treats the input as type="text". This means the input might appear to work, but you lose important benefits: there’s no native date picker UI, no built-in date format validation, and no appropriate mobile keyboard. The W3C validator flags this to help you catch the mistake early.

This matters for several reasons:

• Accessibility: Valid input types provide semantic meaning to assistive technologies. A type="date" input tells screen readers that a date is expected, enabling better guidance for users.
• User experience: Native date inputs offer platform-appropriate date pickers on mobile and desktop, reducing input errors.
• Standards compliance: Using invalid attribute values produces unpredictable behavior across browsers and can break future compatibility.

To fix this issue, replace type="dob" with a recognized type. For a date of birth field, type="date" is the most appropriate choice. If you need more control over formatting, you can use type="text" with a JavaScript date picker library or custom validation.

Examples

❌ Invalid: using type="dob"

<label for="dob">Date of Birth:</label>
<input type="dob" id="dob" name="dob">

The browser will treat this as a plain text input, and the W3C validator will report: Bad value “dob” for attribute “type” on element “input”.

✅ Fixed: using type="date"

<label for="dob">Date of Birth:</label>
<input type="date" id="dob" name="dob">

This uses the native HTML date input, which provides a built-in date picker in most modern browsers. You can also constrain the date range with min and max attributes:

<label for="dob">Date of Birth:</label>
<input type="date" id="dob" name="dob" min="1900-01-01" max="2025-12-31">

✅ Fixed: using type="text" with a JavaScript date picker

If you need more control over the date picker’s appearance or need to support older browsers that lack native date input support, use type="text" and enhance it with JavaScript:

<label for="dob">Date of Birth:</label>
<input type="text" id="dob" name="dob" placeholder="YYYY-MM-DD">

You can then attach a JavaScript date picker library (such as Flatpickr, Pikaday, or a framework-specific component) to this input for a custom date selection experience. When using this approach, make sure to add appropriate aria-* attributes and validation to maintain accessibility.

Valid type values for reference

Here are some commonly used valid type values for the <input> element:

• text — plain text input
• date — date picker (year, month, day)
• datetime-local — date and time picker (no timezone)
• month — month and year picker
• number — numeric input
• email — email address input
• tel — telephone number input
• password — masked text input

Always choose the type that best matches the data you’re collecting. For a date of birth, type="date" is the most semantically correct and user-friendly option.

An empty string is not a valid value for the autocomplete attribute on an input element.

The autocomplete attribute controls whether the browser can autofill input values, and it requires a valid, non-empty value according to the HTML specification. Acceptable values are on, off, or specific autocomplete tokens such as name, email, username, etc. Leaving it empty, like autocomplete="", causes validation errors.

Incorrect example:

<input type="text" name="username" autocomplete="">

Correct examples: Enable browser autocomplete:

<input type="text" name="username" autocomplete="on">

Disable browser autocomplete:

<input type="text" name="username" autocomplete="off">

Use a specific token (recommended for forms that collect particular data):

<input type="email" name="useremail" autocomplete="email">

The max attribute defines the maximum value that is acceptable and valid for the input containing it. When the browser encounters max="", it expects a valid floating-point number as defined by the HTML specification. An empty string cannot be parsed as a number, so the attribute becomes meaningless and triggers a validation error.

This commonly happens when HTML is generated dynamically by a template engine or framework that outputs an empty value for max when no maximum has been configured. It can also occur when a developer adds the attribute as a placeholder intending to fill it in later.

While most browsers will silently ignore an invalid max value, relying on this behavior is problematic for several reasons:

• Standards compliance: The HTML specification requires max to be a valid floating-point number when present.
• Predictable validation: An empty max means no client-side maximum constraint is enforced, which may not be the developer’s intent. Explicitly removing the attribute makes that intention clear.
• Accessibility: Assistive technologies may read the max attribute to communicate input constraints to users. An empty value could lead to confusing or undefined behavior.

This error applies to input types that accept numeric-style max values, including number, range, date, datetime-local, month, week, and time.

How to Fix It

1. Set a valid numeric value: If you need a maximum constraint, provide a proper floating-point number (e.g., max="100" or max="99.5").
2. Remove the attribute: If no maximum is needed, remove the max attribute entirely rather than leaving it empty.
3. Fix dynamic templates: If your HTML is generated from a template, add a conditional check so that max is only rendered when a value is actually available.

Examples

❌ Invalid: Empty max attribute

<label for="quantity">Quantity:</label>
<input type="number" id="quantity" name="quantity" max="">

The empty string "" is not a valid floating-point number, so this triggers the validation error.

✅ Fixed: Providing a valid numeric value

<label for="quantity">Quantity:</label>
<input type="number" id="quantity" name="quantity" max="100">

✅ Fixed: Removing the attribute entirely

<label for="quantity">Quantity:</label>
<input type="number" id="quantity" name="quantity">

If no maximum constraint is needed, simply omit the max attribute.

❌ Invalid: Empty max on a date input

<label for="end-date">End date:</label>
<input type="date" id="end-date" name="end-date" max="">

✅ Fixed: Valid date value for max

<label for="end-date">End date:</label>
<input type="date" id="end-date" name="end-date" max="2025-12-31">

For date-related input types, the max value must be in the appropriate date/time format (e.g., YYYY-MM-DD for type="date").

Fixing dynamic templates

If you’re generating HTML with a templating language, conditionally include the attribute only when a value exists. For example, in a Jinja2-style template:

<input type="number" id="price" name="price"
  {% if max_price %}max="{{ max_price }}"{% endif %}>

This ensures the max attribute is only rendered when max_price has a valid value, avoiding the empty-string problem entirely.

Remove the empty maxlength value and provide a non-negative integer or omit the attribute entirely.

Explanation

The maxlength attribute on an input element must be a valid non-negative integer per the HTML specification. An empty string ("") is invalid and triggers the validator error.

• Valid: a decimal integer like 0, 10, 255.
• Invalid: empty string, negative numbers, non-numeric strings, or whitespace.
  If no maximum length is needed, omit maxlength instead of leaving it empty.
  Note that maxlength applies to text-entry controls such as type="text", search, url, tel, email, and password. For other types (e.g., number, date), maxlength is ignored and should not be used.

Examples

Correct: set an explicit maximum

<input type="text" name="username" maxlength="20">

Correct: no maximum, omit the attribute

<input type="text" name="comment">

Incorrect: empty string (validator error)

<input type="text" name="username" maxlength="">

An empty string for the min attribute on an input element is invalid; it must be a valid number.

The min attribute specifies the minimum value an <input> element can accept when using types such as number, range, date, or datetime-local. According to the HTML specification, the value for min must be a valid floating point number (or a valid date/time string for date inputs). Setting min="" (an empty string) is invalid and will trigger validator errors.

HTML examples

Invalid usage:

<input type="number" min="" max="10">

Valid usage (set min to a specific number, or omit it if no minimum is required):

<input type="number" min="0" max="10">

or, if no minimum restriction is needed:

<input type="number" max="10">

Always provide a valid number for min or remove the attribute entirely if a minimum is not needed.

The name attribute on an <input> element identifies the form control’s data when the form is submitted. It acts as the key in the key-value pair sent to the server (e.g., email=user@example.com). When you set name="", the attribute is present but contains an empty string, which the HTML specification considers an invalid value. An empty name means the input’s data will be excluded from the form’s submission payload in most browsers, making it functionally useless for form processing.

This issue matters for several reasons:

• Form functionality: Inputs with empty names are typically omitted from form data, so the server never receives the user’s input.
• Standards compliance: The HTML specification requires that if the name attribute is present, its value must not be empty.
• JavaScript references: An empty name makes it difficult to reference the element using methods like document.getElementsByName() or FormData.
• Accessibility: Screen readers and assistive technologies may use the name attribute to help identify form controls, and an empty value provides no useful information.

Note that the name attribute is not technically required on every <input> element — it’s perfectly valid to omit it entirely. For example, inputs used purely for client-side JavaScript interactions without form submission don’t need a name. The error specifically arises when the attribute is present but set to an empty string.

To fix the issue, either assign a meaningful name that describes the data the input collects, or remove the name attribute altogether if the input isn’t part of a form submission.

Examples

❌ Empty name attribute triggers the error

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

✅ Providing a meaningful name value

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

✅ Removing name when the input isn’t submitted

If the input is only used for client-side interaction and doesn’t need to be part of form data, simply omit the attribute:

<label for="search">Filter results:</label>
<input type="text" id="search">

❌ Multiple inputs with empty names

This pattern sometimes appears when inputs are generated dynamically with placeholder attributes:

<form action="/register" method="post">
  <input type="text" name="">
  <input type="password" name="">
  <button type="submit">Register</button>
</form>

✅ Each input gets a descriptive name

<form action="/register" method="post">
  <label for="username">Username:</label>
  <input type="text" id="username" name="username">
  <label for="password">Password:</label>
  <input type="password" id="password" name="password">
  <button type="submit">Register</button>
</form>

The HTML <input> element accepts a specific set of values for its type attribute, as defined by the HTML specification. The value "numeric" is not one of them. When a browser encounters an unrecognized type value, it falls back to type="text", meaning the user gets a plain text field instead of a dedicated numeric input. This fallback behavior means you lose built-in features like increment/decrement spinner controls, numeric keyboard on mobile devices, and native client-side validation that rejects non-numeric entries.

This confusion often arises because of the inputmode="numeric" attribute, which is valid and controls which virtual keyboard appears on mobile devices. The inputmode attribute and the type attribute serve different purposes, and mixing them up leads to this validation error.

Using the correct type="number" value matters for several reasons:

• Accessibility: Screen readers and assistive technologies use the type attribute to announce the expected input format to users.
• User experience: Browsers display appropriate controls (spinners, numeric keypads) for type="number" inputs.
• Validation: Native form validation automatically checks that the entered value is a valid number, within optional min/max bounds and matching an optional step value.
• Standards compliance: Invalid type values cause W3C validation errors and signal potential bugs in your markup.

Examples

Incorrect: using type="numeric"

This triggers the validation error because "numeric" is not a valid type value:

<label for="quantity">Quantity:</label>
<input type="numeric" id="quantity" name="quantity">

The browser will treat this as type="text", so users can type any characters, no spinner controls appear, and no numeric validation occurs.

Correct: using type="number"

Replace "numeric" with "number":

<label for="quantity">Quantity:</label>
<input type="number" id="quantity" name="quantity" min="1" max="10">

This gives you a proper numeric input with optional min, max, and step attributes for constraining the allowed range and increments.

Alternative: using inputmode="numeric" with type="text"

If you need a numeric keyboard on mobile but want more control over the input (for example, accepting values like zip codes or credit card numbers that aren’t truly “numbers”), you can use inputmode="numeric" on a text input instead:

<label for="zip">ZIP Code:</label>
<input type="text" inputmode="numeric" pattern="[0-9]{5}" id="zip" name="zip">

Here, type="text" is valid, inputmode="numeric" triggers the numeric keyboard on mobile devices, and the pattern attribute provides validation. This approach is useful when type="number" isn’t appropriate — for instance, type="number" strips leading zeros and allows scientific notation like 1e5, which is undesirable for codes and identifiers.

Summary of the fix

In most cases, simply changing type="numeric" to type="number" is the correct fix. Choose the inputmode approach only when you specifically need a text field with a numeric keyboard.

The search ARIA role is a landmark role, which means it identifies a large, navigable section of a page — specifically, the region that contains the search functionality. Landmark roles help assistive technologies (like screen readers) quickly identify and jump to major sections of a document. Because landmarks describe sections of a page, they belong on container elements that encompass all the parts of the search interface (the label, the input field, the submit button, etc.), not on a single <input> element.

When you place role="search" on an <input>, the validator rejects it because the search role doesn’t match the semantics of an input control. An <input> represents a single interactive widget, not a page region. The valid way to indicate that an input field is for search queries is to use <input type="search">, which gives browsers and assistive technologies the correct semantic meaning for that specific control.

Meanwhile, if you want to mark an entire search form as a search landmark, apply role="search" to the <form> element that wraps the search controls. In modern HTML, you can also use the <search> element, which has the implicit search landmark role without needing any ARIA attribute.

How to fix it

1. Remove role="search" from the <input> element.
2. Change the input’s type to "search" — this tells browsers and assistive technologies that the field is for search queries.
3. Apply role="search" to the wrapping <form>, or use the HTML <search> element as the container.

Examples

❌ Incorrect: role="search" on an <input>

<form>
  <label for="query">Search</label>
  <input role="search" id="query" name="q">
  <button type="submit">Go</button>
</form>

This triggers the validation error because search is not a valid role for <input>.

✅ Correct: type="search" on the input, role="search" on the form

<form role="search">
  <label for="query">Search this site</label>
  <input type="search" id="query" name="q">
  <button type="submit">Go</button>
</form>

Here, role="search" is correctly placed on the <form> element, creating a search landmark. The <input type="search"> conveys the correct semantics for the input field itself.

✅ Correct: Using the <search> element (modern HTML)

<search>
  <form>
    <label for="query">Search this site</label>
    <input type="search" id="query" name="q">
    <button type="submit">Go</button>
  </form>
</search>

The <search> element has the implicit ARIA role of search, so no explicit role attribute is needed on either the container or the form. This is the most semantic approach in browsers that support it.

✅ Correct: Standalone search input without a landmark

If you simply need a search-styled input without marking up a full landmark region, just use type="search":

<label for="filter">Filter results</label>
<input type="search" id="filter" name="filter">

This gives the input the correct semantics and allows browsers to provide search-specific UI features (such as a clear button) without requiring a landmark role.

The HTML specification defines specific rules about which autocomplete values can be used on which form elements. The street-address token is categorized as a “multiline” autofill field because street addresses often span multiple lines (e.g., “123 Main St\nApt 4B”). Since <input> elements only accept single-line text, the spec prohibits using street-address with them. The <textarea> element, on the other hand, naturally supports multiline content, making it the appropriate host for this token.

This matters for several reasons. First, browsers use autocomplete values to offer autofill suggestions. When the element type doesn’t match the expected data format, browsers may not autofill correctly or may ignore the hint entirely. Second, standards compliance ensures consistent behavior across different browsers and assistive technologies. Third, using the correct pairing improves the user experience — users expect their full street address to appear in a field that can actually display it properly.

You have two approaches to fix this:

1. Use a <textarea> — If you want the full street address in a single field, switch from <input> to <textarea>. This is the most semantically correct choice when you expect multiline address data.

2. Use line-specific tokens on <input> elements — If your form design uses separate single-line fields for each part of the address, use address-line1, address-line2, and address-line3 instead. These tokens are explicitly allowed on <input> elements.

Examples

❌ Invalid: street-address on an <input>

<label for="address">Street Address</label>
<input type="text" id="address" name="address" autocomplete="street-address">

This triggers the validation error because street-address requires a multiline control.

✅ Fix: Use a <textarea> with street-address

<label for="address">Street Address</label>
<textarea id="address" name="address" autocomplete="street-address"></textarea>

The <textarea> supports multiline text, so street-address is valid here.

✅ Fix: Use line-specific tokens on <input> elements

<label for="address1">Address Line 1</label>
<input type="text" id="address1" name="address1" autocomplete="address-line1">

<label for="address2">Address Line 2</label>
<input type="text" id="address2" name="address2" autocomplete="address-line2">

The address-line1, address-line2, and address-line3 tokens are single-line autofill fields and are perfectly valid on <input> elements. This approach is common in forms that break the address into separate fields for apartment numbers, building names, or other details.

Summary of allowed pairings

Choose the approach that best fits your form layout. If you prefer a single address field, use <textarea> with street-address. If you prefer structured, separate fields, use <input> elements with the appropriate address-line tokens.

The HTML specification defines specific rules about which autocomplete autofill field names can be paired with which input types. The tel-national token (which represents a phone number without the country code) is classified as requiring a text-based input control. Meanwhile, <input type="tel"> is a specialized control that the spec treats differently from a plain text field. When the validator encounters tel-national on a type="tel" input, it flags the mismatch because the autofill field name is not allowed in that context.

This might seem counterintuitive — a national telephone number value on a telephone input feels like a natural fit. However, the distinction exists because type="tel" already implies a complete telephone number, and the spec maps the broader tel autocomplete token to it. The more granular telephone tokens like tel-national, tel-country-code, tel-area-code, tel-local, tel-local-prefix, and tel-local-suffix are designed for type="text" inputs where a phone number is being broken into individual parts across multiple fields.

Getting this right matters for browser autofill behavior. When the autocomplete value and input type are properly paired according to the spec, browsers can more reliably populate the field with the correct portion of the user’s stored phone number. An invalid pairing may cause autofill to silently fail or behave unpredictably across different browsers.

How to fix it

You have two options:

1. Change the input type to text — Use type="text" if you specifically want the national portion of a phone number (without the country code). This is the right choice when you’re splitting a phone number across multiple fields.
2. Change the autocomplete value to tel — Use autocomplete="tel" if you want a single field for the full phone number. This pairs correctly with type="tel".

Examples

❌ Invalid: tel-national on type="tel"

<label for="phone">Phone number</label>
<input id="phone" name="phone" type="tel" autocomplete="tel-national">

This triggers the validation error because tel-national is not allowed on a type="tel" input.

✅ Fix option 1: Change input type to text

<label for="phone">Phone number (without country code)</label>
<input id="phone" name="phone" type="text" autocomplete="tel-national">

Using type="text" satisfies the spec’s requirement for the tel-national autofill token. This is ideal when collecting just the national portion of a number.

✅ Fix option 2: Change autocomplete to tel

<label for="phone">Phone number</label>
<input id="phone" name="phone" type="tel" autocomplete="tel">

Using autocomplete="tel" is the correct pairing for type="tel" and tells the browser to autofill the complete phone number.

✅ Splitting a phone number across multiple fields

When you need separate fields for different parts of a phone number, use type="text" with the granular autocomplete tokens:

<fieldset>
  <legend>Phone number</legend>
  <label for="country-code">Country code</label>
  <input id="country-code" name="country-code" type="text" autocomplete="tel-country-code">
  <label for="national">National number</label>
  <input id="national" name="national" type="text" autocomplete="tel-national">
</fieldset>

Use the boolean attribute disabled without any value or with the attribute name as the value; "true" is invalid.

Detailed explanation

The HTML boolean attribute disabled indicates that the element is not editable, focusable, or submittable. For boolean attributes (per the WHATWG HTML standard and MDN), the presence of the attribute means “on/true,” and its absence means “off/false.” Valid syntaxes are:

• disabled
• disabled=""
• disabled="disabled"

Invalid values include arbitrary strings like "true" or "false". Using disabled="true" triggers the validator error because boolean attributes must not use non-empty values other than the attribute name itself.

Relevant elements that support disabled include input, button, select, textarea, optgroup, option, fieldset, and form (partial behavior). For dynamic enabling/disabling, set or remove the attribute via JavaScript rather than assigning string values.

HTML examples

Reproduce the validator error (invalid)

<!DOCTYPE html>
<html lang="en">
<head>
  <title>Invalid Disabled Example</title>
</head>
<body>
  <form>
    <input type="text" disabled="true">
    <button type="submit" disabled="false">Submit</button>
  </form>
</body>
</html>

Fix (valid boolean attribute usage)

<!DOCTYPE html>
<html lang="en">
<head>
  <title>Valid Disabled Example</title>
</head>
<body>
  <form>
<!-- Presence means disabled -->

    <input type="text" disabled>
<!-- Also valid: disabled="disabled" or disabled="" -->

    <button type="submit" disabled="disabled">Submit</button>
  </form>
</body>
</html>

When you write an attribute like maxlength="200 and accidentally omit the closing quote, everything that follows — including subsequent attribute names and their values — gets absorbed into that one attribute’s value. In this case, the validator sees the value of maxlength as 200 aria-required= (or similar), which is not a valid integer. The parser doesn’t encounter a closing " until it finds the next quotation mark further along in the tag, causing a cascade of errors.

This is a problem for several reasons:

• Broken functionality: The maxlength attribute won’t work because 200 aria-required= is not a valid number. The browser cannot determine the intended character limit.
• Lost attributes: The aria-required attribute is swallowed into the malformed maxlength value, so it never gets applied as a separate attribute. Assistive technologies like screen readers won’t know the field is required.
• Accessibility impact: Since aria-required="true" is lost, users who rely on screen readers won’t receive the information that the field is mandatory, potentially leading to form submission errors and a frustrating experience.

The root cause is almost always a missing closing quotation mark. Carefully check that every attribute value has both an opening and a closing ". This kind of typo is easy to make and easy to miss, especially in long tags with many attributes.

Examples

Incorrect — missing closing quote on maxlength

The closing " after 200 is missing, so the value of maxlength extends all the way to the next quotation mark it finds:

<input type="text" name="nome" id="nome" maxlength="200 aria-required="true">

The validator interprets maxlength as having the value 200 aria-required=, and only true ends up as the value of an unintended or malformed attribute. Nothing works as expected.

Correct — properly quoted attributes

Each attribute has its own properly matched pair of quotation marks:

<input type="text" name="nome" id="nome" maxlength="200" aria-required="true">

Here, maxlength="200" correctly limits the input to 200 characters, and aria-required="true" is a separate attribute that tells assistive technologies the field is required.

Incorrect — missing closing quote with more attributes

This issue can happen with any combination of attributes. Here, a missing quote after maxlength absorbs class and placeholder:

<input type="text" maxlength="50 class="username" placeholder="Enter name">

Correct — all quotes properly closed

<input type="text" maxlength="50" class="username" placeholder="Enter name">

Tips for avoiding this issue

• Use a code editor with syntax highlighting. Most editors color attribute values differently from attribute names. If you see an attribute name rendered in the same color as a value string, a quote is likely missing.
• Format attributes one per line on complex elements. This makes it much easier to spot mismatched quotes:

<input
  type="text"
  name="nome"
  id="nome"
  maxlength="200"
  aria-required="true">

• Validate early and often. Running your HTML through the W3C validator regularly helps catch these small typos before they cause confusing bugs in production.

The accept attribute provides browsers with a hint about which file types the user should be able to select through the file picker dialog. While browsers may still allow users to select other file types, the attribute helps filter the file picker to show relevant files first, improving the user experience.

The W3C validator reports this error when it encounters tokens in the accept attribute that don’t conform to the expected format. The attribute value is parsed as a set of comma-separated tokens, and each token must be one of the following:

• A valid MIME type such as application/pdf, text/plain, or image/png (the / character separating type and subtype is required).
• A file extension starting with a period, such as .pdf, .docx, or .jpg.
• One of three wildcard MIME types: audio/*, video/*, or image/*.

Common mistakes that trigger this error include using bare file extensions without the leading dot (e.g., pdf instead of .pdf), using arbitrary words that aren’t valid MIME types, or including spaces in a way that creates malformed tokens. The HTML specification (WHATWG) defines strict rules for how these tokens are parsed, and violating them produces a validation error.

Getting this attribute right matters for several reasons. First, a correctly specified accept attribute helps users by pre-filtering the file picker, so they don’t have to hunt through unrelated files. Second, assistive technologies may use this attribute to communicate accepted file types to users. Third, some browsers may silently ignore a malformed accept value entirely, removing the helpful filtering behavior you intended.

To fix the issue, review each token in your accept attribute and ensure it matches one of the three valid formats listed above. If you’re unsure of the correct MIME type for a file format, consult the IANA Media Types registry. When in doubt, dot-prefixed file extensions (like .pdf or .docx) are often simpler and more readable.

Examples

Incorrect: bare words without dots or MIME type format

<input type="file" name="document" accept="doc, docx, pdf">

The tokens doc, docx, and pdf are neither valid MIME types (no /) nor valid file extensions (no leading .), so the validator rejects them.

Incorrect: spaces creating malformed tokens

<input type="file" name="photo" accept="image/png, image/jpeg">

While most browsers handle spaces after commas gracefully, the validator may flag this depending on parsing. It’s safest to avoid spaces or keep them minimal.

Correct: using dot-prefixed file extensions

<input type="file" name="document" accept=".doc,.docx,.pdf">

Correct: using valid MIME types

<input type="file" name="document" accept="application/msword,application/vnd.openxmlformats-officedocument.wordprocessingml.document,application/pdf">

Correct: mixing MIME types, extensions, and wildcards

<input type="file" name="media" accept="image/*,.pdf,video/mp4">

This accepts all image types, PDF files, and MP4 videos. Mixing formats is perfectly valid as long as each token individually conforms to the specification.

Correct: using wildcard MIME types for broad categories

<input type="file" name="photo" accept="image/*">

This allows the user to select any image file, regardless of specific format.

checked is a boolean attribute and should not have a value; it must be written as just checked.

The checked attribute is used with <input> elements of type checkbox or radio. As a boolean attribute, it is either present (interpreted as true) or omitted (false). Adding any value, like checked="true", is not valid and causes a validation error. The correct usage is simply checked.

Incorrect example:

<input type="checkbox" checked="true">

Correct example:

<input type="checkbox" checked>

Example in context:

<!DOCTYPE html>
<html lang="en">
<head>
  <title>Checkbox Example</title>
</head>
<body>
  <label>
    <input type="checkbox" checked>
    Subscribe to newsletter
  </label>
</body>
</html>

The disabled attribute is a boolean attribute and must not have a value or should simply be present (disabled or disabled=""). Boolean attributes like disabled indicate presence by their occurrence alone and should not include explicit values.

Incorrect usage:

<input type="text" disabled="yes">
<input type="text" disabled="true">
<input type="text" disabled="false">

Correct usage:

<input type="text" disabled>
<input type="text" disabled="">

Only the presence of the disabled attribute disables the input. The value, if given, is ignored by the browser but causes validation problems if specified incorrectly. For W3C compliance, simply include the disabled attribute without specifying a value.

Although using <input type="text" disabled="disabled"> might still be marked as valid by the W3C Validator, the general recommendation for boolean attributes is to not pass any value.

Invalid value used for the multiple attribute on an input element.

The multiple attribute is a boolean attribute for certain input types (e.g., email, file). Boolean attributes must appear without a value (or with the same name as value in legacy cases), and they only work on specific types. Valid usage: <input type="email" multiple> or <input type="file" multiple>. Invalid usage includes multiple="1", multiple="true", or using multiple on unsupported types like text or number. The email type allows comma-separated addresses when multiple is present; the file type allows selecting more than one file.

HTML Examples

Example that reproduces the error

<!DOCTYPE html>
<html lang="en">
<head>
  <title>Invalid multiple</title>
</head>
<body>
<!-- Invalid: value on boolean attribute, and wrong type -->

  <input type="text" name="tags" multiple="1">
</body>
</html>

Corrected example

<!DOCTYPE html>
<html lang="en">
<head>
  <title>Valid multiple</title>
</head>
<body>
<!-- Valid: boolean attribute without a value on supported types -->

  <input type="email" name="recipients" multiple placeholder="name@example.com, other@example.com">

  <input type="file" name="attachments" multiple>
</body>
</html>