HTML Validation

HTML Guides for bad value

Learn how to identify and fix common HTML validation errors flagged by the W3C Validator — so your pages are standards-compliant and render correctly across every browser. Also check our Accessibility Guides.

Scan Your Site Free

Bad value (true|false) for attribute “itemscope” on element “html”.

The itemscope attribute is part of the HTML Microdata specification, used to define the scope of structured data on a page. It works alongside itemtype and itemprop to provide machine-readable metadata about your content, which search engines and other tools can use to better understand your pages.

In HTML, boolean attributes follow a specific rule: their mere presence on an element represents a true state, and their absence represents false. Unlike JavaScript or other programming languages where you might write itemscope="true" or itemscope="false", HTML boolean attributes do not work this way. The only valid forms for a boolean attribute are:

The attribute name alone: itemscope
The attribute with an empty value: itemscope=""
The attribute with its own name as the value: itemscope="itemscope"

Assigning any other value — including "true" or "false" — is invalid HTML. This is especially confusing because itemscope="false" does not disable the attribute. Since the attribute is still present on the element, the browser treats it as active. This can lead to incorrect structured data being generated, which may cause search engines to misinterpret your content.

This issue matters for several reasons:

Standards compliance: Invalid attribute values violate the HTML specification, causing W3C validation errors.
Structured data accuracy: Incorrect microdata markup can result in search engines misreading your page content, potentially affecting rich search results.
Developer intent: Writing itemscope="false" suggests you want to disable the attribute, but it actually does the opposite — the attribute remains active.

To fix this, simply use the bare attribute name when you want it enabled, or remove it entirely when you don’t.

Examples

Incorrect: assigning "true" to itemscope

<html itemscope="true" itemtype="https://schema.org/WebPage">
<!-- ... -->

</html>

Incorrect: assigning "false" to itemscope

This does not disable itemscope — the attribute is still present, so the browser treats it as active.

<div itemscope="false" itemtype="https://schema.org/Product">
  <span itemprop="name">Widget</span>
</div>

Correct: using the bare attribute

<html itemscope itemtype="https://schema.org/WebPage">
<!-- ... -->

</html>

Correct: using an empty string value

This is an equally valid way to specify a boolean attribute, though the bare form is more common and readable.

<div itemscope="" itemtype="https://schema.org/Product">
  <span itemprop="name">Widget</span>
</div>

Correct: removing the attribute entirely

If you don’t need itemscope on the element, simply omit it.

<html lang="en">
  <head>
    <title>My Page</title>
  </head>
  <body>
    <p>No microdata here.</p>
  </body>
</html>

Correct: a complete example with microdata

<!DOCTYPE html>
<html lang="en" itemscope itemtype="https://schema.org/WebPage">
  <head>
    <title>My Product</title>
  </head>
  <body>
    <div itemscope itemtype="https://schema.org/Product">
      <h1 itemprop="name">Super Widget</h1>
      <p itemprop="description">The best widget money can buy.</p>
    </div>
  </body>
</html>

This same rule applies to all HTML boolean attributes, such as hidden, disabled, checked, required, readonly, autoplay, and defer. None of them accept "true" or "false" as values — they are either present or absent.

Bad value “callto:X” for attribute “href” on element “a”: Illegal character in scheme data: space is not allowed.

When you write a phone link using <a href="callto:...">, you may encounter two distinct problems at once. First, the callto: scheme is a legacy, non-standard protocol originally associated with Skype. The correct and widely supported URI scheme for telephone links is tel:, as defined by RFC 3966. Second, spaces within URI scheme data are illegal characters. URIs must not contain unencoded spaces anywhere, and telephone URIs specifically expect a compact phone number composed of digits, hyphens (-), dots (.), and an optional leading plus sign (+) for international dialing.

The W3C validator raises this error because the value provided to href violates URI syntax rules. Browsers may still attempt to handle the link, but behavior will be inconsistent — some mobile browsers may not recognize callto: at all, and spaces in the URI can cause the number to be parsed incorrectly or truncated. Using the standard tel: scheme with a properly formatted number ensures the link works reliably across devices and platforms, including mobile phones, VoIP applications, and assistive technologies.

How to fix it

Replace callto: with tel: — The tel: scheme is the standard for phone number links and is supported by all modern browsers and mobile operating systems.
Remove spaces and slashes — Strip out any spaces, slashes, or parentheses from the phone number. These characters are not valid in a tel: URI without percent-encoding, and they serve no functional purpose in the link target.
Use a leading + for international numbers — If applicable, include the full international dialing code prefixed with + (e.g., +1 for the US, +49 for Germany). This makes the link work regardless of the caller’s location.
Optional visual separators — If you want visual separators within the href for readability in your source code, use hyphens (-) or dots (.), which are permitted in tel: URIs. However, the simplest and safest approach is digits only (plus the optional leading +).

Examples

Incorrect: callto: with spaces and slashes

This triggers the validator error because spaces and slashes are illegal in URI scheme data, and callto: is non-standard.

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

Incorrect: tel: with spaces

Even with the correct tel: scheme, spaces in the phone number are still invalid URI characters.

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

Correct: tel: with digits only

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

Correct: International number with + prefix

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

Correct: Using hyphens for readability

Hyphens are valid characters in tel: URIs and can improve source code readability without affecting functionality.

<a href="tel:+49-07142-12345">Call us</a>

Displaying a formatted number to the user

You can still show a human-friendly formatted number as the visible link text while keeping the href value clean and valid.

<a href="tel:+490714212345">+49 (0) 7142 / 12 34 5</a>

This approach gives you the best of both worlds: the link text is easy for users to read, and the href value is a valid, standards-compliant tel: URI that works reliably across all devices and passes W3C validation.

Bad value “contact” for attribute “autocomplete” on element “input”: The string “contact” is not a valid autofill field name.

The autocomplete attribute helps browsers autofill form fields with previously saved user data. The HTML specification defines a strict set of valid values, and each one maps to a specific type of information (like a name, email address, phone number, or street address). The string "contact" by itself is not a valid autofill field name — it’s a contact type token, which is a modifier meant to be combined with a field name to distinguish between different types of contact information.

The HTML spec defines two contact type tokens: "home", "work", "mobile", "fax", and "pager" (for phone-related fields), as well as the broader "shipping" and "billing" scoping tokens. The token "contact" doesn’t exist as a standalone value at all. You may have confused it with a contact type prefix pattern like "home email" or "work tel", or you may have intended to use a specific field name entirely.

Getting the autocomplete value right matters for several reasons. Browsers rely on these exact tokens to offer relevant autofill suggestions. Screen readers and assistive technologies may also use this information to help users understand what data a field expects. An invalid value means the browser will likely ignore the attribute entirely, degrading the user experience — especially on mobile devices where autofill is heavily used.

To fix the issue, determine what kind of information the input field is collecting and use the appropriate autofill field name. Common valid values include "name", "email", "tel", "street-address", "postal-code", "organization", and "username". If you want to indicate that this is specifically a contact email or phone (as opposed to, say, a billing one), you don’t use "contact" — instead, you can omit the modifier entirely or use a section-scoping approach.

Examples

❌ Invalid: Using “contact” as the autocomplete value

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

The value "contact" is not a recognized autofill field name, so the browser cannot determine what to autofill.

✅ Fixed: Using a valid autofill field name

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

The value "email" is a valid autofill field name that tells the browser to suggest saved email addresses.

✅ Fixed: Using a valid combination with a section or contact type token

If you need to differentiate between types of phone numbers, you can use tokens like "home", "work", or "mobile" as prefixes:

<label for="work-tel">Work Phone</label>
<input type="tel" id="work-tel" name="work-tel" autocomplete="work tel">

<label for="home-email">Personal Email</label>
<input type="email" id="home-email" name="home-email" autocomplete="home email">

Common valid autocomplete values

Here are some frequently used valid autofill field names:

Value	Purpose
"name"	Full name
"email"	Email address
"tel"	Phone number
"username"	Username
"new-password"	New password (for registration)
"current-password"	Existing password (for login)
"street-address"	Street address
"postal-code"	ZIP or postal code
"country-name"	Country name
"organization"	Company or organization
"off"	Disable autofill

For the complete list of valid values and their permitted combinations, refer to the WHATWG autofill specification.

Bad value “dialog” for attribute “role” on element “dialog”.

