Guias HTML para valor inválido

The type attribute on an anchor (<a>) element is an advisory hint that tells the browser what kind of content to expect at the link destination. According to the WHATWG HTML specification, when present, this attribute must contain a valid MIME type string. An empty string ("") is not a valid MIME type, so the W3C validator flags it as an error.

This issue commonly appears when a CMS, templating engine, or JavaScript framework generates the type attribute dynamically but produces an empty value when no MIME type is available. It can also happen when developers add the attribute as a placeholder intending to fill it in later.

Why this matters

While browsers generally handle an empty type attribute gracefully by ignoring it, there are good reasons to fix this:

• Standards compliance — An empty string violates the HTML specification’s requirement for a valid MIME type, making your document invalid.
• Accessibility — Assistive technologies may use the type attribute to communicate the linked resource’s format to users. An empty value provides no useful information and could lead to unexpected behavior in some screen readers.
• Predictable behavior — Browsers are allowed to use the type hint to influence how they handle a link (e.g., suggesting a download or choosing a handler). An empty value makes the intent ambiguous.

How to fix it

You have two straightforward options:

1. Remove the type attribute — If you don’t need to specify the MIME type, simply omit the attribute. This is the preferred approach when the type is unknown or unnecessary.
2. Provide a valid MIME type — If you want to hint at the linked resource’s format, supply a proper MIME type string like application/pdf, text/html, image/png, application/zip, etc.

The type attribute is purely advisory — the browser does not enforce it or refuse to follow the link if the actual content type differs. So omitting it is always safe.

Examples

Incorrect — empty type attribute

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

This triggers the validation error because "" is not a valid MIME type.

Correct — attribute removed

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

Removing the type attribute entirely is the simplest fix and works perfectly when the MIME type hint isn’t needed.

Correct — valid MIME type provided

<a href="report.pdf" type="application/pdf">Download Report</a>

If you want to explicitly indicate the format of the linked resource, use a proper MIME type value.

Multiple links with correct type usage

<ul>
  <li><a href="slides.pptx" type="application/vnd.openxmlformats-officedocument.presentationml.presentation">Slides (PPTX)</a></li>
  <li><a href="data.csv" type="text/csv">Data (CSV)</a></li>
  <li><a href="https://example.com/about">About Us</a></li>
</ul>

In this example, the first two links include type attributes with valid MIME types to hint at the file format. The third link, pointing to a regular webpage, omits type entirely since it’s not needed.

Fixing dynamically generated attributes

If your template engine produces empty type attributes, add a conditional check:

<!-- Instead of always outputting type="" -->

<!-- Only include the attribute when a value exists -->

<a href="report.pdf" type="application/pdf">Download Report</a>

In template logic, ensure you only render the type attribute when a non-empty MIME type value is available. Otherwise, omit the attribute from the output altogether.

The WAI-ARIA specification defines a specific set of role values that assistive technologies like screen readers understand. These include roles such as button, checkbox, alert, dialog, img, navigation, banner, and many others. The value "icon" is not among them. When a browser or assistive technology encounters an unrecognized role, it cannot determine the element’s purpose, which defeats the goal of using ARIA in the first place.

This is primarily an accessibility problem. Screen readers rely on valid ARIA roles to communicate the nature of elements to users. An invalid role like "icon" is either ignored or causes unpredictable behavior, leaving users of assistive technologies without the context they need. It’s also a standards compliance issue — the W3C validator flags this because the HTML specification requires role values to match roles defined in the ARIA specification.

The fix depends on the purpose of the element:

• Decorative icons (that don’t convey information): Remove the role attribute entirely, or use aria-hidden="true" to explicitly hide the element from the accessibility tree.
• Meaningful icons (that convey information visually): Use role="img" along with an aria-label to provide a text alternative.
• Icons inside interactive elements: Hide the icon with aria-hidden="true" and ensure the parent interactive element has an accessible name through visible text or an aria-label.

Examples

❌ Invalid: Using the non-existent "icon" role

<span class="icon" role="icon"></span>

This triggers the validation error because "icon" is not a valid ARIA role.

✅ Fixed: Decorative icon with no role

If the icon is purely decorative and doesn’t convey any meaning (e.g., it’s next to text that already describes the action), simply remove the role attribute. Adding aria-hidden="true" ensures screen readers skip over it completely.

<span class="icon" aria-hidden="true"></span>

✅ Fixed: Meaningful icon using role="img"

If the icon conveys meaningful information that isn’t available through surrounding text, use role="img" and provide a descriptive aria-label:

<span class="icon-warning" role="img" aria-label="Warning"></span>

This tells assistive technologies that the element represents an image and gives it an accessible name of “Warning.”

✅ Fixed: Icon inside a button

When an icon is placed inside an interactive element like a button, hide the icon from the accessibility tree and let the button’s text or label provide the meaning:

<button>
  <span class="icon-save" aria-hidden="true"></span>
  Save
</button>

If the button has no visible text (an icon-only button), provide an aria-label on the button itself:

<button aria-label="Save">
  <span class="icon-save" aria-hidden="true"></span>
</button>

✅ Fixed: Icon using an <img> element instead

If you’re using an actual image file for the icon, consider using a semantic <img> element, which has a built-in img role:

<img src="icon-alert.svg" alt="Alert" class="icon">

For decorative image icons, use an empty alt attribute:

<img src="icon-decorative.svg" alt="" class="icon">

In HTML, every element has a set of ARIA roles it is allowed to carry. The ul element implicitly has the list role, and the ARIA specification only permits certain roles to override it — specifically directory, group, listbox, menu, menubar, none, presentation, radiogroup, tablist, toolbar, and tree. The navigation role is not among them.

The navigation role is a landmark role, meaning it identifies a major section of the page dedicated to navigational links. HTML5 introduced the nav element specifically for this purpose, and it carries the navigation role implicitly — no role attribute needed. When you place role="navigation" on a ul, you’re conflicting with the element’s semantics. A ul represents a list of items, not a navigational landmark. Assistive technologies like screen readers rely on correct role assignments to help users understand page structure and navigate efficiently. An incorrect role can confuse users by misrepresenting what the element actually is.

Beyond accessibility concerns, this is a standards compliance issue. The W3C validator enforces the rules defined in the ARIA in HTML specification, which maps each HTML element to its allowed roles. Violating these rules means your markup is invalid and may behave unpredictably across different browsers and assistive technologies.

The fix is straightforward: use a nav element as the wrapper for your navigation list. This gives you the navigation landmark semantics automatically, while the ul retains its proper list role. Both elements work together — the nav tells assistive technologies “this is a navigation section,” and the ul tells them “here is a list of links.”

Examples

❌ Incorrect: navigation role on a ul

This triggers the validation error because navigation is not an allowed role for ul.

<ul role="navigation">
  <li><a href="/">Home</a></li>
  <li><a href="/about">About</a></li>
  <li><a href="/contact">Contact</a></li>
</ul>

✅ Correct: wrapping the ul in a nav element

The nav element provides the navigation landmark implicitly. No role attribute is needed.

<nav>
  <ul>
    <li><a href="/">Home</a></li>
    <li><a href="/about">About</a></li>
    <li><a href="/contact">Contact</a></li>
  </ul>
</nav>

✅ Correct: labeling multiple navigation landmarks

When a page has more than one nav element, use aria-label to distinguish them for screen reader users.

<nav aria-label="Main">
  <ul>
    <li><a href="/">Home</a></li>
    <li><a href="/about">About</a></li>
    <li><a href="/contact">Contact</a></li>
  </ul>
</nav>

<nav aria-label="Footer">
  <ul>
    <li><a href="/privacy">Privacy Policy</a></li>
    <li><a href="/terms">Terms of Service</a></li>
  </ul>
</nav>

✅ Correct: using an allowed role on ul

If you need the ul to behave as something other than a plain list — for example, a menu in a web application — use one of its permitted roles.

<ul role="menubar">
  <li role="menuitem"><a href="/">Home</a></li>
  <li role="menuitem"><a href="/about">About</a></li>
  <li role="menuitem"><a href="/contact">Contact</a></li>
</ul>

Note that menu and menubar roles are meant for application-style menus with keyboard interaction, not for simple site navigation. For standard website navigation, the nav wrapper approach is almost always the right choice.

