HTML Guides for tel

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 required attribute is a boolean attribute that tells the browser a field must be filled in before the form can be submitted. However, not every input type supports this concept. Some input types always have a value (like range, which defaults to a midpoint, or color, which defaults to #000000), while others represent actions rather than user data (like submit, reset, image, and button). For hidden inputs, the user has no way to interact with the field at all, so requiring them to provide a value makes no sense.

The HTML specification explicitly limits required to the following input types: checkbox, date, datetime-local, email, file, month, number, password, radio, search, tel, text, time, url, and week.

Using required on an unsupported type is invalid HTML. Browsers will typically ignore the attribute in this situation, which means you might believe a field is required when it actually isn’t being validated at all. This can lead to forms being submitted with missing or unexpected data. It also creates confusion for assistive technologies — screen readers may announce a field as required even though the browser won’t enforce it, misleading users.

How to fix it

1. Check the input type. If you’re using required on an input with a type like hidden, range, color, submit, reset, image, or button, the attribute is not allowed.
2. Remove the required attribute if the input type inherently provides a value or doesn’t accept user-provided data.
3. Change the input type if you actually need the field to be required and the current type doesn’t match your intent.
4. Use server-side validation for inputs like hidden that can’t use required but still need a value.

Examples

❌ Invalid: required on a hidden input

<form>
  <input type="hidden" name="token" required>
  <button type="submit">Submit</button>
</form>

The user cannot interact with a hidden input, so required is not allowed here. The browser won’t enforce it.

❌ Invalid: required on a range input

<form>
  <label for="volume">Volume:</label>
  <input type="range" id="volume" name="volume" min="0" max="100" required>
  <button type="submit">Submit</button>
</form>

A range input always has a value (it defaults to the midpoint), so required is meaningless and not permitted.

❌ Invalid: required on a color input

<form>
  <label for="color">Pick a color:</label>
  <input type="color" id="color" name="color" required>
  <button type="submit">Submit</button>
</form>

A color input always has a value (defaulting to #000000), so required is not valid here.

✅ Valid: required removed from unsupported types

<form>
  <input type="hidden" name="token" value="abc123">
  <label for="volume">Volume:</label>
  <input type="range" id="volume" name="volume" min="0" max="100">
  <button type="submit">Submit</button>
</form>

✅ Valid: required on supported input types

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

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

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

  <button type="submit">Submit</button>
</form>

These input types — email, date, and checkbox — all accept direct user input and are on the allowed list for the required attribute.

Spaces are not permitted in the href value for phone links; the phone number must be a continuous string without spaces or slashes.

The href attribute of an anchor (<a>) element defines the link’s destination. For phone numbers, the proper URI scheme is tel:, not callto:. According to the HTML standard and the WHATWG Living Standard, the phone number should contain only digits and may use plus (+) or hyphen (-) characters for formatting, but it should not include spaces or slashes.

Incorrect HTML:

<a href="callto:07142/ 12 34 5">Call us</a>

Correct HTML:

<a href="tel:0714212345">Call us</a>

With country code and optional formatting:

<a href="tel:+49714212345">Call us</a>

For best compatibility and validation, always use the tel: scheme and ensure the phone number string contains only allowed characters.

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>

A URI (Uniform Resource Identifier) follows a strict syntax defined by RFC 3986. The general structure is scheme:scheme-data, where no spaces or other illegal characters are allowed between the colon and the scheme-specific data. When the W3C validator reports “Illegal character in scheme data,” it means the parser found a character that isn’t permitted in that position of the URI.

The most common cause of this error is adding a space after the colon in tel: links (e.g., tel: +123456789). While browsers may be forgiving and still handle the link, the markup is technically invalid. This matters for several reasons:

• Accessibility: Screen readers and assistive technologies rely on well-formed URIs to correctly identify link types. A malformed tel: link might not be announced as a phone number.
• Standards compliance: Invalid URIs violate the HTML specification, which requires the href attribute to contain a valid URL.
• Cross-device behavior: Mobile devices use the URI scheme to determine which app should handle a link. A malformed tel: URI may fail to trigger the phone dialer on some devices or operating systems.
• Interoperability: While some browsers silently trim spaces, others may encode them as %20, potentially breaking the phone number or other scheme data.

To fix this issue, ensure there are no spaces or other illegal characters between the scheme’s colon and the data that follows it. For telephone links specifically, the number should follow the colon directly, using only digits, hyphens, dots, parentheses, and the + prefix as defined by RFC 3966.

Examples

Incorrect: space after the colon in a tel: link

<a href="tel: +1-234-567-8900">Call us</a>

The space between tel: and +1 is an illegal character in the URI scheme data.

Correct: no space after the colon

<a href="tel:+1-234-567-8900">Call us</a>

Incorrect: space after the colon in a mailto: link

<a href="mailto: support@example.com">Email support</a>

Correct: mailto: with no space

<a href="mailto:support@example.com">Email support</a>

Incorrect: other illegal characters in scheme data

<a href="tel:+1 234 567 8900">Call us</a>

Spaces within the phone number itself are also illegal characters in the URI. Use hyphens, dots, or no separators instead.

Correct: valid separators in a phone number

<a href="tel:+1-234-567-8900">Call us</a>
<a href="tel:+1.234.567.8900">Call us</a>
<a href="tel:+12345678900">Call us</a>

Visual formatting vs. the href value

If you want the displayed phone number to include spaces for readability, format the visible text separately from the href value:

<a href="tel:+12345678900">+1 234 567 8900</a>

The href contains a valid URI with no spaces, while the link text is formatted for easy reading. This gives you the best of both worlds — valid markup and a user-friendly display.