The HTML specification defines a set of implicit ARIA roles (also called “native semantics”) for many HTML elements. The <dialog> element’s implicit role is dialog, which means assistive technologies like screen readers already announce it correctly without any explicit ARIA markup. When you add role="dialog" to a <dialog> element, you’re restating what the browser and accessibility tree already know—and the ARIA in HTML specification explicitly restricts this.

The ARIA in HTML spec maintains a list of allowed roles for each HTML element. For <dialog>, the only permitted role override is alertdialog (for dialogs that require an immediate response from the user). Setting role="dialog" is not listed as an allowed value because it duplicates the native semantics, and the spec treats such redundancy as a conformance error. This is why the W3C Validator reports: Bad value “dialog” for attribute “role” on element “dialog”.

Why this matters

Standards compliance: The W3C Validator enforces the ARIA in HTML specification, which prohibits redundant role assignments on elements that already carry that role implicitly. Valid markup ensures your pages conform to web standards.
Accessibility clarity: While most assistive technologies handle redundant roles gracefully today, unnecessary ARIA attributes add noise to the codebase and can cause confusion about whether the element’s native semantics are intentionally being overridden. The first rule of ARIA is: don’t use ARIA if a native HTML element already provides the semantics you need.
Maintainability: Removing redundant attributes keeps your HTML clean and easier to maintain. Future developers won’t need to wonder whether the explicit role was added intentionally to work around a bug.

How to fix it

Locate any <dialog> element with a role="dialog" attribute.
Remove the role attribute entirely.
If you need the dialog to behave as an alert dialog (one that interrupts the user and demands immediate attention), use role="alertdialog" instead—this is the one permitted role override for <dialog>.

Examples

Incorrect — redundant role causes a validation error

<dialog role="dialog">
  <h2>Confirm action</h2>
  <p>Are you sure you want to proceed?</p>
  <button>Cancel</button>
  <button>Confirm</button>
</dialog>

Correct — relying on the implicit role

<dialog>
  <h2>Confirm action</h2>
  <p>Are you sure you want to proceed?</p>
  <button>Cancel</button>
  <button>Confirm</button>
</dialog>

The <dialog> element automatically exposes role="dialog" in the accessibility tree, so no explicit attribute is needed.

Correct — using an allowed role override

If the dialog represents an urgent alert that requires immediate user interaction, you can override the role with alertdialog:

<dialog role="alertdialog" aria-labelledby="alert-title" aria-describedby="alert-desc">
  <h2 id="alert-title">Session expiring</h2>
  <p id="alert-desc">Your session will expire in 60 seconds. Do you want to continue?</p>
  <button>Stay signed in</button>
</dialog>

This is valid because alertdialog is explicitly listed as a permitted role for the <dialog> element in the ARIA in HTML specification. Note that aria-labelledby and aria-describedby are strongly recommended for alert dialogs so assistive technologies can announce the title and description properly.

Bad value “dob” for attribute “type” on element “input”.

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.

Bad value “false” for attribute “hidden” on element X.

The hidden attribute indicates that an element is not yet, or is no longer, relevant to the current state of the page. Browsers will not render elements that have this attribute. It’s available on all HTML elements as a global attribute.

In HTML, boolean attributes like hidden, disabled, readonly, and checked follow special rules. Unlike attributes in programming languages where you might set a value to true or false, boolean attributes in HTML work by presence or absence:

Present = the feature is on (e.g., hidden, hidden="", or hidden="hidden")
Absent = the feature is off (the attribute is simply not in the markup)

This is a common source of confusion. Writing hidden="false" does not make the element visible. Because the attribute is still present in the markup, the browser interprets it as “this element is hidden.” The actual string value "false" is ignored for the purpose of determining the boolean state. This can lead to frustrating bugs where elements remain invisible despite what looks like correct code.

According to the HTML specification, the only valid values for a boolean attribute are the empty string ("") or the attribute’s own name (e.g., hidden="hidden"). Any other value, including "true" or "false", is invalid and will trigger a W3C validator error.

How the hidden attribute works with newer values

Starting with more recent updates to the HTML specification, the hidden attribute also accepts the value "until-found". When set to hidden="until-found", the element remains hidden but can be revealed by the browser’s find-in-page feature or by fragment navigation. This is the only keyword value (besides the empty string and the attribute’s canonical name) that changes the attribute’s behavior. It does not change the fact that "false" is an invalid value.

How to fix it

To hide an element, add the hidden attribute with no value.
To show an element, remove the hidden attribute entirely from the markup.
If you’re toggling visibility with JavaScript, use element.hidden = false (the JavaScript property, not the HTML attribute) or element.removeAttribute('hidden').

Examples

❌ Invalid: setting hidden to "false"

<!-- The element is STILL hidden and the markup is invalid -->

<div hidden="false">You won't see this text.</div>

❌ Invalid: setting hidden to "true"

<!-- "true" is also not a valid value for a boolean attribute -->

<p hidden="true">This paragraph is hidden, but the markup is invalid.</p>

✅ Valid: using hidden without a value

<div hidden>This element is hidden from the page.</div>

✅ Valid: using hidden with an empty string or its own name

<!-- Both of these are valid ways to write boolean attributes -->

<div hidden="">Hidden element</div>
<div hidden="hidden">Also a hidden element</div>

✅ Valid: showing the element by omitting hidden

<div>This element is visible because it has no hidden attribute.</div>

✅ Valid: using hidden="until-found"

<div hidden="until-found">
  This content is hidden but can be found via browser search.
</div>

Toggling visibility with JavaScript

When dynamically showing or hiding elements, use the hidden property on the DOM element rather than setting the attribute to "false":

<button type="button" id="toggle">Toggle message</button>
<p id="message" hidden>Hello! Now you can see me.</p>
<script>
  document.getElementById("toggle").addEventListener("click", function () {
    const msg = document.getElementById("message");
    msg.hidden = !msg.hidden; // Correctly toggles the boolean property
  });
</script>

Using msg.hidden = false in JavaScript correctly removes the hidden attribute from the element. This is different from writing hidden="false" directly in HTML, which keeps the attribute present and triggers the validation error.

Bad value “” for attribute “aria-controls” on element “a”: An IDREFS value must contain at least one non-whitespace character.

The validator error occurs when an element such as an a, button, or custom widget includes aria-controls="" (empty) or whitespace-only. The aria-controls attribute takes one or more space-separated id values (IDREFS). Each referenced id must exist exactly once in the same document. Leaving it empty violates the ARIA and HTML requirements and provides no usable relationship for assistive technologies.

Why this matters:

Accessibility: Screen readers rely on aria-controls to announce relationships between controls and controlled regions (e.g., a toggle and its panel). An empty value misleads AT or adds noise.
Standards compliance: HTML and ARIA require at least one non-whitespace id. Empty values cause validation failures.
Robustness: Incorrect references can confuse scripts and future maintainers, and break behavior when IDs change.

How to fix it:

Only add aria-controls when the element truly controls another region (show/hide, sort, update).
Ensure the controlled element has a unique id.
Set aria-controls to that id (or multiple space-separated IDs).
Keep the reference in sync if IDs change.
If nothing is controlled, remove aria-controls entirely.

Examples

Invalid: empty aria-controls (triggers the error)

<a href="#" aria-controls="">Toggle details</a>

Valid: control a single region

<div id="details-panel" hidden>
  Some details...
</div>
<a href="#details-panel" aria-controls="details-panel">Toggle details</a>

Valid: control multiple regions (space-separated IDs)

<section id="filters" hidden>...</section>
<section id="results" hidden>...</section>
<button type="button" aria-controls="filters results">Show filters and results</button>

Valid: remove when not needed

<a href="#">Toggle details</a>

Minimal complete document with proper usage

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>aria-controls Example</title>
  </head>
  <body>
    <button type="button" aria-controls="info" aria-expanded="false">Toggle info</button>
    <div id="info" hidden>
      Extra information.
    </div>
    <script>
      const btn = document.querySelector('button');
      const panel = document.getElementById(btn.getAttribute('aria-controls'));
      btn.addEventListener('click', () => {
        const expanded = btn.getAttribute('aria-expanded') === 'true';
        btn.setAttribute('aria-expanded', String(!expanded));
        panel.hidden = expanded;
      });
    </script>
  </body>
</html>

Tips:

Use aria-controls for functional relationships (control affects content), not just visual proximity.
Combine with aria-expanded when toggling visibility to convey state.
Verify that every id in aria-controls exists and is unique; avoid dynamic mismatches created by templating or component reuse.