The HTML specification defines a specific list of allowed ARIA roles for each element. For the <img> element, role="none" is permitted but role="presentation" is not listed as a valid value. This distinction exists even though the WAI-ARIA 1.1 specification treats none and presentation as synonymous — role="none" was introduced as an alias specifically because the word “presentation” was often misunderstood by authors. The HTML spec adopted none as the canonical value for <img>.

Why this matters

Standards compliance: Using a role value not permitted by the HTML specification for a given element produces a validation error. Keeping your HTML valid ensures predictable behavior across browsers and assistive technologies.

Accessibility: The intended purpose of role="presentation" or role="none" is to tell assistive technologies that an element is purely decorative and carries no semantic meaning. However, for images, the established and most reliable way to achieve this is simply providing an empty alt attribute (alt=""). Screen readers already know to skip images with alt="", so adding a role is usually unnecessary.

Clarity of intent: Using alt="" clearly communicates to both browsers and developers that the image is decorative. If the image actually conveys information, it should have a meaningful alt value and no presentation-related role at all.

How to fix it

1. If the image is decorative: Remove the role attribute entirely and ensure the image has alt="". This is the simplest and most widely supported approach.
2. If you need an explicit ARIA role: Replace role="presentation" with role="none" and keep alt="".
3. If the image conveys meaning: Remove the role and provide a descriptive alt attribute that explains what the image communicates.

Examples

❌ Bad: using role="presentation" on an <img>

<img src="divider.png" alt="" role="presentation">

This triggers the validation error because presentation is not an allowed role value for <img> in the HTML specification.

✅ Fixed: decorative image with empty alt (preferred)

<img src="divider.png" alt="">

The empty alt attribute is sufficient to tell assistive technologies the image is decorative. No role is needed.

✅ Fixed: decorative image with role="none"

<img src="divider.png" alt="" role="none">

If you explicitly need an ARIA role, role="none" is the valid value for <img>. The empty alt should still be included.

✅ Fixed: meaningful image with descriptive alt

<img src="quarterly-sales.png" alt="Bar chart showing quarterly sales increasing from $2M to $5M in 2024">

If the image communicates information, provide a descriptive alt and do not use a presentation or none role — doing so would hide the image’s meaning from assistive technology users.

❌ Bad: meaningful image incorrectly hidden

<img src="quarterly-sales.png" alt="Sales chart" role="presentation">

This is both invalid HTML (wrong role value for <img>) and an accessibility problem — the role would attempt to hide a meaningful image from screen readers.

The role attribute exposes an element’s purpose to assistive technologies. ARIA defines a fixed set of role values; sidebar is not among them, so validators report a bad value. Sidebars typically contain related or ancillary content, which maps to the complementary landmark role. In HTML, the <aside> element already represents this concept and implicitly maps to the complementary role.

Leaving an invalid role harms accessibility because screen readers may ignore the landmark or misreport it, and automated tools can’t build a reliable landmarks map. Standards compliance also matters for consistent behavior across browsers and assistive tech.

To fix it:

• Replace role="sidebar" with role="complementary" on a generic container; add an accessible name with aria-labelledby or aria-label when multiple complementary regions exist.
• Prefer <aside> for semantic HTML. It implicitly has the complementary role; add a label when there is more than one <aside>.
• Do not add role="complementary" to <aside> unless you need to override something; duplicate roles are unnecessary.
• If the area is site-wide navigation, use <nav> or role="navigation" instead; choose the role that best matches the intent.

Examples

Invalid: non-existent ARIA role

<div role="sidebar">
<!-- Related links and promos -->

</div>

Fixed: use the complementary role on a generic container

<div role="complementary" aria-labelledby="sidebar-title">
  <h2 id="sidebar-title">Related</h2>
  <ul>
    <li><a href="/guide-a">Guide A</a></li>
    <li><a href="/guide-b">Guide B</a></li>
  </ul>
</div>

Fixed: use semantic HTML with aside (implicit complementary)

<aside aria-labelledby="sidebar-title">
  <h2 id="sidebar-title">Related</h2>
  <ul>
    <li><a href="/guide-a">Guide A</a></li>
    <li><a href="/guide-b">Guide B</a></li>
  </ul>
</aside>

Multiple sidebars: ensure unique, descriptive labels

<aside aria-labelledby="filters-title">
  <h2 id="filters-title">Filter results</h2>
<!-- filter controls -->

</aside>

<aside aria-labelledby="related-title">
  <h2 id="related-title">Related articles</h2>
<!-- related links -->

</aside>

When it’s actually navigation: use the navigation landmark

<nav aria-label="Section navigation">
  <ul>
    <li><a href="#intro">Intro</a></li>
    <li><a href="#examples">Examples</a></li>
    <li><a href="#contact">Contact</a></li>
  </ul>
</nav>

Tips:

• Use <aside> for tangential content; it’s the simplest, standards-based approach.
• Provide an accessible name when more than one complementary region is present.
• Avoid inventing ARIA roles; stick to defined values like banner, main, navigation, complementary, contentinfo, and others.

ARIA defines a fixed set of role values that user agents and assistive technologies understand. sidebar is not in that set, so role="sidebar" fails conformance checking and gives unreliable signals to screen readers. Using a valid role or the correct HTML element improves accessibility, ensures consistent behavior across browsers and AT, and keeps your markup standards‑compliant.

Sidebars typically contain tangential or ancillary content (e.g., related links, promos, author info). The ARIA role that matches that meaning is complementary. In HTML, the semantic element for the same concept is aside, which by default maps to the complementary landmark in accessibility APIs. Prefer native semantics first: use <aside> when possible. Only add role="complementary" when you can’t change the element type or when you need an explicit landmark for non-semantic containers.

How to fix:

• If the element is a sidebar: change <div role="sidebar"> to <aside> (preferred), or to <div role="complementary">.
• Ensure each page has at most one primary main region and that complementary regions are not essential to understanding the main content.
• Provide an accessible name for the complementary region when multiple exist, using aria-label or aria-labelledby, to help users navigate landmarks.

Examples

Triggers the validator error

<div role="sidebar">
<!-- Sidebar content -->

</div>

Fixed: use the semantic element (preferred)

<aside aria-label="Related articles">
<!-- Sidebar content -->

</aside>

Fixed: keep the container, apply a valid role

<div role="complementary" aria-label="Related articles">
<!-- Sidebar content -->

</div>

Full document example with two sidebars (each labeled)

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>Sidebar Landmarks Example</title>
  </head>
  <body>
    <header>
      <h1>News Today</h1>
    </header>

    <main id="main">
      <article>
        <h2>Main Story</h2>
        <p>...</p>
      </article>
    </main>

    <aside aria-label="Trending topics">
      <ul>
        <li>Science</li>
        <li>Politics</li>
        <li>Sports</li>
      </ul>
    </aside>

    <div role="complementary" aria-labelledby="sponsor-title">
      <h2 id="sponsor-title">Sponsored</h2>
      <p>Ad content</p>
    </div>

    <footer>
      <p>&copy; 2026</p>
    </footer>
  </body>
</html>

Notes:

• Do not invent ARIA roles (e.g., sidebar, hero, footer-nav). Use defined roles like complementary, navigation, banner, contentinfo, and main.
• Prefer native HTML elements (aside, nav, header, footer, main) over generic containers with roles.
• Label multiple complementary landmarks to make them distinguishable in screen reader landmark lists.

The W3C validator raises this error because ARIA roles must be compatible with the element they are applied to. A <ul> element has an implicit ARIA role of list, and overriding it with tabpanel creates a conflict. The tabpanel role signals to assistive technologies that the element is a panel of content activated by a corresponding tab. When this role is placed on a <ul>, screen readers lose the semantic meaning of the list (item count, list navigation, etc.) while also misrepresenting the element’s function in the tab interface.

This matters for several reasons:

• Accessibility: Screen reader users rely on correct roles to navigate and understand page structure. A <ul> marked as tabpanel confuses both its list semantics and its role in the tab interface.
• Standards compliance: The ARIA in HTML specification defines which roles are allowed on which elements. The tabpanel role is not permitted on <ul>.
• Browser behavior: Browsers may handle conflicting roles inconsistently, leading to unpredictable behavior across assistive technologies.

The fix is straightforward: wrap the <ul> inside a proper container element (like a <div> or <section>) and apply the tabpanel role to that container instead.

Examples

Incorrect: tabpanel role on a <ul>

This triggers the validation error because tabpanel is not a valid role for <ul>:

<div role="tablist" aria-label="Recipe categories">
  <button role="tab" aria-controls="panel-1" aria-selected="true" id="tab-1">Appetizers</button>
  <button role="tab" aria-controls="panel-2" aria-selected="false" id="tab-2">Desserts</button>
</div>

<ul role="tabpanel" id="panel-1" aria-labelledby="tab-1">
  <li>Bruschetta</li>
  <li>Spring rolls</li>
</ul>

<ul role="tabpanel" id="panel-2" aria-labelledby="tab-2" hidden>
  <li>Tiramisu</li>
  <li>Cheesecake</li>
</ul>

Correct: tabpanel role on a container wrapping the <ul>

Move the tabpanel role to a <div> and nest the <ul> inside it. This preserves both the tab panel semantics and the list semantics:

<div role="tablist" aria-label="Recipe categories">
  <button role="tab" aria-controls="panel-1" aria-selected="true" id="tab-1">Appetizers</button>
  <button role="tab" aria-controls="panel-2" aria-selected="false" id="tab-2">Desserts</button>
</div>

<div role="tabpanel" id="panel-1" aria-labelledby="tab-1">
  <ul>
    <li>Bruschetta</li>
    <li>Spring rolls</li>
  </ul>
</div>

<div role="tabpanel" id="panel-2" aria-labelledby="tab-2" hidden>
  <ul>
    <li>Tiramisu</li>
    <li>Cheesecake</li>
  </ul>
</div>

Correct: Using <section> as the tab panel

A <section> element also works well as a tab panel container, especially when the panel content is more complex:

<div role="tablist" aria-label="Project info">
  <button role="tab" aria-controls="tasks-panel" aria-selected="true" id="tasks-tab">Tasks</button>
  <button role="tab" aria-controls="notes-panel" aria-selected="false" id="notes-tab">Notes</button>
</div>

<section role="tabpanel" id="tasks-panel" aria-labelledby="tasks-tab">
  <h2>Current tasks</h2>
  <ul>
    <li>Review pull requests</li>
    <li>Update documentation</li>
  </ul>
</section>

<section role="tabpanel" id="notes-panel" aria-labelledby="notes-tab" hidden>
  <h2>Meeting notes</h2>
  <p>Discussed project timeline and milestones.</p>
</section>

In a properly structured tabbed interface:

• The tablist role goes on the container that holds the tab buttons.
• Each tab trigger gets role="tab" with aria-controls pointing to its panel’s id.
• Each content panel gets role="tabpanel" on a generic container like <div> or <section>, with aria-labelledby referencing the corresponding tab’s id.
• List elements like <ul> and <ol> should remain inside the panel as regular content, retaining their native list semantics.

The aria-hidden attribute controls whether an element and its descendants are exposed to assistive technologies such as screen readers. When set to true, the element is hidden from the accessibility tree; when set to false, it remains visible. According to the WAI-ARIA specification, the only valid values for this attribute are the literal strings true and false. Any other value — including "true" with embedded quotation marks — is invalid.

When the validator reports a bad value like "true" (with the quotation marks as part of the value), it means the actual attribute value contains the characters "true" rather than just true. HTML attributes already use outer quotes as delimiters, so any quotes inside the value become part of the value itself. The browser or assistive technology may not recognize "true" as a valid ARIA state, which can lead to the element being incorrectly exposed to or hidden from screen readers, breaking the intended accessibility behavior.

This issue commonly arises in a few scenarios:

• Copy-pasting from formatted text where “smart quotes” or extra quoting gets included.
• Templating engines or frameworks that double-escape or double-quote attribute values (e.g., aria-hidden="{{value}}" where {{value}} already outputs "true").
• JavaScript that sets the attribute with extra quotes, such as element.setAttribute("aria-hidden", '"true"').

To fix the issue, ensure the attribute value contains only the bare string true or false with no extra quotation marks, HTML entities, or escaped characters inside it.

Examples

Incorrect — extra quotes embedded in the value

<div aria-hidden='"true"'>
  This content should be hidden from assistive tech
</div>

The rendered attribute value is literally "true" (five characters including the quotes), which is not a recognized ARIA value.

Incorrect — HTML entities producing extra quotes

<div aria-hidden="&quot;true&quot;">
  This content should be hidden from assistive tech
</div>

The &quot; entities resolve to quotation mark characters, producing the same invalid value of "true".

Correct — simple true value

<div aria-hidden="true">
  This content is hidden from assistive tech
</div>

Correct — simple false value

<div aria-hidden="false">
  This content is visible to assistive tech
</div>

Fixing the issue in JavaScript

If you’re setting the attribute dynamically, make sure you aren’t wrapping the value in extra quotes:

<div id="modal">Modal content</div>
<script>
  // Incorrect:
  // document.getElementById("modal").setAttribute("aria-hidden", '"true"');

  // Correct:
  document.getElementById("modal").setAttribute("aria-hidden", "true");
</script>

Fixing the issue in templating engines

If a template variable already outputs a quoted string, don’t add additional quotes around it. For example, in a templating system:

<!-- Incorrect: if myVar outputs "true" (with quotes) -->

<!-- <div aria-hidden="{{myVar}}"> -->


<!-- Correct: ensure myVar outputs just true (no quotes) -->

<div aria-hidden="true">
  Content
</div>

The key takeaway is straightforward: the outer quotes in aria-hidden="true" are HTML syntax — they delimit the attribute value. The value itself must be exactly true or false with nothing extra. If you’re generating HTML dynamically, inspect the rendered output in your browser’s developer tools to confirm the attribute value doesn’t contain stray quotation marks.

The wrap attribute on a <textarea> controls how text is wrapped when the form is submitted. The value "virtual" was used by some older browsers (notably early versions of Netscape and Internet Explorer) as a proprietary alternative to what the HTML Standard now calls "soft". Since "virtual" was never part of any formal HTML specification, the W3C validator correctly rejects it as an invalid value.

The HTML Standard defines only two valid values for wrap:

• soft (the default): The text is visually wrapped in the browser for display purposes, but no actual line break characters are inserted into the submitted form data. The server receives the text as continuous lines.
• hard: The browser inserts carriage return + line feed (CRLF) characters at the visual wrap points when the form is submitted, so the server receives the text with hard line breaks. When using wrap="hard", you must also specify the cols attribute so the browser knows where the wrap points are.

Since "virtual" was functionally identical to "soft", replacing it is straightforward. If you omit the wrap attribute altogether, the browser defaults to soft wrapping, which gives you the same behavior.

Why this matters

Using non-standard attribute values can lead to unpredictable behavior across browsers. While most modern browsers will likely fall back to soft wrapping when they encounter an unrecognized wrap value, this is not guaranteed by any specification. Sticking to valid values ensures consistent, cross-browser behavior and keeps your markup standards-compliant.

How to fix it

1. Replace wrap="virtual" with wrap="soft" for an explicit equivalent.
2. Remove the wrap attribute entirely if you want the default soft wrapping behavior.
3. Use wrap="hard" with a cols attribute if you actually need hard line breaks inserted on submission.

Examples

❌ Invalid: using the non-standard "virtual" value

<form>
  <label for="msg">Message</label>
  <textarea id="msg" name="msg" wrap="virtual"></textarea>
</form>

This triggers the error: Bad value “virtual” for attribute “wrap” on element “textarea”.

✅ Fixed: using wrap="soft" (equivalent to "virtual")

<form>
  <label for="msg">Message</label>
  <textarea id="msg" name="msg" wrap="soft"></textarea>
</form>

✅ Fixed: omitting wrap entirely (defaults to "soft")

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

Since "soft" is the default, removing the attribute produces identical behavior and cleaner markup.

✅ Fixed: using wrap="hard" with cols

If you need the submitted text to include line breaks at wrap points, use wrap="hard" and specify cols:

<form>
  <label for="msg">Message</label>
  <textarea id="msg" name="msg" wrap="hard" cols="60" rows="6"></textarea>
</form>

Note that cols is required when using wrap="hard". Omitting it will trigger a separate validation error.

Other legacy values to watch for

The value "virtual" isn’t the only non-standard wrap value from the early web. You may also encounter wrap="physical" (the legacy equivalent of "hard") or wrap="off" (which disabled wrapping). Neither is valid in modern HTML. Replace "physical" with "hard" (and add cols), and replace "off" by removing the attribute and using CSS (white-space: nowrap; or overflow-wrap: normal;) to control visual wrapping if needed.