Bad value for attribute “href” on element “a”: Illegal character in fragment: “#” is not allowed.

In a URL, the # character has a special role: it acts as the delimiter that separates the main URL from the fragment identifier. The fragment typically points to a specific section or element within the target document, often corresponding to an element’s id attribute. Because # serves this reserved purpose, it cannot appear more than once in its raw form within a URL. When the validator encounters something like ##pricing or section#one#two, it flags the extra # characters as illegal.

This issue usually arises from one of these common scenarios:

Typos — accidentally typing ## instead of #.
String concatenation bugs — building URLs programmatically where a # is included both in the base URL and prepended to the fragment value.
Copy-paste errors — duplicating the # when copying URLs from browser address bars or other sources.
Literal # intended in fragment — if you genuinely need a # symbol within the fragment text, it must be percent-encoded as %23.

This matters because browsers may handle malformed URLs inconsistently. Some browsers silently strip the extra #, while others may fail to navigate to the intended fragment. Malformed URLs also cause problems for assistive technologies, web crawlers, and any tooling that parses links. Keeping your URLs well-formed ensures predictable behavior across all user agents and complies with the URL Standard and HTML specification.

Examples

Incorrect: duplicate # in the URL

The double ## makes the fragment identifier invalid:

<a href="https://example.com/faqs##pricing">Pricing</a>

Correct: single # delimiter

Remove the extra # so that pricing is the fragment:

<a href="https://example.com/faqs#pricing">Pricing</a>

Incorrect: extra # inside the fragment

Here, the fragment portion overview#details contains a raw #, which is not allowed:

<a href="/docs#overview#details">Details</a>

Correct: percent-encode the literal #

If you truly need a # as part of the fragment text, encode it as %23:

<a href="/docs#overview%23details">Details</a>

In most cases though, this pattern suggests the URL structure should be rethought. A cleaner approach is to link directly to the intended fragment:

<a href="/docs#details">Details</a>

Incorrect: programmatic concatenation error

A common bug in templates or JavaScript is prepending # when the variable already includes it:

<!-- If defined as defined as fragment = "#pricing", this produces a double ## -->

<a href="https://example.com/faqs#pricing">Pricing</a>

Correct: ensure only one # is present

Make sure either the base URL or the fragment variable includes the #, but not both:

<a href="https://example.com/faqs#pricing">Pricing</a>

Fragment-only links

Fragment-only links (links to sections within the same page) follow the same rule — only one #:

<!-- Incorrect -->

<a href="##contact">Contact Us</a>

<!-- Correct -->

<a href="#contact">Contact Us</a>

Bad value for attribute “href” on element “a”: Illegal character in fragment: space is not allowed.

A URL fragment identifier is the part of a URL that follows the # character. It typically points to an element on the page that has a matching id attribute. According to the URL specification, certain characters — including spaces — are not allowed to appear literally in a URL. When the W3C HTML Validator encounters a raw space in a fragment, it reports this as an illegal character.

This issue matters for several reasons. Browsers may handle unescaped spaces in fragments inconsistently, leading to broken in-page navigation. Screen readers and other assistive technologies rely on well-formed URLs to navigate users to the correct section of a page. Additionally, spaces in id attributes are themselves invalid in HTML — the id attribute must not contain any ASCII whitespace characters. So the root cause often involves two separate violations: an invalid id and an invalid fragment URL.