The HTML specification defines boolean attributes as attributes whose presence indicates a true state and whose absence indicates false. According to the WHATWG HTML standard, a boolean attribute may only have three valid representations:

• The attribute name alone (e.g., async)
• The attribute with an empty string value (e.g., async="")
• The attribute with a value matching its own name, case-insensitively (e.g., async="async")

Any other value — such as async="true", async="1", async="yes", or async="false" — is invalid HTML and will trigger this validation error. This is a common misunderstanding because developers often assume boolean attributes work like boolean values in programming languages, where you’d assign true or false.

Why this matters

While most browsers are lenient and will treat any value of async as the true state (since the attribute is present regardless of its value), using invalid values creates several problems:

• Standards compliance: Invalid HTML may cause issues with strict parsers, validators, or tools that process your markup.
• Misleading intent: Writing async="false" does not disable async behavior — the attribute is still present, so the browser treats it as enabled. This can lead to confusing bugs where a script behaves asynchronously even though the developer intended otherwise.
• Maintainability: Other developers reading the code may misinterpret async="false" as actually disabling async loading.

To disable async behavior, you must remove the attribute entirely rather than setting it to "false".

How async works

For classic scripts with a src attribute, the async attribute causes the script to be fetched in parallel with HTML parsing and executed as soon as it’s available, without waiting for the document to finish parsing.

For module scripts (type="module"), the async attribute causes the module and all its dependencies to be fetched in parallel and executed as soon as they are ready, rather than waiting until the document has been parsed (which is the default deferred behavior for modules).

Examples

❌ Invalid: arbitrary values on async

<!-- Bad: "true" is not a valid boolean attribute value -->

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

<!-- Bad: "1" is not a valid boolean attribute value -->

<script async="1" src="analytics.js"></script>

<!-- Bad: "yes" is not a valid boolean attribute value -->

<script async="yes" src="tracker.js"></script>

<!-- Bad and misleading: this does NOT disable async -->

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

✅ Valid: correct boolean attribute usage

<!-- Preferred: attribute name alone -->

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

<!-- Also valid: empty string value -->

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

<!-- Also valid: value matching attribute name -->

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

<!-- Correct way to disable async: remove the attribute -->

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

✅ Valid: async with module scripts

<script async type="module" src="app.mjs"></script>

<script async type="module">
  import { init } from './utils.mjs';
  init();
</script>

This same rule applies to all boolean attributes in HTML, including defer, disabled, checked, required, hidden, and others. When in doubt, use the attribute name on its own with no value — it’s the cleanest and most widely recognized form.

The HTML specification defines the height and width attributes on the <embed> element as valid non-negative integers. This means the value must consist only of digits — for example, 650 — with no units, whitespace, or other characters appended. When you write height="650px", the validator encounters the letter “p” where it expects either another digit or the end of the value, and it raises this error.

This is a common mistake because CSS requires units (e.g., 650px), and it’s easy to assume HTML attributes work the same way. They don’t. In HTML, the height attribute implicitly means CSS pixels, so writing 650 already means “650 pixels.” Adding px is not only redundant — it makes the value invalid.

While most browsers are forgiving and will parse 650px correctly by stripping the unit, relying on this behavior is problematic. It violates the HTML specification, causes validation errors that can mask other real issues in your markup, and there’s no guarantee every browser or embedded content handler will be equally tolerant. Standards compliance ensures consistent rendering across browsers and assistive technologies.

How to fix it

You have two approaches:

1. Remove the unit from the HTML attribute. Change height="650px" to height="650". This is the simplest fix and keeps your sizing in the markup.

2. Move sizing to CSS. Remove the height attribute entirely and use a stylesheet or inline style attribute instead. This approach is more flexible because CSS supports units like %, em, vh, and more.

The same rule applies to the width attribute on <embed>, as well as height and width on elements like <img>, <video>, <iframe>, and <canvas> — all of which expect plain integers in HTML.

Examples

❌ Invalid: unit included in the HTML attribute

The px suffix causes the validator error because the attribute value must be digits only.

<embed src="file.pdf" type="application/pdf" width="800" height="650px">

Other invalid variations include:

<embed src="file.pdf" type="application/pdf" height="100%">
<embed src="file.pdf" type="application/pdf" height="40em">
<embed src="file.pdf" type="application/pdf" height="50vh">

✅ Fixed: plain integer without a unit

Remove the unit so the value is a valid non-negative integer.

<embed src="file.pdf" type="application/pdf" width="800" height="650">

✅ Fixed: sizing moved to CSS

If you need units other than pixels, or prefer to keep presentation in your stylesheets, use CSS instead of the HTML attribute.

<embed class="pdf-viewer" src="file.pdf" type="application/pdf">

.pdf-viewer {
  width: 800px;
  height: 650px;
}

✅ Fixed: inline style as an alternative

You can also use the style attribute directly if a separate stylesheet isn’t practical.

<embed src="file.pdf" type="application/pdf" style="width: 800px; height: 80vh;">

This is especially useful when you need viewport-relative or percentage-based sizing that HTML attributes can’t express.

The href attribute on an <a> element must contain a valid URL as defined by the WHATWG URL Standard. According to this standard, the forward slash (/) is the only recognized path segment delimiter. Backslashes (\) have no defined role in URL path syntax and are treated as invalid characters by the validator.

This issue most commonly occurs when developers copy file paths from Windows, which uses backslashes as its native path separator, directly into HTML. For example, copying a path like images\photos\sunset.jpg from Windows Explorer and pasting it into an href attribute will trigger this validation error.

While most modern browsers will silently normalize backslashes to forward slashes, relying on this behavior is problematic for several reasons:

• Standards compliance: Your HTML fails validation, which can mask other real issues in your code.
• Interoperability: Not all HTTP clients, crawlers, or tools normalize backslashes. Search engine bots, link checkers, or older browsers may fail to follow the link correctly.
• Portability: Code that depends on browser error correction is fragile and may break in unexpected environments, such as server-side rendering, email clients, or embedded web views.
• Accessibility: Screen readers and assistive technologies that parse href values may not handle backslashes consistently, potentially breaking navigation for users who rely on these tools.

To fix the issue, simply replace every backslash (\) with a forward slash (/) in any URL used in an href attribute. This applies not only to <a> elements but to any attribute that expects a URL, such as src, action, or data.

Examples

Incorrect: backslash used as path delimiter

<a href="docs\guide\intro.html">Introduction</a>

Correct: forward slash used as path delimiter

<a href="docs/guide/intro.html">Introduction</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: mixed slashes

Sometimes a URL contains a mix of forward and backslashes, which still triggers the error:

<a href="assets/images\photo.jpg">View photo</a>

Correct: all forward slashes

<a href="assets/images/photo.jpg">View photo</a>

Tips for avoiding this issue

• Search and replace: If you’re migrating content or working with paths generated on Windows, do a global find-and-replace of \ with / across your HTML files.
• Editor settings: Many code editors can highlight or auto-fix invalid URL characters. Enable linting tools or HTML validation plugins to catch this early.
• Build tools: If your build process generates links from file system paths, ensure it normalizes path separators to forward slashes before writing them into HTML output.
• URL encoding: If you genuinely need a literal backslash character within a URL (which is extremely rare), it must be percent-encoded as %5C. However, this is almost never the intended behavior when this validation error appears.

A valid URL consists of several parts: a scheme (like https), followed by ://, then the host, and optionally a path, query string, and fragment. The :// separator — a colon followed by two forward slashes — is a required part of the URL syntax for schemes like http and https. When one of these slashes is missing, the browser may fail to navigate to the intended destination, interpret the value as a relative path, or behave unpredictably across different environments.

This error commonly occurs due to simple typos, copy-paste mistakes, or programmatic URL construction where string concatenation goes wrong. While some browsers may attempt to correct malformed URLs, you should never rely on this behavior. A malformed href can break navigation entirely, cause security warnings, produce unexpected redirects, or confuse assistive technologies like screen readers that announce link destinations to users.

Beyond the missing-slash case, this error can also appear when other parts of the URL contain characters that aren’t valid without proper encoding — for instance, spaces or special characters that should be percent-encoded. Always ensure your URLs conform to the URL Standard.

How to Fix

1. Check the scheme separator: Verify that the protocol is followed by :// (colon and two slashes). For example, https:// not https:/ or https:.
2. Validate the full URL: Paste the URL into a browser’s address bar to confirm it resolves correctly.
3. Encode special characters: If the URL contains spaces or special characters, use proper percent-encoding (e.g., spaces become %20).
4. Review dynamically generated URLs: If URLs are built through string concatenation or template logic, double-check that all parts are joined correctly.