The best approach is to use hyphens (-) or underscores (_) instead of spaces in your id values, then match the fragment accordingly. This produces clean, readable, and shareable URLs (e.g., page.html#contact-info instead of page.html#contact%20info). If you’re working with a CMS or build tool that auto-generates id values with spaces, configure it to produce hyphen-separated, lowercase identifiers instead.

If you absolutely cannot change the id values (e.g., they’re generated by a third-party system), you can percent-encode the spaces as %20 in the href. This satisfies URL syntax rules, but note that an id containing spaces is still invalid HTML on its own. Fixing the id is always the preferred solution.

Examples

Invalid: space in fragment and id

This triggers the validator error because href="#My Section" contains an unescaped space. The id="My Section" is also invalid HTML since id values cannot contain spaces.

<a href="#My Section">Go to section</a>

<h2 id="My Section">My Section</h2>

Fixed: hyphen-separated fragment and id

Replace spaces with hyphens in both the id and the fragment. This is the cleanest and most widely recommended approach.

<a href="#my-section">Go to section</a>

<h2 id="my-section">My Section</h2>

Fixed: underscore-separated fragment and id

Underscores work equally well if you prefer that convention.

<a href="#my_section">Go to section</a>

<h2 id="my_section">My Section</h2>

Alternative: percent-encoding the space

Encoding the space as %20 resolves the fragment URL error, but the id with a space is still invalid HTML. Use this only as a last resort when you cannot control the id values.

<a href="#My%20Section">Go to section</a>

<!-- Note: this id is still invalid HTML due to the space -->

<h2 id="My Section">My Section</h2>

Full valid document

A complete example demonstrating multiple in-page links with properly formatted fragments and id values:

<!doctype html>
<html lang="en">
  <head>
    <title>Page sections</title>
  </head>
  <body>
    <nav>
      <ul>
        <li><a href="#getting-started">Getting Started</a></li>
        <li><a href="#advanced-usage">Advanced Usage</a></li>
        <li><a href="#frequently-asked-questions">FAQ</a></li>
      </ul>
    </nav>

    <h2 id="getting-started">Getting Started</h2>
    <p>Introduction content here.</p>

    <h2 id="advanced-usage">Advanced Usage</h2>
    <p>Advanced content here.</p>

    <h2 id="frequently-asked-questions">Frequently Asked Questions</h2>
    <p>FAQ content here.</p>
  </body>
</html>

Bad value X for attribute “href” on element “a”: Illegal character in path segment

URLs follow strict syntax rules defined by RFC 3986. Only a specific set of characters are allowed directly in a URL path segment — these include letters, digits, hyphens (-), periods (.), underscores (_), and tildes (~), along with a handful of sub-delimiters like !, $, &, ', (, ), *, +, ,, ;, and =. Any character outside this set — including spaces, angle brackets (< >), curly braces ({ }), pipe characters (|), backslashes (\), carets (^), and backticks (`) — must be percent-encoded.

Percent-encoding replaces the character with a % sign followed by its two-digit hexadecimal ASCII code. For example:

Character	Percent-encoded
(space)	%20
{	%7B
}	%7D

| | | %7C | | < | %3C | | > | %3E | | ^ | %5E |

This validation error matters for several reasons. First, browsers may handle illegal characters inconsistently — some may silently encode them, while others may break the link or navigate to an unexpected destination. Second, tools that parse HTML (screen readers, search engine crawlers, link checkers) rely on well-formed URLs and may fail or behave unpredictably when they encounter illegal characters. Third, standards compliance ensures your HTML works reliably across all environments.

Common causes of this error include:

Copying and pasting URLs from documents or emails that contain unencoded spaces or special characters.
Template variables or placeholders left in href values (e.g., {{url}}).
File paths with spaces used directly as URLs without encoding.
Non-ASCII characters in URLs that haven’t been properly encoded.

Examples

❌ Space in the URL path

<a href="/my page/about us.html">About Us</a>

✅ Spaces percent-encoded as %20

<a href="/my%20page/about%20us.html">About Us</a>

❌ Curly braces from a template placeholder left in the markup

<a href="/products/{{product-id}}/details">View Details</a>

✅ Curly braces replaced with an actual value

<a href="/products/42/details">View Details</a>

❌ Pipe character in the path

<a href="/search/color|size">Filter Results</a>

✅ Pipe character percent-encoded as %7C

<a href="/search/color%7Csize">Filter Results</a>

❌ Angle brackets in the URL

<a href="/page/<section>">Go to Section</a>

✅ Angle brackets percent-encoded

<a href="/page/%3Csection%3E">Go to Section</a>

How to Fix

Identify the illegal character from the validator’s error message — it typically tells you exactly which character is problematic.
Replace it with the correct percent-encoded equivalent using the table above or a URL encoder tool.
If the URL contains template syntax (like {{...}}), make sure your templating engine processes it before the HTML is served to the browser. The raw template syntax should never appear in the final rendered HTML.
Consider renaming files and directories to avoid spaces and special characters altogether — this is the cleanest long-term solution.

If you’re generating URLs programmatically, use built-in encoding functions like JavaScript’s encodeURIComponent() or PHP’s rawurlencode() to ensure all special characters are properly escaped before inserting them into href attributes.

Bad value for attribute “href” on element “a”: Illegal character in query: “|” is not allowed.

The W3C HTML Validator checks that URLs used in attributes like href conform to the URL Standard maintained by WHATWG. According to this standard, only certain characters are permitted to appear literally in the query component of a URL. The pipe character (|, Unicode U+007C) is not in the set of allowed query characters, which means it must be percent-encoded as %7C when it appears in a URL’s query string.

While most modern browsers will silently handle a raw | in a URL and still navigate to the intended destination, relying on this behavior is problematic for several reasons:

Standards compliance: HTML documents that contain unencoded special characters in URLs are technically invalid and will fail W3C validation.
Interoperability: Not all user agents, HTTP clients, web scrapers, or proxy servers handle illegal URL characters the same way. An unencoded pipe could be misinterpreted, stripped, or cause unexpected behavior in certain environments.
Security: Properly encoding URLs helps prevent injection attacks and ensures that each part of the URL is unambiguously parsed. Unencoded special characters can be exploited in certain contexts.
Link sharing and processing: URLs are often copied, pasted, embedded in emails, or processed by APIs. An unencoded | may break the URL when it passes through systems that strictly enforce URL syntax.

This issue commonly arises when URLs are constructed by hand, pulled from databases, or generated by backend systems that don’t automatically encode query parameters. It can also appear when using pipe-delimited values as query parameter values (e.g., ?filter=red|blue|green).

The fix is straightforward: replace every literal | in the URL with its percent-encoded equivalent %7C. If you’re generating URLs in code, use built-in encoding functions like JavaScript’s encodeURIComponent() or PHP’s urlencode() to handle this automatically.

Examples

Incorrect: raw pipe character in query string

<a href="https://example.com/search?q=test|demo">Search</a>

The literal | in the query string triggers the validation error.

Correct: pipe character percent-encoded

<a href="https://example.com/search?q=test%7Cdemo">Search</a>

Replacing | with %7C makes the URL valid. The server receiving this request will decode it back to test|demo automatically.

Incorrect: multiple pipe characters as delimiters

<a href="https://example.com/filter?colors=red|blue|green">Filter colors</a>

Correct: all pipe characters encoded

<a href="https://example.com/filter?colors=red%7Cblue%7Cgreen">Filter colors</a>

Generating encoded URLs in JavaScript

If you’re building URLs dynamically, use encodeURIComponent() to encode individual parameter values:

<script>
  const colors = "red|blue|green";
  const url = "https://example.com/filter?colors=" + encodeURIComponent(colors);
  // Result: "https://example.com/filter?colors=red%7Cblue%7Cgreen"
</script>

This ensures that any special characters in the value — including |, spaces, ampersands, and others — are properly encoded without you needing to remember each character’s percent-encoded form.

Other characters to watch for

The pipe character is not the only one that causes this validation error. Other characters that must be percent-encoded in URL query strings include curly braces ({ and }), the caret (^), backtick (`), and square brackets ([ and ]) when used outside of specific contexts. As a general rule, always encode user-supplied or dynamic values using your language’s URL encoding function rather than constructing query strings through simple string concatenation.

Bad value for attribute “href” on element “a”: Illegal character in query: space is not allowed.

The href attribute expects a valid URL, and URLs follow strict syntax rules defined by RFC 3986. Under these rules, spaces are not permitted anywhere in a URL — not in the path, the query string, the fragment, or any other component. When a browser encounters a space in an href, it may attempt to fix the URL by encoding the space automatically, but this behavior is not guaranteed to be consistent across all browsers and contexts. Relying on browsers to silently correct invalid URLs is fragile and can lead to broken links.

This matters for several reasons. First, standards compliance: the W3C validator flags this because the HTML specification requires href values to be valid URLs. Second, interoperability: while most modern browsers handle spaces gracefully on navigation, other consumers of your HTML — such as web crawlers, screen readers, link checkers, and APIs that parse HTML — may not. Third, accessibility: assistive technologies rely on well-formed URLs to correctly announce and follow links. A malformed URL could lead to unexpected behavior for users depending on these tools.

The fix is straightforward: replace every literal space character with %20. This is called percent-encoding (sometimes called URL encoding). The sequence %20 is the hexadecimal representation of the space character (ASCII code 32). In the query string portion of a URL specifically, you may also see + used to represent spaces (as defined by the application/x-www-form-urlencoded format), but %20 is universally valid across all parts of a URL and is the safer choice.

Be aware that spaces can sometimes be hard to spot, especially trailing spaces or spaces introduced by template engines and CMS platforms that concatenate URL parts. If you’re generating URLs dynamically (e.g., in a server-side template or JavaScript), use built-in encoding functions like encodeURIComponent() in JavaScript or urlencode() in PHP rather than manually replacing spaces.

Examples

Incorrect: space in the query string

<a href="search.html?q=my search">Search for 'my search'</a>

The literal space between my and search makes this an invalid URL.

Correct: space replaced with %20

<a href="search.html?q=my%20search">Search for 'my search'</a>

Incorrect: spaces in the path

<a href="/files/my document.pdf">Download the document</a>

Spaces in the path segment are equally invalid.

Correct: spaces in the path encoded

<a href="/files/my%20document.pdf">Download the document</a>

Incorrect: multiple spaces across path and query

<a href="/product catalog/items?name=red shoes&category=on sale">Red Shoes</a>

Correct: all spaces encoded

<a href="/product%20catalog/items?name=red%20shoes&amp;category=on%20sale">Red Shoes</a>

Note that in addition to encoding the spaces, the & in the query string should be written as & in HTML to avoid being interpreted as the start of an HTML entity.

Using JavaScript to encode URLs dynamically

If you’re building URLs in JavaScript, use encodeURIComponent() for individual parameter values or encodeURI() for full URLs:

<script>
  const query = "my search";
  const url = "search.html?q=" + encodeURIComponent(query);
  // Result: "search.html?q=my%20search"
</script>

This approach prevents encoding issues by handling all special characters automatically — not just spaces, but also characters like #, &, =, and others that have special meaning in URLs.

Bad value for attribute “href” on element “a”: Illegal character in query: “[” is not allowed.

The W3C HTML Validator checks that URLs in href attributes conform to the URL standard (defined by WHATWG). While square brackets are permitted in the host component of a URL (to support IPv6 addresses like [::1]), they are not valid unescaped characters in the query string — the part of the URL that comes after the ?. When the validator encounters a literal [ or ] in the query portion, it flags it as an illegal character.

This issue commonly arises when working with APIs or server-side frameworks that use square brackets in query parameters to represent arrays or nested data structures. For example, PHP-style query strings like ?filter[name]=foo or ?ids[]=1&ids[]=2 contain brackets that must be encoded for valid HTML.

Why this matters

Standards compliance: The WHATWG URL Standard explicitly lists square brackets among the characters that must be percent-encoded in query strings. Invalid URLs cause W3C validation failures.
Browser behavior: While most modern browsers are forgiving and will often handle unescaped brackets correctly, relying on this lenient parsing is fragile. Some HTTP clients, proxies, or intermediary servers may reject or mangle URLs with illegal characters.
Interoperability: Encoded URLs are safer when copied, shared, or processed by tools like link checkers, web scrapers, or email clients that may perform strict URL parsing.

How to fix it

Replace every literal square bracket in the query string with its percent-encoded form:

Character	Percent-encoded
[	%5B
]	%5D

If you’re generating URLs dynamically in a server-side language or JavaScript, use the appropriate encoding function (e.g., encodeURIComponent() in JavaScript, urlencode() in PHP, or urllib.parse.quote() in Python) to handle this automatically.

Examples

Incorrect: literal brackets in the query string

<a href="https://example.com/search?filter[status]=active">Active items</a>

This triggers the validation error because [ and ] appear unescaped in the query.

Correct: percent-encoded brackets

<a href="https://example.com/search?filter%5Bstatus%5D=active">Active items</a>

Replacing [ with %5B and ] with %5D resolves the error. The server receiving this request will decode the values back to filter[status]=active.

Incorrect: array-style parameters with brackets

<a href="/api/items?ids[]=1&ids[]=2&ids[]=3">Load items</a>

Correct: array-style parameters encoded

<a href="/api/items?ids%5B%5D=1&amp;ids%5B%5D=2&amp;ids%5B%5D=3">Load items</a>

Note that in addition to encoding the brackets, the & characters in HTML attributes should be written as & for fully valid markup.

Incorrect: brackets in a simple value

<a href="search.html?q=[value]">Search</a>

Correct: encoded brackets in a simple value

<a href="search.html?q=%5Bvalue%5D">Search</a>

Note on brackets in the host (valid use)

Square brackets are valid in the host portion of a URL for IPv6 addresses. The following does not trigger the error:

<a href="http://[::1]:8080/page">IPv6 localhost</a>

The validator only flags brackets that appear in the query string or other parts of the URL where they are not permitted.

Bad value for attribute “href” on element “a”: Illegal character in scheme data: “\” is not allowed.

The W3C HTML Validator raises this error when it encounters a backslash character (\) inside the href attribute of an anchor element. According to the WHATWG URL Standard, backslashes are not valid characters in URL scheme data. URLs are defined with forward slashes (/) as delimiters — this applies to all parts of a URL, including the scheme, authority, path, query, and fragment.

This issue most commonly occurs when developers copy file paths from Windows operating systems, where backslashes are the default path separator (e.g., C:\Users\Documents\file.html), and paste them directly into HTML markup. It can also happen when server-side code generates URLs using OS-level path functions that produce backslashes on Windows.

Why this matters

Standards compliance: The WHATWG URL Standard explicitly forbids backslashes in scheme data. Validators flag this as an error because the resulting URL is malformed.
Cross-browser inconsistency: While some browsers may silently correct backslashes to forward slashes, this behavior is not guaranteed across all browsers or versions. Relying on browser error correction leads to fragile code.
Broken links: Certain browsers, HTTP clients, or intermediary servers may not auto-correct the backslash, causing the link to fail entirely — resulting in 404 errors or unexpected navigation.
Security concerns: Backslashes in URLs can be exploited in certain attack vectors like open redirects or path traversal attacks. Using well-formed URLs reduces the attack surface.

How to fix it

Replace all backslashes (\) with forward slashes (/) in your href values.
Check for URL generation in server-side code. If your application builds URLs programmatically, ensure it uses forward slashes regardless of the host operating system.
Use relative or absolute URLs consistently. Whether the URL is relative (images/photo.jpg) or absolute (https://example.com/images/photo.jpg), always use forward slashes.

Examples

Incorrect: backslashes in a relative path

<a href="pages\about\team.html">Meet the Team</a>

Correct: forward slashes in a relative path

<a href="pages/about/team.html">Meet the Team</a>

Incorrect: backslashes in an absolute URL

<a href="https://example.com\blog\2024\post.html">Read the Post</a>

Correct: forward slashes in an absolute URL

<a href="https://example.com/blog/2024/post.html">Read the Post</a>

Incorrect: Windows file path pasted directly

<a href="assets\downloads\report.pdf">Download Report</a>

Correct: converted to a proper relative URL

<a href="assets/downloads/report.pdf">Download Report</a>

Incorrect: mixed slashes

Sometimes a URL contains a mix of forward and backslashes, which also triggers this error:

<a href="https://example.com/images\photos\sunset.jpg">View Photo</a>

Correct: all forward slashes

<a href="https://example.com/images/photos/sunset.jpg">View Photo</a>

A quick way to audit your HTML files is to search for \ within any href (or src, action, etc.) attribute values and replace them with /. In most code editors, you can use find-and-replace scoped to attribute values to handle this efficiently.

Bad value “X” for attribute “href” on element “link”: Illegal character in path segment: “X” is not allowed.

URLs follow strict syntax rules defined by RFC 3986. Within the path segment of a URL, only a specific set of characters is allowed: unreserved characters (letters, digits, -, ., _, ~), percent-encoded characters (like %20), and certain reserved sub-delimiters. When the W3C validator encounters a character outside this allowed set in a <link> element’s href attribute, it flags the error.

Common causes of this issue include:

Template placeholders left in the URL, such as {{variable}} or ${path}, where curly braces and dollar signs haven’t been resolved or encoded.
Spaces in file paths, such as href="styles/my file.css" instead of using %20 or renaming the file.
Copy-paste errors that introduce invisible or special Unicode characters.
Backslashes (\) used instead of forward slashes (/), which is a common mistake on Windows systems.
Unencoded query-like characters placed in the path portion of the URL.

This matters because browsers may interpret malformed URLs inconsistently. A URL that works in one browser might fail in another. Additionally, invalid URLs can break resource loading, cause accessibility issues when assistive technologies try to process the document, and lead to unexpected behavior with proxies, CDNs, or other intermediaries that strictly parse URLs.

To fix the issue, inspect the href value reported in the error and either:

Remove the illegal character if it was included by mistake.
Percent-encode the character if it must be part of the URL (e.g., a space becomes %20, a pipe | becomes %7C).
Rename the referenced file or directory to avoid special characters altogether (the simplest and most reliable approach).

Examples

Incorrect: Space in the path

<link rel="stylesheet" href="styles/my styles.css">

The space character is not allowed in a URL path segment. The validator will flag this as an illegal character.

Fixed: Percent-encode the space

<link rel="stylesheet" href="styles/my%20styles.css">

Better fix: Rename the file to avoid spaces

<link rel="stylesheet" href="styles/my-styles.css">

Incorrect: Template placeholder left unresolved

<link rel="stylesheet" href="styles/{{theme}}/main.css">

Curly braces { and } are not valid in URL path segments. This commonly happens with server-side or client-side templating syntax that wasn’t processed before the HTML was served.

Fixed: Use a valid resolved path

<link rel="stylesheet" href="styles/dark/main.css">

Incorrect: Backslash used as path separator

<link rel="stylesheet" href="styles\main.css">

Backslashes are not valid URL characters. URLs always use forward slashes.

Fixed: Use forward slashes

<link rel="stylesheet" href="styles/main.css">

Incorrect: Pipe character in the URL

<link rel="stylesheet" href="styles/font|icon.css">

Fixed: Percent-encode the pipe character

<link rel="stylesheet" href="styles/font%7Cicon.css">

Full valid document example

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>My Webpage</title>
    <link rel="stylesheet" href="styles/main.css">
    <link rel="icon" href="images/favicon.ico">
  </head>
  <body>
    <h1>Welcome to my webpage!</h1>
    <p>Here is some content.</p>
  </body>
</html>

When in doubt, run your URL through a URL encoder or validator separately to confirm all characters are legal. As a general best practice, stick to lowercase letters, digits, hyphens, and forward slashes in your file and directory names—this avoids encoding issues entirely and makes your URLs clean and predictable.

Bad value “” for attribute “imagesizes” on element “link”: Must not be empty.

The imagesizes attribute is used exclusively on <link> elements that have rel="preload" and as="image". It works in tandem with the imagesrcset attribute to allow the browser to preload the most appropriate image from a set of candidates — mirroring how sizes and srcset work on an <img> element. When the browser encounters these attributes on a <link>, it can begin fetching the right image resource early, before it even parses the <img> tag in the document body.

When imagesizes is set to an empty string (""), the browser has no information about the intended display size of the image, which defeats the purpose of responsive image preloading. The browser cannot select the best candidate from imagesrcset without knowing how large the image will be rendered. An empty value is invalid per the HTML specification, which requires the attribute to contain a valid source size list (the same syntax used by the sizes attribute on <img>).

This matters for both performance and standards compliance. Responsive preloading is a performance optimization — an empty imagesizes undermines that by leaving the browser unable to make an informed choice. From a standards perspective, the validator correctly rejects the empty value because the attribute’s defined value space does not include the empty string.

How to fix it

Provide a valid sizes value that matches the sizes attribute on the corresponding <img> element in your page. This tells the browser how wide the image will be at various viewport widths.
Remove imagesizes entirely if you don’t need responsive preloading. If you’re preloading a single image (using href instead of imagesrcset), you don’t need imagesizes at all.

Examples

❌ Bad: empty imagesizes attribute

<link
  rel="preload"
  as="image"
  imagesrcset="hero-480.jpg 480w, hero-800.jpg 800w, hero-1200.jpg 1200w"
  imagesizes="">

The empty imagesizes="" triggers the validation error and prevents the browser from selecting the correct image candidate.

✅ Fixed: providing a valid sizes value

<link
  rel="preload"
  as="image"
  imagesrcset="hero-480.jpg 480w, hero-800.jpg 800w, hero-1200.jpg 1200w"
  imagesizes="(max-width: 600px) 480px, (max-width: 1000px) 800px, 1200px">

The imagesizes value uses the same syntax as the sizes attribute on <img>. It provides media conditions paired with lengths, with a fallback length at the end. This value should match the sizes attribute on the corresponding <img> element in your markup.

✅ Fixed: simple full-width image

<link
  rel="preload"
  as="image"
  imagesrcset="banner-640.jpg 640w, banner-1280.jpg 1280w"
  imagesizes="100vw">

If the image spans the full viewport width, 100vw is a straightforward and valid value.

✅ Fixed: removing the attribute when not needed

<link rel="preload" as="image" href="logo.png">

If you’re preloading a single, non-responsive image, omit both imagesrcset and imagesizes and use the href attribute instead. The imagesizes attribute is only meaningful when paired with imagesrcset.

Bad value “” for attribute “imagesrcset” on element “link”: Must contain one or more image candidate strings.

The imagesrcset attribute is used exclusively on <link> elements that have rel="preload" and as="image". It mirrors the srcset attribute of the <img> element, allowing the browser to preload the most appropriate image resource based on the current viewport and display conditions. When the validator encounters imagesrcset="" (an empty value), it reports this error because an empty string is not a valid source set — it must contain at least one image candidate string.

Each image candidate string in the imagesrcset value consists of a URL followed by an optional width descriptor (e.g., 480w) or pixel density descriptor (e.g., 2x). Multiple candidates are separated by commas. This is the same syntax used by the srcset attribute on <img> elements.

This issue typically arises when a CMS, static site generator, or templating engine outputs the imagesrcset attribute with an empty value — for example, when a responsive image field has no data. Browsers may ignore the malformed attribute, but it results in invalid HTML, can cause unexpected preloading behavior, and signals that the page’s resource hints are misconfigured. Fixing it ensures standards compliance and that the browser’s preload scanner works as intended.

How to fix it

Provide a valid source set — populate imagesrcset with one or more image candidate strings.
Remove the attribute — if you don’t have multiple image sources to preload, remove imagesrcset (and imagesizes) from the <link> element entirely. You can still preload a single image using just the href attribute.
Conditionally render — if your templating system might produce an empty value, add logic to omit the attribute when no responsive sources are available.

When using imagesrcset, you should also include the imagesizes attribute (mirroring the sizes attribute on <img>) so the browser can select the correct candidate based on layout information.

Examples

❌ Empty imagesrcset triggers the error

<link rel="preload" as="image" href="hero.jpg" imagesrcset="" imagesizes="">

The empty imagesrcset value is invalid and produces the W3C validation error.

✅ Valid imagesrcset with width descriptors

<link
  rel="preload"
  as="image"
  href="hero-800.jpg"
  imagesrcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1200.jpg 1200w"
  imagesizes="(max-width: 600px) 400px, (max-width: 1000px) 800px, 1200px">

This tells the browser to preload the most appropriate image based on the viewport width, matching the responsive behavior of the corresponding <img> element on the page.

✅ Valid imagesrcset with pixel density descriptors

<link
  rel="preload"
  as="image"
  href="logo.png"
  imagesrcset="logo.png 1x, logo@2x.png 2x">

This preloads the correct logo variant based on the device’s pixel density.

✅ Removing the attribute when no responsive sources exist

<link rel="preload" as="image" href="hero.jpg">

If you only have a single image to preload, simply use href without imagesrcset. This is valid and avoids the error entirely.

✅ Conditional rendering in a template

If you’re using a templating language, conditionally include the attribute:

<!-- Pseudocode example -->

<link
  rel="preload"
  as="image"
  href="hero.jpg"
  {% if responsive_sources %}
    imagesrcset="{{ responsive_sources }}"
    imagesizes="{{ image_sizes }}"
  {% endif %}>

This prevents the attribute from being rendered with an empty value when no responsive image data is available.

Bad value “” for attribute “maxlength” on element “textarea”: The empty string is not a valid non-negative integer.

The maxlength attribute controls the maximum number of characters a user can type into a <textarea>. According to the HTML specification, its value must be a valid non-negative integer — that is, a string of one or more ASCII digits like 0, 100, or 5000. An empty string (""), whitespace, negative numbers, or non-numeric values are all invalid. When the browser encounters an invalid maxlength value, its behavior becomes unpredictable — some browsers may ignore the attribute, while others may silently enforce no limit, leading to inconsistent form behavior across platforms.

This issue frequently arises when a server-side template or JavaScript framework conditionally outputs the maxlength attribute but produces an empty value when no limit is configured. For example, a template like maxlength="{{ maxChars }}" will render maxlength="" if the maxChars variable is empty or undefined. The fix is to ensure the attribute is omitted entirely when no value is available, rather than rendering it with an empty string.

Omitting maxlength allows unlimited input. Setting it to 0 is technically valid but prevents the user from entering any characters at all, which is rarely useful. Choose a value that makes sense for your use case, such as the corresponding database column’s character limit.

Why this matters

Standards compliance: The HTML specification explicitly requires a valid non-negative integer. An empty string violates this rule and produces a validation error.
Consistent behavior: Browsers handle invalid attribute values differently. A valid value ensures the character limit works reliably across all browsers.
Accessibility: Screen readers and assistive technologies may announce the maximum character limit to users. An empty or invalid value could cause confusing announcements or be silently ignored.
Form reliability: If your application depends on maxlength for client-side input restrictions (e.g., to match a database column limit), an invalid value means the constraint isn’t enforced, potentially leading to data truncation or server errors.

How to fix it

Set a specific integer value if you need a character limit: maxlength="200".
Remove the attribute entirely if no limit is needed. An absent maxlength means unlimited input.
Fix your templates — if you’re using a server-side language or JavaScript framework, conditionally render the attribute so it’s omitted when no value is provided rather than output as empty.

Examples

❌ Invalid: empty maxlength value

The empty string is not a valid non-negative integer, so this triggers the validation error.

<label for="msg">Message</label>
<textarea id="msg" name="message" maxlength=""></textarea>

❌ Invalid: non-numeric maxlength value

Strings, decimals, and negative numbers are also invalid.

<label for="bio">Bio</label>
<textarea id="bio" name="bio" maxlength="none"></textarea>

<label for="notes">Notes</label>
<textarea id="notes" name="notes" maxlength="-1"></textarea>

✅ Fixed: specific integer value

Set maxlength to the desired character limit.

<label for="msg">Message (max 200 characters)</label>
<textarea id="msg" name="message" maxlength="200"></textarea>

✅ Fixed: attribute omitted entirely

If no character limit is needed, simply remove the attribute.

<label for="msg">Message</label>
<textarea id="msg" name="message"></textarea>

✅ Fixed: conditional rendering in a template

If you’re using a templating engine, conditionally include the attribute only when a value exists. The exact syntax depends on your framework — here’s a conceptual example:

<!-- Instead of always outputting the attribute: -->

<!-- <textarea maxlength="{{ maxChars }}"></textarea> -->


<!-- Only render it when maxChars has a value: -->

<!-- {% if maxChars %}<textarea maxlength="{{ maxChars }}"></textarea>{% endif %} -->


<label for="feedback">Feedback</label>
<textarea id="feedback" name="feedback" maxlength="500"></textarea>

Bad value “” for attribute “name” on element “a”: An ID must not be the empty string.

The name attribute on <a> elements was historically used to create named anchors — fragment targets that could be linked to with href="#anchorName". In modern HTML (the WHATWG living standard), the name attribute on <a> is considered obsolete for this purpose. The id attribute is now the standard way to create fragment targets, and it can be placed on any element, not just <a> tags.

Regardless of whether you use name or id, the value must be a non-empty string. The W3C validator enforces this rule because an empty identifier serves no functional purpose — it cannot be referenced by a fragment link, it cannot be targeted by JavaScript, and it creates invalid markup. Browsers may silently ignore it, but it pollutes the DOM and signals a likely mistake in the code.

Empty name attributes often appear in content migrated from older CMS platforms or WYSIWYG editors that inserted placeholder anchors like <a name=""></a>. They can also result from templating systems where a variable intended to populate the attribute resolved to an empty string.

Why this matters

Standards compliance: Both the WHATWG HTML living standard and the W3C HTML specification require that identifier-like attributes (id, name) must not be empty strings.
Accessibility: Screen readers and assistive technologies may attempt to process named anchors. Empty identifiers create noise without providing any navigational value.
Functionality: An empty name or id cannot be used as a fragment target, so the element is effectively useless as a link destination.

How to fix it

Remove the element entirely if the empty anchor serves no purpose — this is the most common fix.
Replace name with id and provide a meaningful, non-empty value if you need a fragment target.
Move the id to a nearby semantic element instead of using a standalone empty <a> tag. For example, place the id directly on a heading, section, or paragraph.
Ensure uniqueness — every id value in a document must be unique.

Examples

❌ Empty name attribute triggers the error

<a name=""></a>
<h2>Introduction</h2>
<p>Welcome to the guide.</p>

❌ Empty name generated by a template

<a name=""></a>
<p>This anchor was meant to be a target but the value is missing.</p>
<a href="#">Jump to section</a>

✅ Remove the empty anchor if it’s unnecessary

<h2>Introduction</h2>
<p>Welcome to the guide.</p>

✅ Use id on the target element directly

<h2 id="introduction">Introduction</h2>
<p>Welcome to the guide.</p>

<!-- Link to the section from elsewhere -->

<a href="#introduction">Go to Introduction</a>

✅ Use id on a standalone anchor if needed

If you need a precise anchor point that doesn’t correspond to an existing element, use an <a> tag with a valid, non-empty id:

<a id="section-start"></a>
<p>This paragraph follows the anchor point.</p>

<a href="#section-start">Jump to section start</a>

✅ Migrate legacy name to id

If your existing code uses the obsolete name attribute with a valid value, update it to use id instead:

<!-- Before (obsolete but was valid in HTML4) -->

<a name="contact"></a>

<!-- After (modern HTML) -->

<a id="contact"></a>

<!-- Even better: put the id on a semantic element -->

<h2 id="contact">Contact Us</h2>

Bad value “” for attribute “name” on element “input”: Must not be empty.

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>

Bad value for attribute “src” on element “iframe”: Illegal character in query: “[” is not allowed.

Square brackets ([ and ]) are reserved characters under RFC 3986, the standard that defines URI syntax. They are only permitted in the host component of a URL (specifically for IPv6 addresses) and are illegal elsewhere, including the query string. While most browsers are lenient and will load an <iframe> even when the src contains raw brackets, the W3C HTML Validator correctly flags this as an invalid URL value.

This pattern surfaces frequently when working with frameworks or APIs that use bracket notation to represent arrays or nested objects in query parameters — for example, filters[category]=news or items[0]=apple. These URLs work in a browser’s address bar because browsers silently fix malformed URLs, but the raw HTML itself is technically non-conforming.

Why it matters

Standards compliance: A valid HTML document requires all attribute values that expect URLs to contain properly encoded URIs. Raw brackets violate this requirement.
Interoperability: While mainstream browsers handle this gracefully, other HTML consumers — such as screen readers, web scrapers, embedded webview components, or email clients — may not be as forgiving.
Maintainability: Properly encoded URLs are unambiguous and reduce the risk of subtle parsing bugs, especially when URLs are constructed dynamically or passed through multiple layers of processing.

How to fix it

There are two main approaches:

Percent-encode the brackets. Replace every [ with %5B and every ] with %5D in the URL. The server will decode them back to brackets automatically, so functionality is preserved.
Use alternative parameter naming. If you control the server, switch to a naming convention that avoids brackets altogether, such as dot notation (filters.category) or underscores (filters_category). This keeps the URL valid without any encoding.

If you’re generating the URL dynamically in JavaScript, you can use encodeURIComponent() on individual parameter keys and values, or use the URL and URLSearchParams APIs, which handle encoding automatically.

Examples

Incorrect — raw brackets in the query string

<iframe src="https://example.com/embed?filters[category]=news&filters[tags]=web"></iframe>

The [ and ] characters in the query string make this an invalid URL value, triggering the validator error.

Fixed — percent-encoded brackets

<iframe src="https://example.com/embed?filters%5Bcategory%5D=news&filters%5Btags%5D=web"></iframe>

Replacing [ with %5B and ] with %5D produces a valid URL. The server receives the same parameter names after decoding.

Fixed — alternative parameter naming

<iframe src="https://example.com/embed?filters.category=news&filters.tags=web"></iframe>

If the server supports it, using dot notation eliminates the need for brackets entirely, keeping the URL clean and valid.

Generating encoded URLs in JavaScript

<iframe id="content-frame"></iframe>
<script>
  const url = new URL("https://example.com/embed");
  url.searchParams.set("filters[category]", "news");
  url.searchParams.set("filters[tags]", "web");
  document.getElementById("content-frame").src = url.href;
  // Result: https://example.com/embed?filters%5Bcategory%5D=news&filters%5Btags%5D=web
</script>

The URLSearchParams API automatically percent-encodes reserved characters, so you can write the parameter names naturally and let the browser produce a valid URL.

Bad value for attribute “src” on element “img”: Fragment is not allowed for data: URIs according to RFC 2397.

A data: URI embeds resource content directly in a URL rather than pointing to an external file. It follows the format data:[<mediatype>][;base64],<data>. RFC 2397, which governs this scheme, explicitly states that fragment identifiers (the # character followed by a fragment name) are not valid in data: URIs.

This issue most commonly arises when developers try to reference a specific element inside an embedded SVG — for example, a particular <symbol> or element with an id — by appending a fragment like #icon-name to a data: URI. While fragments work in standard URLs (e.g., icons.svg#home), the data: URI scheme simply doesn’t support them.

Why It Matters

Standards compliance: Browsers may handle invalid data: URIs inconsistently. Some may silently ignore the fragment, while others may fail to render the image entirely.
Portability: Code that relies on non-standard behavior in one browser may break in another or in a future update.
Accessibility and tooling: Validators, linters, and assistive technologies expect well-formed URIs. An invalid URI can cause unexpected issues down the chain.

How to Fix It

You have several options depending on your use case:

Remove the fragment from the data: URI. If the embedded content is a complete, self-contained image, it doesn’t need a fragment reference.
Inline the SVG directly into the HTML document. This lets you reference internal id values with standard fragment syntax using <use> elements.
Use an external file instead of a data: URI. Standard URLs like icons.svg#home fully support fragment identifiers.
Encode the full, standalone SVG into the data: URI so that it contains only the content you need, eliminating the need for a fragment reference.

Examples

❌ Incorrect: Fragment in a data: URI

<img
  src="data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg'%3E%3Csymbol id='icon'%3E%3Ccircle cx='10' cy='10' r='10'/%3E%3C/symbol%3E%3C/svg%3E#icon"
  alt="Icon">

The #icon fragment at the end of the data: URI violates RFC 2397 and triggers the validation error.

✅ Correct: Self-contained SVG in a data: URI (no fragment)

Embed only the content you need directly, without wrapping it in a <symbol> or referencing a fragment:

<img
  src="data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 20 20'%3E%3Ccircle cx='10' cy='10' r='10'/%3E%3C/svg%3E"
  alt="Icon">

✅ Correct: External SVG file with a fragment

Move the SVG to a separate file and reference the specific symbol using a standard URL fragment:

<img src="icons.svg#icon" alt="Icon">

✅ Correct: Inline SVG with <use> referencing an internal id

If you need to reference individual symbols from a sprite, inline the SVG and use fragment references within the same document:

<svg xmlns="http://www.w3.org/2000/svg" hidden>
  <symbol id="icon-home" viewBox="0 0 20 20">
    <path d="M10 2 L2 10 L4 10 L4 18 L16 18 L16 10 L18 10 Z"/>
  </symbol>
</svg>

<svg width="20" height="20" aria-hidden="true">
  <use href="#icon-home"></use>
</svg>

This approach gives you full control over individual icons without needing data: URIs at all, and it’s the most flexible option for icon systems.

Bad value for attribute “src” on element “img”: Illegal character in scheme data: “<” is not allowed.

The W3C HTML validator raises this error when the src attribute of an <img> element contains characters that are not permitted in a valid URI. The most common culprit is the < character, but other characters like >, {, }, |, \, ^, and backticks are also illegal in URIs according to RFC 3986.

This issue typically occurs in a few common scenarios:

Template syntax left unresolved: Server-side or client-side template tags (e.g., <%= imageUrl %>, {{ image.src }}) appear literally in the HTML output instead of being processed into actual URLs.
Copy-paste errors: HTML markup or angle brackets accidentally end up inside a src value.
Malformed dynamic URLs: JavaScript or server-side code incorrectly constructs a URL that includes raw HTML or special characters.

This matters because browsers may fail to load the image or interpret the URL unpredictably. Invalid URIs can also cause issues with screen readers and assistive technologies that try to resolve the src to provide context about the image. Keeping your markup standards-compliant ensures consistent behavior across all browsers and environments.

How to fix it

Check for unprocessed template tags. If you see template syntax like <%, {{, or similar in the rendered HTML, ensure your templating engine is running correctly and outputting the resolved URL.
Use valid, well-formed URLs. The src value should be a properly formatted absolute or relative URL.
Percent-encode special characters. If a special character is genuinely part of the URL (which is rare for <), encode it: < becomes %3C, > becomes %3E, and so on.
Inspect your generated HTML. View the page source in your browser to confirm the actual output, rather than relying on what your code looks like before processing.

Examples

Incorrect — template syntax in src

The template tag was not processed, leaving a < character in the src attribute:

<img src="<%= user.avatar %>" alt="User avatar">

Incorrect — HTML accidentally inside src

Angle brackets from stray markup ended up in the URL:

<img src="images/<thumbnail>/photo.jpg" alt="Photo">

Correct — a valid relative URL

<img src="images/photo.jpg" alt="Photo">

Correct — a valid absolute URL

<img src="https://example.com/images/photo.jpg" alt="Photo">

Correct — special characters percent-encoded

If the URL genuinely requires characters that are not allowed in a URI, percent-encode them:

<img src="https://example.com/search?q=a%3Cb" alt="Search result">

In this case, %3C represents the < character in the query string, making the URI valid.

Bad value “” for attribute “src” on element “script”: Must be non-empty.

The src attribute on a <script> element tells the browser where to fetch an external JavaScript file. According to the HTML specification, when the src attribute is present, its value must be a valid non-empty URL. An empty string does not qualify as a valid URL, so the validator flags it as an error.

This issue typically arises in a few common scenarios:

Templating or CMS placeholders — A template engine or content management system outputs an empty src when no script URL is configured.
Dynamic JavaScript — Client-side code is intended to set the src later, but the initial HTML ships with an empty value.
Copy-paste mistakes — The attribute was added in anticipation of a script file that was never specified.

Beyond failing validation, an empty src causes real problems. Most browsers interpret an empty src as a relative URL that resolves to the current page’s URL. This means the browser will make an additional HTTP request to re-fetch the current HTML document and attempt to parse it as JavaScript, wasting bandwidth, slowing down page load, and potentially generating console errors. It can also cause unexpected side effects in server logs and analytics.

How to Fix It

Choose the approach that matches your intent:

Provide a valid URL — If you need an external script, set src to the correct file path or full URL.
Use an inline script — If your JavaScript is written directly in the HTML, remove the src attribute entirely. Note that when src is present, browsers ignore any content between the opening and closing <script> tags.
Remove the element — If the script isn’t needed, remove the <script> element altogether.

Also keep in mind:

Ensure the file path is correct relative to the HTML file’s location.
If using an absolute URL, verify it is accessible and returns JavaScript content.
If a script should only be loaded conditionally, handle the condition in your server-side or build logic rather than outputting an empty src.

Examples

❌ Invalid: Empty src attribute

<script src=""></script>

This triggers the validation error because the src value is an empty string.

❌ Invalid: Whitespace-only src attribute

<script src="  "></script>

A value containing only whitespace is also not a valid URL and will produce the same error.

✅ Fixed: Valid external script

<script src="js/app.js"></script>

The src attribute contains a valid relative URL pointing to an actual JavaScript file.

✅ Fixed: Valid external script with a full URL

<script src="https://example.com/js/library.min.js"></script>

✅ Fixed: Inline script without src

If you want to write JavaScript directly in your HTML, omit the src attribute:

<script>
  console.log("This is an inline script.");
</script>

✅ Fixed: Conditionally omitting the element

If the script URL comes from a template variable that might be empty, handle it at the template level so the <script> element is only rendered when a URL is available. For example, in a templating language:

<!-- Pseudocode — only output the tag when the URL exists -->

<!-- {% if script_url %} -->

<script src="analytics.js"></script>
<!-- {% endif %} -->

This prevents the empty src from ever reaching the browser.

Bad value for attribute “srcset” on element “img”: Expected width descriptor but found X at Y. (When the “sizes” attribute is present, all image candidate strings must specify a width.)

The srcset attribute allows you to provide multiple image sources so the browser can choose the most appropriate one based on the user’s device and viewport. There are two distinct modes for srcset:

Width descriptor mode — Each candidate specifies the image’s intrinsic width using a w descriptor (e.g., 640w). This mode requires the sizes attribute so the browser knows how much space the image will occupy in the layout, enabling it to pick the best candidate.
Density descriptor mode — Each candidate specifies a pixel density using an x descriptor (e.g., 2x). This mode does not use the sizes attribute; the browser simply matches candidates to the device’s pixel density.

These two modes are mutually exclusive. You cannot mix w and x descriptors in the same srcset, and you cannot use x descriptors (or bare URLs with no descriptor) when sizes is present. The HTML specification is explicit about this: if sizes is specified, all image candidate strings must include a width descriptor.

Why this matters

Standards compliance: The WHATWG HTML Living Standard defines strict parsing rules for srcset. When sizes is present, the browser’s source selection algorithm expects width descriptors. Providing density descriptors or bare candidates in this context violates the spec and produces undefined behavior.
Broken image selection: Browsers rely on the sizes attribute to calculate which w-described image best fits the current layout width. If you provide x descriptors alongside sizes, the browser may ignore the srcset entirely or fall back to the src attribute, defeating the purpose of responsive images.
Accessibility and performance: Responsive images exist to serve appropriately sized files to different devices. An invalid srcset/sizes combination can result in oversized images being downloaded on small screens (wasting bandwidth) or undersized images on large screens (reducing visual quality).

How to fix it

You have two options:

Keep sizes and switch to width descriptors — Replace every x descriptor (or missing descriptor) in srcset with the actual intrinsic pixel width of each image file, expressed with a w suffix.
Remove sizes and keep density descriptors — If you only need to serve different resolutions for high-DPI screens at a fixed layout size, drop the sizes attribute and use x descriptors.

When using width descriptors, the value must match the image file’s actual intrinsic width in pixels. For example, if photo-640.jpg is 640 pixels wide, its descriptor should be 640w.

Examples

Invalid: sizes present with density descriptors

This triggers the error because 1x and 2x are density descriptors, but sizes requires width descriptors.

<img
  src="photo-640.jpg"
  srcset="photo-640.jpg 1x, photo-1280.jpg 2x"
  sizes="(max-width: 600px) 100vw, 600px"
  alt="A mountain landscape">

Invalid: sizes present with a bare candidate (no descriptor)

A candidate with no descriptor defaults to 1x, which is a density descriptor — still invalid when sizes is present.

<img
  src="photo-640.jpg"
  srcset="photo-640.jpg, photo-1280.jpg 2x"
  sizes="(max-width: 600px) 100vw, 600px"
  alt="A mountain landscape">

Fix: use width descriptors with sizes

Each candidate now specifies the intrinsic width of the image file. The browser uses the sizes value to determine which image to download.

<img
  src="photo-640.jpg"
  srcset="photo-320.jpg 320w, photo-640.jpg 640w, photo-1280.jpg 1280w"
  sizes="(max-width: 600px) 100vw, 600px"
  alt="A mountain landscape">

Alternative fix: remove sizes and use density descriptors

If you don’t need the browser to choose images based on layout width — for example, the image always renders at a fixed CSS size — drop sizes and use x descriptors.

<img
  src="photo-640.jpg"
  srcset="photo-640.jpg 1x, photo-1280.jpg 2x"
  alt="A mountain landscape">

Using width descriptors with source inside picture

The same rule applies to source elements inside a picture. If sizes is present, every candidate must use a w descriptor.

<picture>
  <source
    srcset="hero-480.webp 480w, hero-960.webp 960w, hero-1920.webp 1920w"
    sizes="(max-width: 768px) 100vw, 50vw"
    type="image/webp">
  <img
    src="hero-960.jpg"
    srcset="hero-480.jpg 480w, hero-960.jpg 960w, hero-1920.jpg 1920w"
    sizes="(max-width: 768px) 100vw, 50vw"
    alt="A hero banner image">
</picture>

Ready to validate your sites?
Start your free trial today.

Pro Trial Free Trial