Examples

Incorrect: Missing a slash after the scheme

<a href="https:/example.com">Visit Example</a>

The validator reports this because https:/example.com has only one slash after the colon instead of the required two.

Incorrect: Missing both slashes

<a href="https:example.com">Visit Example</a>

This is also invalid — the colon must be followed by // for https URLs.

Correct: Properly formatted URL

<a href="https://example.com">Visit Example</a>

Correct: URL with a path

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

Correct: URL with encoded spaces

<a href="https://example.com/search?q=hello%20world">Search</a>

Incorrect: Unencoded space in URL

<a href="https://example.com/my page">My Page</a>

Spaces are not valid in URLs. Use %20 or + (in query strings) instead:

<a href="https://example.com/my%20page">My Page</a>

URLs follow a strict syntax defined by RFC 3986 and the URL Living Standard. Only a specific set of characters are allowed to appear unencoded in a URL. Curly braces ({ and }) are among the characters that fall outside this permitted set. When the W3C validator encounters a raw { or } in an href value, it reports the error: Bad value for attribute “href” on element “a”: Illegal character in fragment.

This issue commonly arises in a few scenarios:

• Server-side or client-side template placeholders left unresolved in the rendered HTML (e.g., {id}, {{slug}}).
• URLs copied from API documentation that use curly braces to indicate variable segments (e.g., /users/{userId}/posts).
• Malformed or auto-generated URLs where curly braces were included by mistake.

Why This Matters

Standards compliance: The HTML specification requires that href values conform to valid URL syntax. Curly braces violate this requirement, producing invalid HTML.

Browser inconsistency: While most modern browsers will attempt to handle URLs with illegal characters by silently encoding them, this behavior is not guaranteed across all browsers or versions. Relying on browser error correction can lead to unpredictable results.

Accessibility and interoperability: Assistive technologies, web crawlers, and other tools that parse HTML may not handle illegal URL characters gracefully. Invalid URLs can break link extraction, bookmarking, and sharing functionality.

Debugging difficulty: If curly braces appear in your rendered HTML, it often signals that a template variable was not properly resolved, which may point to a deeper bug in your application logic.

How to Fix It

The fix depends on why the curly braces are there:

1. If the curly braces are literal characters that should be part of the URL, replace them with their percent-encoded equivalents: { becomes %7B and } becomes %7D.

2. If the curly braces are template placeholders (e.g., {userId}), ensure your server-side or client-side code resolves them to actual values before the HTML is sent to the browser. The rendered HTML should never contain unresolved template variables.

3. If the curly braces were included by mistake, simply remove them.

Examples

Incorrect: Raw curly braces in href

<a href="https://example.com/api/users/{userId}/profile">View Profile</a>

This triggers the validation error because { and } are illegal URL characters.

Correct: Percent-encoded curly braces

If the curly braces are meant to be literal parts of the URL:

<a href="https://example.com/api/users/%7BuserId%7D/profile">View Profile</a>

Correct: Resolved template variable

If the curly braces were template placeholders, ensure your templating engine resolves them before rendering. The final HTML should look like:

<a href="https://example.com/api/users/42/profile">View Profile</a>

Incorrect: Curly braces in a fragment identifier

<a href="https://example.com/docs#section-{name}">Jump to Section</a>

Correct: Percent-encoded fragment

<a href="https://example.com/docs#section-%7Bname%7D">Jump to Section</a>

Incorrect: Curly braces in query parameters

<a href="https://example.com/search?filter={active}">Active Items</a>

Correct: Percent-encoded query parameter

<a href="https://example.com/search?filter=%7Bactive%7D">Active Items</a>

Using JavaScript for dynamic URLs

If you need to build URLs dynamically with values that might contain special characters, use encodeURIComponent() in JavaScript rather than inserting raw values into href attributes:

<a id="dynamic-link" href="https://example.com">Dynamic Link</a>
<script>
  var value = "{some-value}";
  var link = document.getElementById("dynamic-link");
  link.href = "https://example.com/path?param=" + encodeURIComponent(value);
</script>

This ensures that any special characters, including curly braces, are automatically percent-encoded in the resulting URL.

The URL standard (defined by WHATWG) specifies a strict set of characters allowed in each part of a URL. A space character is not among them. When the validator encounters a literal space in an href value, it reports the error “Illegal character in scheme data: space is not allowed.” This applies to spaces anywhere in the URL — the path, query string, fragment, or even after the scheme (e.g., https:).

While most modern browsers are forgiving and will attempt to fix malformed URLs by encoding spaces automatically, relying on this behavior is problematic for several reasons:

• Standards compliance: Invalid URLs violate the HTML specification, and markup that depends on browser error-correction is fragile and unpredictable.
• Accessibility: Assistive technologies, such as screen readers, may not handle malformed URLs the same way browsers do. This can result in broken links for users relying on these tools.
• Interoperability: Non-browser consumers of your HTML — search engine crawlers, link checkers, email clients, RSS readers, and APIs — may not perform the same auto-correction, leading to broken links or missed content.
• Copy-paste and sharing: When users copy a malformed URL from the source, the space can cause the link to break when pasted into other applications.

How to fix it

The fix depends on where the space appears:

1. In the path or fragment: Replace each space with %20. For example, /my file.html becomes /my%20file.html.
2. In the query string: You can use %20 or, if the value is part of application/x-www-form-urlencoded data, + is also acceptable for spaces within query parameter values. However, %20 is universally safe.
3. Programmatically: Use encodeURI() in JavaScript to encode a full URL (it preserves structural characters like /, ?, and #). Use encodeURIComponent() to encode individual query parameter values. On the server side, use your language’s equivalent URL-encoding function.

If you’re writing URLs by hand in HTML, simply find every space and replace it with %20. If URLs are generated dynamically (from a database, CMS, or user input), ensure your templating or server-side code encodes them before inserting into the markup.

Examples

Invalid — space in the path

<a href="https://example.com/docs/My Report.pdf">Download Report</a>

The literal space between “My” and “Report” triggers the validator error.

Fixed — space encoded as %20

<a href="https://example.com/docs/My%20Report.pdf">Download Report</a>

Invalid — space in a query parameter

<a href="https://example.com/search?q=hello world">Search</a>

Fixed — space encoded in the query string

<a href="https://example.com/search?q=hello%20world">Search</a>

Invalid — multiple spaces in different URL parts

<a href="https://example.com/my folder/page two.html?ref=some value#my section">Link</a>

Fixed — all spaces encoded

<a href="https://example.com/my%20folder/page%20two.html?ref=some%20value#my%20section">Link</a>

Encoding URLs with JavaScript

If you’re building URLs dynamically, use the built-in encoding functions rather than doing manual string replacement:

<script>
  // encodeURI encodes a full URL but preserves :, /, ?, #, etc.
  const url = encodeURI("https://example.com/docs/My Report.pdf");
  // Result: "https://example.com/docs/My%20Report.pdf"

  // encodeURIComponent encodes a single value (for query params)
  const query = encodeURIComponent("hello world");
  // Result: "hello%20world"
</script>

Note that encodeURI() is appropriate for encoding a complete URL, while encodeURIComponent() should be used for individual components like query parameter values — it encodes characters such as / and ? that have structural meaning in a URL.

In the structure of a URL, the @ symbol has a special meaning: it separates the userinfo component (username and password) from the host. A URL with credentials follows this pattern:

scheme://username:password@hostname/path

When the username or password itself contains an @ character — for example, an email address used as a username — the browser or URL parser may not be able to determine where the credentials end and the hostname begins. For instance, in http://user@name:pass@example.com, it’s unclear whether the host is name or example.com.

The URL Standard (maintained by WHATWG) requires that any @ appearing within the userinfo component be percent-encoded as %40. Percent-encoding replaces the literal character with a % followed by its hexadecimal ASCII code (40 for @). This removes the ambiguity and ensures all parsers interpret the URL identically.

While modern browsers may attempt to handle ambiguous URLs, the behavior is not guaranteed to be consistent across all user agents, link checkers, or HTTP clients. Properly encoding these characters ensures reliable behavior everywhere and keeps your HTML valid.

Note: Including credentials directly in URLs is generally discouraged for security reasons, as they may be exposed in browser history, server logs, and referrer headers. Consider alternative authentication methods when possible.

Examples

❌ Incorrect: unencoded @ in the username

<a href="http://user@name:password@example.com/path">Login</a>

Here, the parser cannot reliably distinguish user@name as the username from the @ that separates credentials from the host.

✅ Correct: percent-encoded @ in the username

<a href="http://user%40name:password@example.com/path">Login</a>

The @ within the username is encoded as %40, leaving only one literal @ to serve as the delimiter before the hostname.

❌ Incorrect: unencoded @ in the password

<a href="http://admin:p@ss@example.com/dashboard">Dashboard</a>

✅ Correct: percent-encoded @ in the password

<a href="http://admin:p%40ss@example.com/dashboard">Dashboard</a>

❌ Incorrect: email address used as username without encoding

<a href="ftp://joe@example.org:secret@ftp.example.com/files">Files</a>

✅ Correct: email address with @ percent-encoded

<a href="ftp://joe%40example.org:secret@ftp.example.com/files">Files</a>

To fix this issue, identify every @ character that appears before the final @ in the authority section of the URL and replace it with %40. The last @ in the authority is the actual delimiter and must remain as a literal character.

The <area> element defines a clickable region within an <map> element, which is used with images to create image maps. When an <area> element includes an href attribute, the browser treats it as a hyperlink. The value of href must be a valid URL, and http:// alone fails validation because the URL specification requires a host after the :// separator. An empty host is not permitted.

This matters for several reasons. Browsers may handle malformed URLs unpredictably — some might ignore the link, others might attempt navigation to a nonsensical destination, and others might throw a network error. Screen readers and other assistive technologies rely on valid href values to announce links correctly and provide meaningful navigation to users. From a standards compliance perspective, the WHATWG URL Standard explicitly rejects URLs with empty hosts, and the W3C validator flags this as an error.

This issue commonly appears when placeholder URLs are left in during development, when CMS tools generate incomplete markup, or when a URL value is dynamically constructed but the host portion ends up empty.

How to fix it

• If the area should link somewhere, replace http:// with the full, intended URL including the host (e.g., https://example.com/page).
• If the area is a temporary placeholder, use href="#" to create a valid no-op link, though be aware this will scroll the page to the top when clicked.
• If the area shouldn’t be interactive, remove the href attribute entirely. Without href, the <area> element is not a hyperlink and won’t be clickable.

Examples

Invalid: empty host in URL

The value http:// has no host, which triggers the validation error.

<img src="diagram.png" alt="Site map" usemap="#siteMap">
<map name="siteMap">
  <area shape="rect" coords="30,23,183,191" href="http://" alt="Home page">
</map>

Fixed: complete URL with a valid host

Providing a full URL with a host resolves the error.

<img src="diagram.png" alt="Site map" usemap="#siteMap">
<map name="siteMap">
  <area shape="rect" coords="30,23,183,191" href="https://example.com/" alt="Home page">
</map>

Fixed: placeholder link with #

If you need the area to remain clickable but don’t have a destination yet, href="#" is a valid placeholder.

<img src="diagram.png" alt="Site map" usemap="#siteMap">
<map name="siteMap">
  <area shape="rect" coords="30,23,183,191" href="#" alt="Home page">
</map>

Fixed: non-interactive area without href

If the area doesn’t need to be a link, simply omit the href attribute.

<img src="diagram.png" alt="Site map" usemap="#siteMap">
<map name="siteMap">
  <area shape="rect" coords="30,23,183,191" alt="Home page">
</map>

The <pattern> element lives inside <svg>, and SVG is an XML-based language. Unlike regular HTML — where id values follow relatively relaxed rules — SVG content must comply with XML 1.0 naming conventions. This means id values have stricter character and formatting requirements than you might be used to in plain HTML.

XML 1.0 Name Rules

An XML 1.0 name (used for id attributes in SVG) must follow these rules:

• First character must be a letter (A–Z, a–z) or an underscore (_).
• Subsequent characters can be letters, digits (0–9), hyphens (-), underscores (_), or periods (.).
• Spaces and special characters like !, @, #, $, %, (, ), etc. are not allowed anywhere in the name.

Common mistakes that trigger this error include starting an id with a digit (e.g., 1pattern), a hyphen (e.g., -myPattern), or a period (e.g., .dotPattern), or including characters like spaces or colons.

Why This Matters

• Standards compliance: SVG is parsed as XML in many contexts. An invalid XML name can cause parsing errors or unexpected behavior, especially when SVG is served with an XML MIME type or embedded in XHTML.
• Functionality: The <pattern> element’s id is typically referenced via url(#id) in fill or stroke attributes. An invalid id may cause the pattern reference to silently fail, leaving elements unfilled or invisible.
• Cross-browser consistency: While some browsers are lenient with invalid XML names, others are not. Using valid names ensures consistent rendering across all browsers and environments.

How to Fix

Rename the id value so it starts with a letter or underscore and contains only valid characters. If you reference this id elsewhere (e.g., in fill="url(#...)" or in CSS), update those references to match.

Examples

❌ Invalid: id starts with a digit

<svg width="200" height="200" xmlns="http://www.w3.org/2000/svg">
  <defs>
    <pattern id="1stPattern" width="10" height="10" patternUnits="userSpaceOnUse">
      <circle cx="5" cy="5" r="3" fill="blue" />
    </pattern>
  </defs>
  <rect width="200" height="200" fill="url(#1stPattern)" />
</svg>

❌ Invalid: id starts with a hyphen

<svg width="200" height="200" xmlns="http://www.w3.org/2000/svg">
  <defs>
    <pattern id="-stripe-bg" width="10" height="10" patternUnits="userSpaceOnUse">
      <rect width="5" height="10" fill="red" />
    </pattern>
  </defs>
  <rect width="200" height="200" fill="url(#-stripe-bg)" />
</svg>

❌ Invalid: id contains special characters

<svg width="200" height="200" xmlns="http://www.w3.org/2000/svg">
  <defs>
    <pattern id="my pattern!" width="10" height="10" patternUnits="userSpaceOnUse">
      <circle cx="5" cy="5" r="3" fill="green" />
    </pattern>
  </defs>
  <rect width="200" height="200" fill="url(#my pattern!)" />
</svg>

✅ Valid: id starts with a letter

<svg width="200" height="200" xmlns="http://www.w3.org/2000/svg">
  <defs>
    <pattern id="firstPattern" width="10" height="10" patternUnits="userSpaceOnUse">
      <circle cx="5" cy="5" r="3" fill="blue" />
    </pattern>
  </defs>
  <rect width="200" height="200" fill="url(#firstPattern)" />
</svg>

✅ Valid: id starts with an underscore

<svg width="200" height="200" xmlns="http://www.w3.org/2000/svg">
  <defs>
    <pattern id="_stripe-bg" width="10" height="10" patternUnits="userSpaceOnUse">
      <rect width="5" height="10" fill="red" />
    </pattern>
  </defs>
  <rect width="200" height="200" fill="url(#_stripe-bg)" />
</svg>

✅ Valid: Using letters, digits, hyphens, and underscores

<svg width="200" height="200" xmlns="http://www.w3.org/2000/svg">
  <defs>
    <pattern id="dot-grid_v2" width="10" height="10" patternUnits="userSpaceOnUse">
      <circle cx="5" cy="5" r="3" fill="green" />
    </pattern>
  </defs>
  <rect width="200" height="200" fill="url(#dot-grid_v2)" />
</svg>

Note that this same XML 1.0 naming rule applies to id attributes on all SVG elements — not just <pattern>. If you see similar errors on elements like <linearGradient>, <clipPath>, or <filter>, the same fix applies: ensure the id starts with a letter or underscore and uses only valid characters.

The media attribute on a <link> element specifies the conditions under which the linked resource should apply. It accepts either a simple media type or a full media query. When the validator reports “unrecognized media,” it means the value you provided doesn’t match any known media type or valid media query syntax.

Several older media types that were defined in earlier CSS specifications have been deprecated. Types like handheld, projection, tv, tty, aural, braille, and embossed are no longer recognized as valid. Modern CSS and HTML only support three media types: all, screen, and print. If you’re using a deprecated type, you should replace it with an appropriate modern media query that targets the device characteristics you need.

Beyond deprecated types, this error also occurs when a media query expression is malformed — for example, missing parentheses around a feature expression, using an unknown feature name, or having a typo in the value.

Why this matters

• Standards compliance: Using unrecognized media types means your HTML doesn’t conform to the current HTML and CSS specifications.
• Browser behavior: Browsers may ignore the entire <link> element or apply the resource unconditionally when they encounter an unrecognized media type, leading to unexpected results.
• Performance: The media attribute helps browsers prioritize resource loading. A valid media query allows the browser to defer loading stylesheets that don’t match the current context (e.g., print stylesheets), improving page load performance.

How to fix it

1. Replace deprecated media types with screen, print, or all, or use modern media queries that target specific device features.
2. Check for typos in your media type or query expression.
3. Validate your media query syntax — feature expressions must be wrapped in parentheses and use recognized feature names like max-width, orientation, or prefers-color-scheme.

Examples

Incorrect: using a deprecated media type

<link rel="stylesheet" href="mobile.css" media="handheld">

The handheld media type is deprecated and will trigger the validation error.

Incorrect: misspelled media type

<link rel="stylesheet" href="styles.css" media="screen">

Incorrect: malformed media query

<link rel="stylesheet" href="responsive.css" media="max-width: 768px">

The feature expression is missing its surrounding parentheses.

Correct: using valid media types

<link rel="stylesheet" href="general.css">
<link rel="stylesheet" href="print.css" media="print">
<link rel="stylesheet" href="screen.css" media="screen">

When no media attribute is specified, it defaults to all.

Correct: replacing deprecated types with modern media queries

Instead of media="handheld", use a media query that targets small screens or specific device capabilities:

<link rel="stylesheet" href="mobile.css" media="screen and (max-width: 768px)">

Correct: using complex media queries

<link rel="stylesheet" href="dark.css" media="(prefers-color-scheme: dark)">
<link rel="stylesheet" href="portrait.css" media="screen and (orientation: portrait)">
<link rel="stylesheet" href="large.css" media="screen and (min-width: 1200px)">

Valid media types reference

For anything more specific than these three types, use media feature expressions like (max-width: 600px), (hover: hover), or (prefers-reduced-motion: reduce) to target the exact device characteristics you need.

The multiple attribute tells the browser that the user can supply more than one value for a given input. For <input type="file">, it allows selecting multiple files at once. For <input type="email">, it allows entering a comma-separated list of email addresses. These are the only two input types that support the multiple attribute according to the HTML specification.

This validation error can appear for two distinct reasons, and sometimes both at once:

1. An invalid value is assigned to the boolean attribute. Boolean attributes in HTML follow strict rules. Valid syntaxes are: the attribute name alone (multiple), an empty string value (multiple=""), or the attribute’s own name as the value (multiple="multiple"). Any other value — including multiple="true", multiple="1", or multiple="yes" — is invalid.

2. The attribute is used on an unsupported input type. Placing multiple on input types like text, number, password, or url is not valid because those types don’t define behavior for this attribute. Browsers will simply ignore it, but it still constitutes invalid markup.

Why this matters

• Standards compliance: Invalid boolean attribute values violate the WHATWG HTML specification. While most browsers are forgiving and may still interpret multiple="true" as the attribute being present, relying on this behavior is fragile and non-standard.
• Accessibility: Assistive technologies rely on valid, well-structured markup. An invalid attribute value could lead to unpredictable behavior in screen readers or other tools.
• Maintainability: Using multiple on an unsupported input type suggests a misunderstanding of the element’s capabilities, which can confuse other developers and lead to bugs.

How to fix it

• Remove the value entirely: Change multiple="1" or multiple="true" to just multiple.
• Use a valid boolean syntax if a value is required: Some templating systems or XML-based contexts (like XHTML) require explicit attribute values. In those cases, use multiple="" or multiple="multiple".
• Ensure the input type supports multiple: Only type="email" and type="file" accept this attribute. If you need multi-value input for other types, consider alternative approaches like multiple separate inputs, a <select multiple> element, or a JavaScript-based solution.

Examples

Invalid: wrong value on a boolean attribute

<!-- Bad: "1" is not a valid boolean attribute value -->

<input type="file" name="attachments" multiple="1">

<!-- Bad: "true" is not a valid boolean attribute value -->

<input type="email" name="recipients" multiple="true">

Invalid: multiple on an unsupported input type

<!-- Bad: type="text" does not support the multiple attribute -->

<input type="text" name="tags" multiple>

<!-- Bad: type="number" does not support the multiple attribute -->

<input type="number" name="quantities" multiple>

Valid: correct usage of multiple

<!-- Correct: boolean attribute with no value -->

<input type="file" name="attachments" multiple>

<!-- Correct: empty string value (valid boolean syntax) -->

<input type="email" name="recipients" multiple="">

<!-- Correct: attribute name as value (valid for XHTML compatibility) -->

<input type="file" name="documents" multiple="multiple">

Full corrected document

<!DOCTYPE html>
<html lang="en">
<head>
  <title>Upload Form</title>
</head>
<body>
  <form action="/submit" method="post" enctype="multipart/form-data">
    <label for="recipients">Recipients:</label>
    <input type="email" id="recipients" name="recipients" multiple placeholder="a@example.com, b@example.com">

    <label for="files">Attachments:</label>
    <input type="file" id="files" name="files" multiple>

    <button type="submit">Send</button>
  </form>
</body>
</html>

In HTML, the name attribute on an <iframe> defines a browsing context name. This name can be referenced by other elements — for example, a link with target="my-frame" will open its URL inside the <iframe> whose name is "my-frame". The HTML specification reserves all browsing context names that start with an underscore for special keywords:

• _self — the current browsing context
• _blank — a new browsing context
• _parent — the parent browsing context
• _top — the topmost browsing context

Because the underscore prefix is reserved for these (and potentially future) keywords, the spec requires that any custom browsing context name must not begin with _. Setting name="_example" or name="_myFrame" on an <iframe> is invalid HTML, even though those exact strings aren’t currently defined keywords. Browsers may handle these inconsistently — some might ignore the name entirely, while others could treat it as one of the reserved keywords, leading to unexpected navigation behavior.

This matters for several reasons:

• Standards compliance: The WHATWG HTML living standard explicitly states that a valid browsing context name must not start with an underscore character.
• Predictable behavior: Using a reserved prefix can cause links or forms targeting that <iframe> to navigate in unintended ways (e.g., opening in a new tab instead of within the frame).
• Future-proofing: New underscore-prefixed keywords could be added to the spec, which might break pages that use custom names starting with _.

To fix the issue, simply rename the name attribute value so it doesn’t start with an underscore. You can use underscores elsewhere in the name — just not as the first character.

Examples

❌ Invalid: name starts with an underscore

<iframe src="https://example.com" name="_example"></iframe>

<a href="https://example.com/page" target="_example">Open in frame</a>

The name _example starts with an underscore, which makes it invalid. A browser might interpret _example unpredictably or ignore the name entirely when used as a target.

✅ Fixed: underscore removed from the start

<iframe src="https://example.com" name="example"></iframe>

<a href="https://example.com/page" target="example">Open in frame</a>

✅ Fixed: underscore used elsewhere in the name

<iframe src="https://example.com" name="my_example"></iframe>

<a href="https://example.com/page" target="my_example">Open in frame</a>

Underscores are perfectly fine as long as they aren’t the first character.

❌ Invalid: using a reserved keyword as a frame name

<iframe src="https://example.com" name="_blank"></iframe>

Using _blank as an <iframe> name is also invalid because it’s a reserved browsing context keyword. A link targeting _blank would open in a new window/tab rather than inside this <iframe>, which is almost certainly not what you intended.

✅ Fixed: descriptive name without underscore prefix

<iframe src="https://example.com" name="content-frame"></iframe>

<a href="https://example.com/page" target="content-frame">Open in frame</a>

How to fix

1. Find every <iframe> element whose name attribute starts with _.
2. Rename each one by removing the leading underscore or replacing it with a letter or other valid character.
3. Update any target attributes on <a>, <form>, or <base> elements that reference the old name so they match the new name.
4. Re-validate your HTML to confirm the issue is resolved.

Understanding Boolean Attributes in HTML

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

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

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

Why This Matters

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

About the novalidate Attribute

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

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

Examples

❌ Invalid: Arbitrary value on novalidate

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

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

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

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

✅ Valid: Attribute name alone (recommended)

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

✅ Valid: Empty string value

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

✅ Valid: Value matching the attribute name

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

✅ Valid: Removing the attribute to enable validation

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

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

✅ Using formnovalidate on a specific button

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

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

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

The ping attribute specifies a space-separated list of URLs that the browser should notify (via a small POST request) when a user follows a hyperlink. This is commonly used for click tracking and analytics. According to the HTML specification, every URL in the list must be a valid, non-empty URL that uses either the http or https scheme — no other schemes or relative paths are permitted.

This restriction exists for practical and security reasons. The ping mechanism is specifically designed for web-based tracking endpoints, so only web protocols make sense. Relative URLs are disallowed because the ping is sent as a separate request independent of normal navigation, and the specification requires absolute URLs to unambiguously identify the target server. Using invalid values won’t produce the intended tracking behavior and will cause the browser to silently ignore the ping attribute entirely.

From an accessibility and standards compliance standpoint, ensuring valid ping values means your analytics will work reliably in browsers that support the attribute. Note that browser support varies — some browsers (notably Firefox) disable ping by default or hide it behind a preference — so you should not rely on it as your sole tracking mechanism.

How to fix it

1. Replace relative URLs with absolute URLs. If you have a value like /track or track.php, prepend the full origin (e.g., https://example.com/track).
2. Remove non-HTTP schemes. Values like mailto:someone@example.com or ftp://example.com/log are not valid for ping.
3. Ensure each URL in the list is properly formatted. Multiple URLs must be separated by spaces (not commas or semicolons), and each one must be a complete http or https URL.

Examples

Incorrect: relative URL

<a href="https://example.com" ping="/track">Visit Example</a>

The value /track is a relative URL, which is not allowed in the ping attribute.

Incorrect: unsupported scheme

<a href="https://example.com" ping="ftp://example.com/log">Visit Example</a>

The ftp: scheme is not permitted — only http and https are valid.

Incorrect: comma-separated URLs

<a href="https://example.com" ping="https://example.com/track, https://analytics.example.com/log">Visit Example</a>

Multiple URLs must be space-separated, not comma-separated. The commas make each URL invalid.

Correct: single absolute URL

<a href="https://example.com" ping="https://example.com/track">Visit Example</a>

Correct: multiple space-separated absolute URLs

<a href="https://example.com" ping="https://example.com/track https://analytics.example.com/log">Visit Example</a>

Each URL is a fully qualified https URL, and they are separated by a single space. Both will receive a POST request when the link is clicked (in browsers that support the ping attribute).

The poster attribute specifies an image to display as a placeholder while the video is loading or before the user starts playback. Like all HTML attributes that accept URLs — such as src, href, and action — the value must conform to valid URI syntax as defined by RFC 3986. In this standard, a literal space character is not a legal character in any part of a URL. When the validator encounters a space in the poster attribute’s value, it flags it as an illegal character in the path segment.

While most modern browsers are forgiving and will attempt to resolve URLs containing raw spaces by internally encoding them, relying on this behavior is problematic for several reasons:

• Standards compliance: The HTML specification requires valid URLs. Raw spaces violate this requirement.
• Interoperability: Not all user agents, HTTP clients, or content delivery systems handle unencoded spaces the same way. Some may truncate the URL at the first space or fail to resolve the resource entirely.
• Portability: If your HTML is consumed by tools, scrapers, or APIs that strictly parse URLs, unencoded spaces can cause silent failures.
• Consistency: Keeping URLs properly encoded prevents subtle bugs when paths are constructed dynamically in server-side or client-side code.

The fix is straightforward. You have two options:

1. Percent-encode the spaces: Replace every space in the URL with %20. This preserves the original file and folder names on the server while producing a valid URL in your HTML.
2. Eliminate spaces from file and folder names: Use hyphens (-), underscores (_), or camelCase instead of spaces. This is generally considered best practice for web assets, as it avoids encoding issues across the board.

Note that this rule applies to the entire URL path, not just the filename. If any directory in the path contains a space, it must also be encoded or renamed. The same principle applies to other special characters that are reserved or disallowed in URLs, such as {, }, |, ^, and [.

Examples

Incorrect — space in the path

The folder name video images contains a space, which is illegal in a URL path segment.

<video controls poster="/img/video images/snapshot.png">
  <source src="/videos/sample.mp4" type="video/mp4">
</video>

Incorrect — space in the filename

The filename my poster.jpg also triggers the same error.

<video controls poster="/img/my poster.jpg">
  <source src="/videos/sample.mp4" type="video/mp4">
</video>

Fixed — percent-encoding the spaces

Each space is replaced with %20, producing a valid URL.

<video controls poster="/img/video%20images/snapshot.png">
  <source src="/videos/sample.mp4" type="video/mp4">
</video>

Fixed — removing spaces from the path

Renaming the folder to use a hyphen eliminates the need for encoding entirely.

<video controls poster="/img/video-images/snapshot.png">
  <source src="/videos/sample.mp4" type="video/mp4">
</video>

Fixed — removing spaces from the filename

<video controls poster="/img/my-poster.jpg">
  <source src="/videos/sample.mp4" type="video/mp4">
</video>

As a general best practice, avoid spaces in all file and folder names used on the web. Use hyphens or underscores instead. If you’re working with files you can’t rename — such as assets from a CMS or third-party system — always percent-encode spaces as %20 in your HTML. This applies not only to poster but to every attribute that takes a URL value, including src, href, action, data, and formaction.

The rel attribute defines the relationship between the current document and a linked resource. The HTML specification maintains a set of recognized keyword values for this attribute, and the allowed keywords vary depending on which element the attribute appears on. For example, stylesheet is valid on <link> but not on <a>, while nofollow is valid on <a> and <form> but not on <link>.

When the validator encounters a rel value that isn’t a recognized keyword, it checks whether the value is a valid absolute URL. This is because the HTML specification allows custom link types to be defined using absolute URLs as identifiers (similar to how XML namespaces work). If the value is neither a recognized keyword nor a valid absolute URL, the validator raises this error.

Common causes of this error include:

• Typos in standard keywords — for example, rel="styelsheet" or rel="no-follow" instead of the correct rel="stylesheet" or rel="nofollow".
• Using non-standard or invented values — such as rel="custom" or rel="external", which aren’t part of the HTML specification’s recognized set.
• Using relative URLs as custom link types — for example, rel="my-custom-type" instead of a full URL like rel="https://example.com/my-custom-type".

This matters because browsers and other user agents rely on recognized rel values to determine how to handle linked resources. An unrecognized value will simply be ignored, which could mean your stylesheet doesn’t load, your prefetch hint doesn’t work, or search engines don’t respect your intended link relationship. Using correct values ensures predictable behavior across all browsers and tools.

Examples

Incorrect: Misspelled keyword

<link rel="styleshet" href="main.css">

The validator reports that styleshet is not a recognized keyword and is not an absolute URL.

Correct: Fixed spelling

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

Incorrect: Non-standard keyword on an anchor

<a href="https://example.com" rel="external">Visit Example</a>

The value external is not a standard rel keyword in the HTML specification, so the validator flags it.

Correct: Using a recognized keyword

<a href="https://example.com" rel="noopener">Visit Example</a>

Incorrect: Relative URL as a custom link type

<link rel="my-custom-rel" href="data.json">

Correct: Absolute URL as a custom link type

If you genuinely need a custom relationship type, provide a full absolute URL:

<link rel="https://example.com/rels/my-custom-rel" href="data.json">

Correct: Common valid rel values

Here are some frequently used standard rel keywords with their appropriate elements:

<!-- Linking a stylesheet -->

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

<!-- Linking a favicon -->

<link rel="icon" href="favicon.ico">

<!-- Preloading a resource -->

<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>

<!-- Telling search engines not to follow a link -->

<a href="https://example.com" rel="nofollow">Sponsored link</a>

<!-- Opening a link safely in a new tab -->

<a href="https://example.com" target="_blank" rel="noopener noreferrer">External site</a>

Multiple rel values

You can specify multiple space-separated rel values. Each one must individually be either a recognized keyword or a valid absolute URL:

<!-- Correct: both values are recognized keywords -->

<a href="https://example.com" target="_blank" rel="noopener noreferrer">External</a>

<!-- Incorrect: "popup" is not a recognized keyword or absolute URL -->

<a href="https://example.com" target="_blank" rel="noopener popup">External</a>

To resolve this error, consult the MDN rel attribute reference for the full list of recognized keywords and which elements support them. If your value isn’t on the list, either replace it with the correct standard keyword or use a complete absolute URL to define your custom link type.