HTML Guides

An element with “role=tab” must be contained in, or owned by, an element with “role=tablist”.

The WAI-ARIA specification defines a strict ownership model for tab-related roles. An element with role="tab" controls the visibility of an associated role="tabpanel" element, and tabs are expected to be grouped within a tablist. This relationship is how assistive technologies like screen readers understand and communicate the tab interface pattern to users — for example, announcing "tab 2 of 4" when focus moves between tabs.

When a tab is not contained in or owned by a tablist, screen readers cannot determine how many tabs exist in the group, which tab is currently selected, or how to navigate between them. This fundamentally breaks the accessibility of the tab interface, making it confusing or unusable for people who rely on assistive technologies.

There are two ways to establish the required relationship:

Direct containment: Place the role="tab" elements as direct children of the role="tablist" element. This is the most common and straightforward approach.
Using aria-owns: If the DOM structure prevents direct nesting, add aria-owns to the tablist element with a space-separated list of id values referencing each tab. This tells assistive technologies that the tablist owns those tabs even though they aren't direct children in the DOM.

Examples

Incorrect: tab outside of a tablist

In this example, the role="tab" buttons are siblings of the tablist rather than children of it, which triggers the validation error.

<divclass="tabs">

<divrole="tablist"aria-label="Sample Tabs"></div>

<buttonrole="tab"aria-selected="true"aria-controls="panel-1"id="tab-1">

First Tab

</button>

<buttonrole="tab"aria-selected="false"aria-controls="panel-2"id="tab-2">

Second Tab

</button>

</div>

Correct: tabs as direct children of tablist

The simplest fix is to place the role="tab" elements directly inside the role="tablist" element.

<divclass="tabs">

<divrole="tablist"aria-label="Sample Tabs">

<buttonrole="tab"aria-selected="true"aria-controls="panel-1"id="tab-1"tabindex="0">

First Tab

</button>

<buttonrole="tab"aria-selected="false"aria-controls="panel-2"id="tab-2"tabindex="-1">

Second Tab

</button>

</div>

<divid="panel-1"role="tabpanel"tabindex="0"aria-labelledby="tab-1">

<p>Content for the first panel</p>

</div>

<divid="panel-2"role="tabpanel"tabindex="0"aria-labelledby="tab-2"hidden>

<p>Content for the second panel</p>

</div>

Correct: using aria-owns when DOM nesting isn't possible

If your layout or framework makes it difficult to nest the tabs directly inside the tablist, you can use aria-owns to establish the relationship programmatically.

<divclass="tabs">

<divrole="tablist"aria-label="Sample Tabs"aria-owns="tab-1 tab-2"></div>

<divclass="tab-wrapper">

<buttonrole="tab"aria-selected="true"aria-controls="panel-1"id="tab-1"tabindex="0">

First Tab

</button>

<buttonrole="tab"aria-selected="false"aria-controls="panel-2"id="tab-2"tabindex="-1">

Second Tab

</button>

</div>

<divid="panel-1"role="tabpanel"tabindex="0"aria-labelledby="tab-1">

<p>Content for the first panel</p>

</div>

<divid="panel-2"role="tabpanel"tabindex="0"aria-labelledby="tab-2"hidden>

<p>Content for the second panel</p>

</div>

Additional notes

Each role="tab" element should use aria-selected to indicate which tab is active ("true") and which are not ("false").
Use aria-controls on each tab to reference the id of its associated tabpanel.
Use aria-labelledby on each tabpanel to point back to its controlling tab.
Set tabindex="0" on the active tab and tabindex="-1" on inactive tabs to support keyboard navigation with arrow keys within the tablist.
Always include an aria-label or aria-labelledby on the tablist to give it an accessible name.

A “link” element with a “rel” attribute that contains the value “preload” must have an “as” attribute.

The preload value of the <link> element's rel attribute lets you declare fetch requests in the HTML <head>, telling the browser to start loading critical resources early in the page lifecycle—before the main rendering machinery kicks in. This can significantly improve performance by ensuring key assets are available sooner and are less likely to block rendering.

However, a preload hint is incomplete without the as attribute. The as attribute tells the browser what kind of resource is being fetched. This matters for several important reasons:

Request prioritization: Browsers assign different priorities to different resource types. A stylesheet is typically higher priority than an image. Without as, the browser cannot apply the correct priority, and the preloaded resource may be fetched with a low default priority, undermining the purpose of preloading.
Content Security Policy (CSP): CSP rules are applied based on resource type (e.g., script-src, style-src). Without knowing the type, the browser cannot enforce the appropriate policy.
Correct Accept header: The as value determines which Accept header the browser sends with the request. For example, an image request sends a different Accept header than a script request. An incorrect or missing header could lead to unexpected responses from the server.
Cache matching: When the resource is later requested by a <script>, <link rel="stylesheet">, or other element, the browser needs to match it against the preloaded resource in its cache. Without as, the browser may not recognize the preloaded resource and could fetch it again, resulting in a duplicate request—the opposite of what you intended.

The HTML specification explicitly requires the as attribute when rel="preload" is used, making this a conformance error.

Common `as` Values

The as attribute accepts a specific set of values. Here are the most commonly used ones:

Value	Resource Type
`script`	JavaScript files
`style`	CSS stylesheets
`font`	Web fonts
`image`	Images
`fetch`	Resources fetched via `fetch()` or `XMLHttpRequest`
`document`	HTML documents (for `<iframe>`)
`audio`	Audio files
`video`	Video files
`track`	WebVTT subtitle tracks
`worker`	Web workers or shared workers

Examples

Incorrect: Missing `as` attribute

This will trigger the validation error because the browser doesn't know what type of resource is being preloaded:

<linkrel="preload"href="/fonts/roboto.woff2">

<linkrel="preload"href="/js/app.js">

Correct: `as` attribute included

Adding the appropriate as value tells the browser exactly what kind of resource to expect:

<linkrel="preload"href="/fonts/roboto.woff2"as="font"type="font/woff2"crossorigin>

<linkrel="preload"href="/js/app.js"as="script">

<linkrel="preload"href="/css/main.css"as="style">

<linkrel="preload"href="/images/hero.webp"as="image">

Note on fonts and `crossorigin`

When preloading fonts, you must also include the crossorigin attribute, even if the font is hosted on the same origin. This is because font fetches are CORS requests by default. Without crossorigin, the preloaded font won't match the later font request and will be fetched twice:

<linkrel="preload"href="/fonts/roboto.woff2"as="font"type="font/woff2"crossorigin>

Full document example

<!DOCTYPE html>

<htmllang="en">

<head>

<metacharset="utf-8">

<title>Preload Example</title>

<linkrel="preload"href="/css/main.css"as="style">

<linkrel="preload"href="/js/app.js"as="script">

<linkrel="preload"href="/fonts/roboto.woff2"as="font"type="font/woff2"crossorigin>

<linkrel="stylesheet"href="/css/main.css">

</head>

<body>

<h1>Hello, world!</h1>

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

</body>

</html>

Choosing the correct as value is straightforward—just match it to how the resource will ultimately be used on the page. If you're preloading a stylesheet, use as="style"; if it's a script, use as="script", and so on.

An element with “role=columnheader” must be contained in, or owned by, an element with “role=row”.

The ARIA specification defines a strict ownership hierarchy for table-related roles. A columnheader represents a header cell for a column, analogous to a <th> element in native HTML. For assistive technologies like screen readers to correctly announce column headers and associate them with the data cells beneath them, the columnheader must exist within a row context. The required structure is:

An element with role="table", role="grid", or role="treegrid" serves as the container.
Inside it, elements with role="rowgroup" (optional) or role="row" organize the rows.
Each role="row" element contains one or more elements with role="columnheader", role="rowheader", or role="cell".

When a role="columnheader" element is placed directly inside a role="table" or role="grid" container — or any other element that is not role="row" — the validator raises this error. Without the row wrapper, screen readers cannot navigate the table structure properly. Users who rely on assistive technology may hear disjointed content or miss the column headers entirely, making the data table unusable.

The best practice, whenever feasible, is to use native HTML table elements (<table>, <thead>, <tr>, <th>, <td>). These carry implicit ARIA roles and establish the correct ownership relationships automatically, eliminating this entire category of errors. Only use ARIA table roles when you genuinely cannot use native table markup — for example, when building a custom grid widget with non-table elements for layout reasons.

Examples

Incorrect: `columnheader` not inside a `row`

In this example, the columnheader elements are direct children of the table container, with no role="row" wrapper:

<divrole="table"aria-label="Employees">

<divrole="columnheader">Name</div>

<divrole="columnheader">Department</div>

<divrole="row">

<divrole="cell">Alice</div>

<divrole="cell">Engineering</div>

</div>

Correct: `columnheader` inside a `row`

Wrapping the column headers in an element with role="row" fixes the issue:

<divrole="table"aria-label="Employees">

<divrole="row">

<divrole="columnheader">Name</div>

<divrole="columnheader">Department</div>

</div>

<divrole="row">

<divrole="cell">Alice</div>

<divrole="cell">Engineering</div>

</div>

Correct: Using `rowgroup` for additional structure

You can optionally use role="rowgroup" to separate headers from body rows, similar to <thead> and <tbody>. The columnheader elements must still be inside a row:

<divrole="table"aria-label="Employees">

<divrole="rowgroup">

<divrole="row">

<divrole="columnheader">Name</div>

<divrole="columnheader">Department</div>

</div>

<divrole="rowgroup">

<divrole="row">

<divrole="cell">Alice</div>

<divrole="cell">Engineering</div>

</div>

Best practice: Use native table elements

Native HTML tables have built-in semantics that make ARIA roles unnecessary. A <th> inside a <tr> already behaves as a columnheader inside a row:

<table>

<thead>

<tr>

<th>Department</th>

</tr>

</thead>

<tbody>

<tr>

<td>Alice</td>

<td>Engineering</td>

</tr>

</tbody>

</table>

This approach is simpler, more robust across browsers and assistive technologies, and avoids the risk of ARIA misuse. Reserve ARIA table roles for situations where native table markup is not an option.

Bad value X for attribute “src” on element “img”: Percentage ("%") is not followed by two hexadecimal digits.

url encoding

In URLs, special characters that aren't part of the standard allowed set must be represented using percent-encoding (also called URL encoding). This works by replacing the character with a % followed by two hexadecimal digits representing its byte value — for example, a space becomes %20, and an ampersand becomes %26. Because % itself serves as the escape character in this scheme, any bare % that isn't followed by two hexadecimal digits creates an ambiguous, invalid URL.

When the W3C validator encounters a src attribute containing a % not followed by two valid hex digits, it cannot determine the intended character and reports the error. This issue typically arises in two scenarios:

A literal percent sign in the URL — for instance, a query parameter like ?width=48% where the % is meant as an actual percent symbol. The % must be encoded as %25.
Incomplete or corrupted percent-encoding — such as %2 instead of %20, or %GZ where the characters after % aren't valid hexadecimal digits (only 0–9 and A–F/a–f are valid).

Why this matters

Browser inconsistency: While many browsers try to handle malformed URLs gracefully, behavior varies. Some browsers may misinterpret the intended resource path, leading to broken images or unexpected requests.
Standards compliance: The URL Living Standard and RFC 3986 define strict rules for percent-encoding. Invalid URLs violate these standards.
Reliability: Proxies, CDNs, and server-side software may reject or misroute requests with malformed URLs, causing images to fail to load in certain environments even if they work in your local browser.

How to fix it

Find every bare % in the URL that isn't followed by two hexadecimal digits.
If the % is meant as a literal percent sign, replace it with %25.
If the % is part of a broken encoding sequence (e.g., %2 or %GH), correct it to the intended two-digit hex code (e.g., %20 for a space).
Use proper URL encoding functions in your language or framework (e.g., encodeURIComponent() in JavaScript, urlencode() in PHP) when building URLs dynamically, rather than constructing them by hand.

Examples

Literal percent sign not encoded

<imgalt="Chart"src="https://example.com/chart.png?scale=50%">

<imgalt="Chart"src="https://example.com/chart.png?scale=50%25">

Incomplete percent-encoding sequence

<imgalt="Photo"src="https://example.com/my%2photo.jpg">

<imgalt="Photo"src="https://example.com/my%20photo.jpg">

Non-hexadecimal characters after percent sign

<imgalt="Logo"src="https://example.com/logo%zz.png">

<imgalt="Logo"src="https://example.com/logo.png">

Multiple encoding issues in one URL

<imgalt="Report"src="https://example.com/img?label=100%&name=my file.png">

<imgalt="Report"src="https://example.com/img?label=100%25&name=my%20file.png">

Building URLs safely with JavaScript

When generating src values in code, use encodeURIComponent() to handle special characters automatically:

constlabel="100%";

constname="my file.png";

constsrc=`https://example.com/img?label=${encodeURIComponent(label)}&name=${encodeURIComponent(name)}`;

// Result: "https://example.com/img?label=100%25&name=my%20file.png"

This ensures every special character — including % — is correctly percent-encoded without manual effort.

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

The fragment portion of a URL (everything after the # symbol) follows the same encoding rules as the rest of the URL — literal space characters are not permitted. When a browser encounters a space in a URL fragment, it may try to correct it automatically, but this behavior is not guaranteed across all browsers and contexts. Relying on browser error-correction leads to fragile links that may break unpredictably.

This issue matters for several reasons. First, it produces invalid HTML that fails W3C validation. Second, fragment navigation (jumping to a specific section of a page) may not work correctly if the browser doesn't auto-correct the space. Third, assistive technologies like screen readers rely on well-formed URLs to announce link destinations accurately. Finally, tools that parse or process HTML programmatically — such as crawlers, link checkers, and content management systems — may misinterpret or reject malformed URLs.

The most common scenario for this error is linking to an id attribute on the same page or another page where the id contains spaces. However, it's worth noting that id values themselves cannot contain spaces in valid HTML (a space in an id would make it multiple invalid tokens). So if you're writing both the link and the target, the best fix is often to correct the id itself by using hyphens or underscores instead of spaces.

How to Fix It

There are two main approaches:

Percent-encode the spaces — Replace each space with %20 in the href value.
Use space-free identifiers — Change the target id to use hyphens or camelCase, then update the fragment to match.

The second approach is strongly preferred because it fixes the root problem and produces cleaner, more readable markup.

Examples

❌ Invalid: Space in the fragment

<ahref="https://example.com/page#some term">Go to section</a>

<ahref="#my section">Jump to My Section</a>

✅ Fixed: Percent-encode the space

If you cannot control the target id (e.g., linking to an external page), percent-encode the space:

<ahref="https://example.com/page#some%20term">Go to section</a>

✅ Better fix: Use a hyphenated `id` and matching fragment

When you control both the link and the target, use a space-free id:

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

<p>Some content here.</p>

<ahref="#my-section">Jump to My Section</a>

❌ Invalid: Space in fragment linking to another page

<ahref="/docs/getting-started#quick start guide">Quick Start Guide</a>

✅ Fixed: Matching hyphenated `id`

<h2id="quick-start-guide">Quick Start Guide</h2>

<ahref="/docs/getting-started#quick-start-guide">Quick Start Guide</a>

A note on `id` naming conventions

Since fragment identifiers reference id attributes, adopting a consistent id naming convention avoids this issue entirely. Common patterns include:

<sectionid="getting-started">

<sectionid="gettingStarted">

<sectionid="getting_started">

All three are valid and will never trigger a space-related validation error in your fragment links.

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

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

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

The <iframe> element embeds another HTML document within the current page, and its src attribute specifies the URL of the content to load. According to the URL Living Standard and RFC 3986, URLs have a strict set of allowed characters. The space character (U+0020) is not one of them — it must always be percent-encoded when it appears in any part of a URL.

When the W3C HTML Validator encounters a literal space in the query portion of an <iframe>'s src attribute, it raises this error because the browser has to guess what you meant. While most modern browsers will silently encode the space for you, relying on this behavior is problematic for several reasons:

Standards compliance: The HTML specification requires that the src attribute contain a valid URL. A URL with literal spaces is not valid.
Interoperability: Different browsers, HTTP clients, and intermediary servers may handle unencoded spaces differently. Some might truncate the URL at the first space, while others might encode it. This inconsistency can lead to broken embeds.
Copy-paste and sharing: If a user or script extracts the URL from the HTML source, the unencoded space may cause errors in contexts that don't perform automatic encoding.

To fix this, replace every literal space in the URL with %20. This is the standard percent-encoding for the space character. In query strings, you can also use + as an alternative encoding for spaces (this is common in application/x-www-form-urlencoded format), though %20 is universally accepted in all parts of a URL.

If you're generating <iframe> URLs dynamically with JavaScript, use the built-in encodeURIComponent() function to encode individual query parameter values, or use the URL and URLSearchParams APIs, which handle encoding automatically.

Examples

❌ Invalid: literal spaces in the query string

<iframesrc="https://maps.google.com/maps?q=2700 6th Avenue"></iframe>

The space between 2700 and 6th and between 6th and Avenue triggers the validation error.

✅ Fixed: spaces encoded as `%20`

<iframesrc="https://maps.google.com/maps?q=2700%206th%20Avenue"></iframe>

✅ Fixed: spaces encoded as `+` in the query string

<iframesrc="https://maps.google.com/maps?q=2700+6th+Avenue"></iframe>

Both %20 and + are valid encodings for spaces in query strings.

❌ Invalid: spaces in multiple query parameters

<iframe

src="https://example.com/embed?title=My Page&city=New York">

</iframe>

✅ Fixed: all spaces properly encoded

<iframe

src="https://example.com/embed?title=My%20Page&city=New%20York">

</iframe>

Using JavaScript to build encoded URLs

If you construct iframe URLs dynamically, let the browser handle encoding for you:

consturl=newURL("https://maps.google.com/maps");

url.searchParams.set("q","2700 6th Avenue");

constiframe=document.createElement("iframe");

iframe.src=url.toString();

// Result: "https://maps.google.com/maps?q=2700+6th+Avenue"

The URLSearchParams API automatically encodes spaces (as +), along with any other special characters, ensuring the resulting URL is always valid.

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

URLs follow strict syntax rules defined by RFC 3986, which does not permit literal space characters anywhere in a URI. When the W3C validator encounters a space in the href attribute of an <a> element — particularly within the query string (the part after the ?) — it flags it as an illegal character.

While most modern browsers will silently fix malformed URLs by encoding spaces for you, relying on this behavior is problematic for several reasons:

Standards compliance: The HTML specification requires that href values contain valid URLs. A space makes the URL syntactically invalid.
Interoperability: Not all user agents, crawlers, or HTTP clients handle malformed URLs the same way. Some may truncate the URL at the first space or reject it entirely.
Accessibility: Screen readers and assistive technologies may struggle to interpret or announce links with invalid URLs.
Link sharing and copy-pasting: If a user copies the link from the source or if the URL is used in an API or redirect, the unencoded space can cause breakage.

To fix this issue, replace every literal space character in the URL with %20. Within query string values, you can also use + as a space encoding (this is the application/x-www-form-urlencoded format commonly used in form submissions). If you're generating URLs dynamically, use your programming language's URL encoding function (e.g., encodeURIComponent() in JavaScript, urlencode() in PHP, or urllib.parse.quote() in Python).

Examples

Incorrect — spaces in the query string

<ahref="https://example.com/search?query=hello world&lang=en">Search</a>

The space between hello and world is an illegal character in the URL.

Correct — space encoded as `%20`

<ahref="https://example.com/search?query=hello%20world&lang=en">Search</a>

Correct — space encoded as `+` in query string

<ahref="https://example.com/search?query=hello+world&lang=en">Search</a>

Using + to represent a space is valid within query strings and is commonly seen in URLs generated by HTML forms.

Incorrect — spaces in the path and query

<ahref="https://example.com/my folder/page?name=John Doe">Profile</a>

Correct — all spaces properly encoded

<ahref="https://example.com/my%20folder/page?name=John%20Doe">Profile</a>

Generating safe URLs in JavaScript

If you're building URLs dynamically, use encodeURIComponent() for individual parameter values:

constquery="hello world";

consturl="https://example.com/search?query="+encodeURIComponent(query);

// Result: "https://example.com/search?query=hello%20world"

</script>

Note that encodeURIComponent() encodes spaces as %20, which is safe for use in any part of a URL. Avoid using encodeURI() for query values, as it does not encode certain characters like & and = that may conflict with query string syntax.

An element with “role=cell” must be contained in, or owned by, an element with “role=row”.

role
cell

The ARIA specification defines a strict ownership hierarchy for table-related roles. A role="cell" element must be "owned by" an element with role="row", meaning it must either be a direct child of that element or be associated with it via the aria-owns attribute. This mirrors how native HTML tables work: a <td> element must live inside a <tr> element. When you use ARIA roles to build custom table structures from non-table elements like <div> or <span>, you are responsible for maintaining this same hierarchy manually.

The expected nesting order for an ARIA table is:

role="table" — the outermost container
role="rowgroup" (optional) — groups rows together, like <thead>, <tbody>, or <tfoot>
role="row" — a single row of cells
role="cell" or role="columnheader" / role="rowheader" — individual cells

When a role="cell" element is placed directly inside a role="table" or any other container that isn't role="row", screen readers lose the ability to announce row and column positions. Users who rely on table navigation shortcuts (such as moving between cells with arrow keys) will find the table unusable. This is not just a validation concern — it directly impacts whether people can access your content.

This issue commonly arises when developers add intermediate wrapper elements for styling purposes and accidentally break the required parent-child relationship, or when they forget to assign role="row" to a container element.

How to Fix

Ensure every element with role="cell" is a direct child of an element with role="row". If you have wrapper elements between the row and cell for layout or styling, either remove them, move the role assignments, or use aria-owns on the row element to explicitly claim ownership of the cells.

Examples

Incorrect — Cell Without a Row Parent

This triggers the validation error because role="cell" elements are direct children of the role="table" container, with no role="row" in between.

<divrole="table">

<divrole="cell">Name</div>

<divrole="cell">Email</div>

</div>

Incorrect — Intermediate Wrapper Breaking Ownership

Here, a styling wrapper sits between the row and its cells. Since the <div> without a role is not a role="row", the cells are not properly owned.

<divrole="table">

<divrole="row">

<divclass="cell-wrapper">

<divrole="cell">Row 1, Cell 1</div>

<divrole="cell">Row 1, Cell 2</div>

</div>

Correct — Cells Directly Inside Rows

Each role="cell" is a direct child of a role="row" element, forming a valid ARIA table structure.

<divrole="table"aria-label="Team members">

<divrole="row">

<divrole="columnheader">Name</div>

<divrole="columnheader">Email</div>

</div>

<divrole="row">

<divrole="cell">Alice</div>

<divrole="cell">alice@example.com</div>

</div>

<divrole="row">

<divrole="cell">Bob</div>

<divrole="cell">bob@example.com</div>

</div>

Correct — Using Rowgroups

You can optionally group rows with role="rowgroup", similar to <thead> and <tbody>. The cells still must be direct children of their rows.

<divrole="table"aria-label="Quarterly results">

<divrole="rowgroup">

<divrole="row">

<divrole="columnheader">Quarter</div>

<divrole="columnheader">Revenue</div>

</div>

<divrole="rowgroup">

<divrole="row">

<divrole="cell">Q1</div>

<divrole="cell">$10,000</div>

</div>

<divrole="row">

<divrole="cell">Q2</div>

<divrole="cell">$12,500</div>

</div>

Correct — Using Native HTML Instead

If your content is genuinely tabular data, consider using native HTML table elements instead of ARIA roles. Native tables have built-in semantics and require no additional role attributes.

<table>

<tr>

<th>Email</th>

</tr>

<tr>

<td>Alice</td>

<td>alice@example.com</td>

</tr>

</table>

Native HTML tables are always preferable when they suit your use case. The first rule of ARIA is: if you can use a native HTML element that already has the semantics you need, use it instead of adding ARIA roles to a generic element.

Bad value X for attribute “href” on element “a”: Percentage ("%") is not followed by two hexadecimal digits.

url encoding

Percent-encoding (also called URL encoding) is the mechanism defined by RFC 3986 for representing special or reserved characters in URLs. It works by replacing a character with a % sign followed by two hexadecimal digits that correspond to the character's byte value. For example, a space becomes %20, an ampersand becomes %26, and a literal percent sign becomes %25. When a browser or parser encounters % in a URL, it expects the next two characters to be valid hexadecimal digits so it can decode them back to the original character.

If the parser finds a % that is not followed by two hexadecimal digits, it cannot decode the sequence, and the URL is considered invalid. The W3C validator flags this as a bad value for the href attribute.

Common causes

A literal % that wasn't encoded. This is the most frequent cause. For instance, a URL containing a percentage value like 50% in a query string — the % must be written as %25.
Truncated percent-encoded sequences. A sequence like %2 is incomplete because it only has one hex digit instead of two.
Invalid hex characters after %. A sequence like %GZ is invalid because G and Z are not hexadecimal digits (valid hex digits are 0–9 and A–F).
Copy-pasting URLs from non-web sources. URLs pasted from documents, emails, or spreadsheets may contain unencoded special characters.

Why this matters

Broken links. Browsers may interpret the malformed URL differently than intended, leading users to the wrong page or a 404 error.
Standards compliance. The WHATWG URL Standard and the HTML specification require that href values contain valid URLs. Malformed URLs violate these standards.
Accessibility. Screen readers and assistive technologies rely on well-formed URLs to provide accurate navigation information to users.
Interoperability. While some browsers attempt error recovery on malformed URLs, behavior is not guaranteed to be consistent across all browsers and tools.

How to fix it

Encode literal % as %25. If the % is meant to appear as part of the URL's content (e.g., in a query parameter value), replace it with %25.
Complete any truncated sequences. If you intended a percent-encoded character like %20, make sure both hex digits are present.
Use proper URL encoding functions. In JavaScript, use encodeURIComponent() for query parameter values. In server-side languages, use the equivalent encoding function (e.g., urllib.parse.quote() in Python, urlencode() in PHP).

Examples

Literal `%` not encoded

<ahref="https://example.com?width=48%">48% width</a>

<ahref="https://example.com?width=48%25">48% width</a>

Truncated percent-encoded sequence

<ahref="https://example.com/path%2file">Download</a>

<ahref="https://example.com/path%2Ffile">Download</a>

Invalid hexadecimal characters

<ahref="https://example.com/search?q=%XYdata">Search</a>

<ahref="https://example.com/search?q=%25XYdata">Search</a>

Multiple unencoded `%` in a URL

<ahref="https://example.com?min=10%&max=90%">Range</a>

<ahref="https://example.com?min=10%25&max=90%25">Range</a>

Bad value X for attribute “srcset” on element “img”: Must contain one or more image candidate strings.

srcset
img

The srcset attribute allows you to specify multiple image sources so the browser can choose the most appropriate one based on the user's device characteristics, such as screen resolution or viewport width. When you include a srcset attribute on an <img> element, the HTML specification requires it to contain one or more comma-separated image candidate strings. Each string consists of a URL followed by an optional descriptor — either a width descriptor (e.g., 200w) or a pixel density descriptor (e.g., 2x).

This validation error typically appears when:

The srcset attribute is empty (srcset="")
The srcset attribute contains only whitespace (srcset=" ")
The value contains syntax errors such as missing URLs, invalid descriptors, or incorrect formatting
A templating engine or CMS outputs the attribute with no value

This matters because browsers rely on the srcset value to select the best image to load. An empty or malformed srcset means the browser must fall back entirely to the src attribute, making the srcset attribute pointless. Additionally, invalid markup can cause unexpected behavior across different browsers and undermines standards compliance.

How to fix it

Provide valid image candidate strings. Each entry needs a URL and optionally a width or pixel density descriptor, with entries separated by commas.
Remove the attribute entirely if you don't have multiple image sources to offer. A plain src attribute is perfectly fine on its own.
Check dynamic output. If a CMS or templating system generates the srcset, ensure it conditionally omits the attribute when no responsive image candidates are available, rather than outputting an empty attribute.

Examples

❌ Empty `srcset` attribute

<imgsrc="/img/photo.jpg"alt="A sunset over the ocean"srcset="">

This triggers the error because srcset is present but contains no image candidate strings.

❌ Malformed `srcset` value

<imgsrc="/img/photo.jpg"alt="A sunset over the ocean"srcset="1x, 2x">

This is invalid because each candidate string must include a URL. Descriptors alone are not valid entries.

✅ Using pixel density descriptors

<img

src="/img/photo-400.jpg"

alt="A sunset over the ocean"

srcset=" /img/photo-400.jpg 1x, /img/photo-800.jpg 2x ">

/img/photo-400.jpg 1x,

/img/photo-800.jpg 2x

Each candidate string contains a URL followed by a pixel density descriptor (1x, 2x). The browser picks the best match for the user's display.

✅ Using width descriptors with `sizes`

<img

src="/img/photo-400.jpg"

alt="A sunset over the ocean"

srcset=" /img/photo-400.jpg 400w, /img/photo-800.jpg 800w, /img/photo-1200.jpg 1200w "

/img/photo-400.jpg 400w,

/img/photo-800.jpg 800w,

/img/photo-1200.jpg 1200w

sizes="(max-width: 600px) 400px, (max-width: 1000px) 800px, 1200px">

Width descriptors (e.g., 400w) tell the browser the intrinsic width of each image. The sizes attribute then tells the browser how large the image will be displayed at various viewport sizes, allowing it to calculate the best source to download.

✅ Removing `srcset` when not needed

<imgsrc="/img/photo.jpg"alt="A sunset over the ocean">

If you only have a single image source, simply omit srcset altogether. The src attribute alone is valid and sufficient.

✅ Single candidate in `srcset`

<img

src="/img/photo.jpg"

alt="A sunset over the ocean"

srcset="/img/photo-highres.jpg 2x">

Even a single image candidate string is valid. Here, the browser will use the high-resolution image on 2x displays and fall back to src otherwise.

This document appears to be written in Arabic. Consider adding “dir="rtl"” to the “html” start tag.

The dir attribute specifies the base text direction for the content of an element. When a document is written in a right-to-left language like Arabic, Hebrew, Persian (Farsi), or Urdu, the browser needs to know that text should flow from right to left. Without this attribute, browsers default to left-to-right (ltr) rendering, which can cause a range of problems: text alignment may be incorrect, punctuation can appear in the wrong place, and the overall page layout may look broken or confusing to native readers.

This matters for several important reasons:

Accessibility: Screen readers and other assistive technologies rely on the dir attribute to correctly announce and navigate content. Without it, the reading experience for users relying on these tools may be disorienting or incorrect.
Visual correctness: Elements like lists, tables, form labels, and navigation menus will mirror their layout in RTL mode. Without dir="rtl", these elements default to LTR positioning, which feels unnatural for RTL language speakers.
Bidirectional text handling: Documents often contain mixed-direction content (e.g., Arabic text with embedded English words, numbers, or brand names). The Unicode Bidirectional Algorithm (BiDi) uses the base direction set by dir to correctly resolve the ordering of these mixed runs of text.
Standards compliance: The WHATWG HTML Living Standard recommends that authors set the dir attribute to match the language of the document, and the W3C Internationalization guidelines strongly encourage it for RTL languages.

How to fix it

Add dir="rtl" to your <html> start tag. If you haven't already, also include the appropriate lang attribute for the specific language you're using.

For Arabic:

<htmldir="rtl"lang="ar">

For Hebrew:

<htmldir="rtl"lang="he">

For Persian:

<htmldir="rtl"lang="fa">

Examples

❌ Missing `dir` attribute on an Arabic document

<!DOCTYPE html>

<htmllang="ar">

<head>

<metacharset="utf-8">

<title>مرحبا بالعالم</title>

</head>

<body>

<h1>مرحبا بالعالم</h1>

<p>هذه صفحة تجريبية باللغة العربية.</p>

</body>

</html>

The browser will render this page with a left-to-right base direction. The heading and paragraph text may appear left-aligned, and any mixed-direction content (like embedded numbers or English words) may be ordered incorrectly.

✅ Correct: `dir="rtl"` added to the `<html>` tag

<!DOCTYPE html>

<htmldir="rtl"lang="ar">

<head>

<metacharset="utf-8">

<title>مرحبا بالعالم</title>

</head>

<body>

<h1>مرحبا بالعالم</h1>

<p>هذه صفحة تجريبية باللغة العربية.</p>

</body>

</html>

Now the browser knows to render the page right-to-left. Text will be right-aligned by default, scroll bars will appear on the left, and the overall layout will feel natural for Arabic readers.

Handling mixed-direction content within a page

If your RTL document contains sections in a left-to-right language, use the dir attribute on individual elements to override the base direction locally:

<p>قام المستخدم بزيارة <spandir="ltr">www.example.com</span> اليوم.</p>

This ensures the URL renders in the correct left-to-right order while the surrounding Arabic text flows right-to-left. Setting dir="rtl" on the <html> element establishes the correct default, and you only need per-element overrides for embedded LTR content.

Bad value X for attribute “srcset” on element “source”: Must contain one or more image candidate strings.

The <source> element is used inside <picture>, <audio>, or <video> elements to specify alternative media resources. When used inside a <picture> element, the srcset attribute is required and must contain one or more comma-separated image candidate strings. Each image candidate string consists of a URL and an optional descriptor — either a width descriptor like 400w or a pixel density descriptor like 2x.

This validation error typically occurs when:

The srcset attribute is present but empty (srcset="").
The attribute value contains only whitespace.
The value is malformed or contains syntax errors (e.g., missing URLs, invalid descriptors).
A dynamic templating system or CMS outputs the attribute with no value.

Why this matters

Browsers rely on the srcset attribute to select the most appropriate image to display based on the user's device capabilities, viewport size, and network conditions. An empty or invalid srcset means the browser cannot perform this selection, potentially resulting in no image being displayed at all. This degrades the user experience, harms accessibility (screen readers and assistive technologies may encounter unexpected behavior), and violates the HTML specification as defined by the WHATWG living standard.

How to fix it

Provide at least one valid image URL in the srcset attribute.
Optionally add descriptors — use width descriptors (w) when combined with the sizes attribute, or pixel density descriptors (x) for fixed-size images.
If you have no image to provide, remove the <source> element entirely rather than leaving srcset empty.
Check dynamic output — if a CMS or templating engine generates the srcset value, add a conditional check to omit the <source> element when no images are available.

Examples

❌ Empty `srcset` attribute

<sourcesrcset=""type="image/webp">

<imgsrc="photo.jpg"alt="A sunset over the ocean">

</picture>

This triggers the error because srcset is present but contains no image candidate strings.

❌ Invalid descriptor syntax

<sourcesrcset="photo.webp 400"type="image/webp">

<imgsrc="photo.jpg"alt="A sunset over the ocean">

</picture>

This is invalid because 400 is not a recognized descriptor — it must be 400w or a density descriptor like 2x.

✅ Single image candidate

<sourcesrcset="photo.webp"type="image/webp">

<imgsrc="photo.jpg"alt="A sunset over the ocean">

</picture>

A single URL without a descriptor is valid and serves as the default 1x candidate.

✅ Multiple candidates with width descriptors

<source

srcset="photo-small.webp 400w, photo-medium.webp 800w, photo-large.webp 1200w"

sizes="(max-width: 600px) 400px, (max-width: 1000px) 800px, 1200px"

type="image/webp">

<imgsrc="photo.jpg"alt="A sunset over the ocean">

</picture>

This provides three image candidates with width descriptors, allowing the browser to choose the best match based on the viewport and display density.

✅ Multiple candidates with pixel density descriptors

<sourcesrcset="photo.webp 1x, photo-2x.webp 2x"type="image/webp">

<imgsrc="photo.jpg"alt="A sunset over the ocean">

</picture>

Pixel density descriptors tell the browser which image to use based on the device's pixel ratio — 1x for standard displays and 2x for high-DPI (Retina) screens.

✅ Removing the source element when no image is available

If your application dynamically generates the srcset value and sometimes has no image to provide, omit the <source> element entirely:

<imgsrc="photo.jpg"alt="A sunset over the ocean">

</picture>

This is valid because the <img> element inside <picture> serves as the required fallback and can stand alone.

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

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:

In the path or fragment: Replace each space with %20. For example, /my file.html becomes /my%20file.html.
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.
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

<ahref="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`

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

Invalid — space in a query parameter

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

Fixed — space encoded in the query string

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

Invalid — multiple spaces in different URL parts

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

Fixed — all spaces encoded

<ahref="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:

// encodeURI encodes a full URL but preserves :, /, ?, #, etc.

consturl=encodeURI("https://example.com/docs/My Report.pdf");

// Result: "https://example.com/docs/My%20Report.pdf"

// encodeURIComponent encodes a single value (for query params)

constquery=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.

Bad value X for attribute “datetime” on element “time”: The literal did not satisfy the time-datetime format.

The <time> HTML element represents a specific period in time or a duration. Its datetime attribute translates human-readable text into a machine-readable format, enabling browsers, search engines, and assistive technologies to reliably parse and understand temporal data. When the datetime value doesn't match one of the accepted formats, the machine-readable purpose of the element is defeated — tools cannot interpret the date or time, which undermines features like search engine rich results, calendar integration, and accessibility enhancements for screen readers.

The HTML specification defines several valid formats for the datetime attribute. Here are the most commonly used ones:

Format	Example	Description
Date	`2024-03-15`	Year, month, day
Month	`2024-03`	Year and month only
Year	`2024`	Valid year
Yearless date	`03-15`	Month and day without year
Time	`14:30` or `14:30:00`	Hours and minutes (seconds optional)
Date and time	`2024-03-15T14:30`	Date and time separated by `T`
Date and time with timezone	`2024-03-15T14:30Z` or `2024-03-15T14:30+05:30`	With UTC (`Z`) or offset
Duration (precise)	`PT1H30M`	ISO 8601 duration
Duration (approximate)	`P2Y6M`	Years, months, etc.
Week	`2024-W12`	ISO week number

Common mistakes that trigger this error include:

Using slashes instead of hyphens: 03/15/2024 instead of 2024-03-15
Using informal date formats: March 15, 2024 or 15-03-2024
Omitting the T separator between date and time: 2024-03-15 14:30
Using 12-hour time with AM/PM: 2:30 PM instead of 14:30
Providing incomplete values: 2024-3-5 instead of 2024-03-05 (months and days must be zero-padded)

Examples

Invalid: Slash-separated date

<timedatetime="03/15/2024">March 15, 2024</time>

Valid: ISO 8601 date format

<timedatetime="2024-03-15">March 15, 2024</time>

Invalid: Missing `T` separator and using AM/PM

<timedatetime="2024-03-15 2:30 PM">March 15 at 2:30 PM</time>

Valid: Date-time with `T` separator and 24-hour time

<timedatetime="2024-03-15T14:30">March 15 at 2:30 PM</time>

Invalid: Informal time string

<timedatetime="half past two">2:30 PM</time>

Valid: Simple time value

<timedatetime="14:30">2:30 PM</time>

Invalid: Non-standard duration

<timedatetime="1 hour 30 minutes">1.5 hours</time>

Valid: ISO 8601 duration

<timedatetime="PT1H30M">1.5 hours</time>

Valid: Date-time with timezone offset

<p>The event starts at <timedatetime="2024-03-15T14:30-05:00">2:30 PM ET on March 15</time>.</p>

Valid: Using only the month

<p>Published in <timedatetime="2024-03">March 2024</time>.</p>

Remember that the human-readable text content between the <time> tags can be in any format you like — it's only the datetime attribute value that must follow the specification. This lets you display dates in a user-friendly way while still providing a standardized machine-readable value.

Bad value “” for attribute “target” on element “area”: Browsing context name must be at least one character long.

target
area

Bad value “” for attribute “max” on element “input”: The empty string is not a valid floating point number.

max
input

Bad value X for attribute “src” on element “source”: Illegal character in path segment: space is not allowed.

Bad value “X” for attribute “src” on element “img”: Illegal character in path segment: space is not allowed.

URLs follow strict syntax rules defined by RFC 3986, which does not allow literal space characters in any part of a URL — whether in the path, query string, or fragment. While many browsers will silently handle spaces by encoding them before making a request, the raw HTML is still invalid. The W3C HTML validator flags this because the src attribute expects a valid URL, and a URL containing a raw space does not conform to the standard.

This issue commonly appears in two scenarios: spaces in file paths (e.g., my image.jpg) and spaces in query string values (e.g., ?search=my term). Both must be percent-encoded. The percent-encoded form of a space is %20. In query strings specifically, you may also see + used to represent spaces (as defined by application/x-www-form-urlencoded), which is also valid in that context.

Beyond standards compliance, raw spaces in URLs can cause real problems. Some older browsers or HTTP clients may truncate the URL at the first space, leading to broken images or failed resource loads. Spaces can also cause issues with link sharing, copy-pasting, and server-side URL parsing. Proper encoding ensures your URLs work reliably across all environments.

How to fix it

Replace spaces with %20 in all parts of the URL. This is the universally safe approach.
Rename files to avoid spaces altogether. Use hyphens (-) or underscores (_) instead of spaces in file and directory names.
Use + in query strings if you prefer, though %20 works everywhere in a URL.

If you're generating URLs programmatically, use built-in encoding functions like JavaScript's encodeURI() or encodeURIComponent() to handle this automatically.

Examples

Spaces in the file path

This triggers the validation error because the file name contains a space:

<imgsrc="/images/my photo.jpg"alt="A vacation photo">

Fix it by encoding the space:

<imgsrc="/images/my%20photo.jpg"alt="A vacation photo">

Or better yet, rename the file to avoid spaces:

<imgsrc="/images/my-photo.jpg"alt="A vacation photo">

Spaces in the query string

This triggers the error because the query parameter value contains a space:

<imgsrc="https://example.com/image?title=sunset beach"alt="Sunset at the beach">

Fix by percent-encoding the space:

<imgsrc="https://example.com/image?title=sunset%20beach"alt="Sunset at the beach">

Using + is also acceptable in query strings:

<imgsrc="https://example.com/image?title=sunset+beach"alt="Sunset at the beach">

Multiple spaces in a URL

When a URL has multiple spaces, each one must be encoded:

<imgsrc="/uploads/user photos/trip to paris.jpg"alt="Trip to Paris">

<imgsrc="/uploads/user%20photos/trip%20to%20paris.jpg"alt="Trip to Paris">

Bad value “” for attribute “target” on element “a”: Browsing context name must be at least one character long.

The target attribute specifies where a linked document should be opened. When the validator encounters target="", it reports an error because the HTML specification requires browsing context names to be at least one character long. An empty string is not a valid browsing context name and has no defined behavior, which means browsers may handle it inconsistently.

This issue commonly arises when a target value is dynamically generated by a CMS, template engine, or JavaScript and the value ends up being empty. It can also happen when a developer adds the attribute with the intent to fill it in later but forgets to do so.

Setting target to an empty string is problematic for several reasons:

Standards compliance: The WHATWG HTML specification explicitly requires valid browsing context names to be non-empty strings. An empty value violates this rule.
Unpredictable behavior: Browsers may interpret an empty target differently — some may treat it like _self, others may behave unexpectedly. This makes your site harder to test and maintain.
Accessibility concerns: Screen readers and assistive technologies may announce the target attribute or use it to inform users about link behavior. An empty value provides no meaningful information.

To fix this, choose one of the following approaches:

Remove the attribute if you want the default behavior (opening in the same browsing context, equivalent to _self).
Set a valid keyword like _blank, _self, _parent, or _top.
Set a custom name if you want multiple links to share the same browsing context (e.g., target="externalWindow").

Examples

❌ Invalid: empty `target` attribute

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

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

✅ Fixed: remove `target` entirely

If you want the link to open in the current browsing context (the default), simply remove the attribute:

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

✅ Fixed: use `_blank` to open in a new tab

<ahref="https://example.com"target="_blank"rel="noopener">Visit Example</a>

Note the addition of rel="noopener" — this is a security best practice when using target="_blank", as it prevents the opened page from accessing the window.opener property.

✅ Fixed: use `_self` explicitly

If you want to be explicit about opening in the same context:

<ahref="https://example.com"target="_self">Visit Example</a>

✅ Fixed: use a custom browsing context name

You can use a custom name so that multiple links reuse the same tab or window:

<ahref="https://example.com"target="externalWindow">Example</a>

<ahref="https://example.org"target="externalWindow">Example Org</a>

Both links will open in the same browsing context named externalWindow. If it doesn't exist yet, the browser creates it; subsequent clicks reuse it.

Dynamic templates

If your target value comes from a template or CMS, make sure the attribute is conditionally rendered rather than output with an empty value. For example, in a templating language:

<ahref="https://example.com"target="">Visit</a>

<ahref="https://example.com"target="_blank"rel="noopener">Visit</a>

In your template logic, conditionally omit the target attribute entirely when no value is provided, rather than rendering it as an empty string.

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

A mailto: link follows URI syntax as defined by RFC 3986, which does not permit raw space characters anywhere in the URI. When the W3C validator encounters a space inside the href value of a mailto: link, it reports it as an illegal character in the scheme data. This most commonly happens due to a typo in the email address itself — for example, accidentally inserting a space in the domain name (example .com) or the local part (user name@example.com). It can also occur when query parameters like subject or body contain unencoded spaces.

This matters for several reasons. First, browsers may truncate or misinterpret the href at the space boundary, meaning the mail client may open with an incorrect or incomplete email address. Second, assistive technologies rely on well-formed URIs to communicate link destinations to users. A malformed mailto: link can confuse screen readers or prevent users from understanding where the link leads. Third, invalid markup signals poor quality to search engines and automated tools.

To fix this issue:

Check the email address for typos. Remove any accidental spaces in the local part (before @) or the domain part (after @).
Percent-encode spaces in query parameters. If you're using subject, body, or cc parameters in the mailto: URI, replace spaces with %20.
Avoid copying and pasting email addresses from formatted documents, which can introduce non-breaking spaces or other invisible whitespace characters.

Examples

Invalid — space in the email address

A space in the domain name makes the URI invalid:

<ahref="mailto:user@example com">Send Email</a>

Valid — corrected email address

Remove the space to form a valid email address:

<ahref="mailto:user@example.com">Send Email</a>

Invalid — space in the local part

<ahref="mailto:john doe@example.com">Send Email</a>

Valid — space removed from local part

<ahref="mailto:johndoe@example.com">Send Email</a>

Invalid — unencoded spaces in subject parameter

<ahref="mailto:info@example.com?subject=Hello World">Email Us</a>

Valid — percent-encoded spaces in subject parameter

Replace each space with %20 in query parameter values:

<ahref="mailto:info@example.com?subject=Hello%20World">Email Us</a>

Valid — full mailto with multiple parameters

<ahref="mailto:support@example.com?subject=Bug%20Report&body=Please%20describe%20the%20issue.">

Report a Bug

</a>

Element “X” not allowed as child of element “Y” in this context. (Suppressing further errors from this subtree.)

nesting

HTML elements follow strict nesting rules defined by the WHATWG HTML Living Standard. Every element has a content model — a description of what content (text, elements, or both) it may contain. When you place an element somewhere it isn't allowed, the browser must guess your intent and may restructure the DOM in unexpected ways. This can lead to inconsistent rendering across browsers, broken layouts, and accessibility issues for screen readers and other assistive technologies.

The "(Suppressing further errors from this subtree.)" part of the message means the validator has stopped checking anything nested inside the problematic element. This is important — it means there could be additional errors hidden beneath this one. Fixing this nesting issue may reveal further problems that need attention.

Here are some of the most common cases that trigger this error:

Block elements inside inline elements: Placing a <div> inside a <span> or an <a> that doesn't permit flow content in that context.
Invalid list children: Putting <div>, <p>, or other elements directly inside <ul> or <ol>, which only allow <li> (and <script>/<template>) as direct children.
Invalid table structure: Placing <td> directly inside <table> without wrapping it in <tr>, or putting non-table elements where only <thead>, <tbody>, <tfoot>, or <tr> are expected.
Headings or paragraphs inside <p>: The <p> element only accepts phrasing content, so nesting a <h2> or another <p> inside it is invalid.
Interactive elements inside interactive elements: Nesting a <button> inside an <a>, or an <a> inside a <button>.

To fix the issue, consult the MDN documentation for the parent element and check its Permitted content section. Then either move the child element to a valid location, wrap it in an appropriate intermediary element, or replace the parent or child with a more suitable element.

Examples

Invalid list children

A <ul> only permits <li> elements as direct children.

❌ Incorrect:

<ul>

<div>

</div>

</ul>

✅ Correct:

<ul>

</ul>

Block element inside a paragraph

The <p> element only accepts phrasing content. A <div> is flow content and cannot be nested inside it.

❌ Incorrect:

<p>

Here is some text.

<divclass="highlight">This is highlighted.</div>

</p>

✅ Correct:

<divclass="highlight">This is highlighted.</div>

Or use a <span> if you want inline styling within the paragraph:

<p>

Here is some text.

<spanclass="highlight">This is highlighted.</span>

</p>

Invalid table structure

Table cells (<td>) must be inside a <tr>, which itself must be inside <thead>, <tbody>, <tfoot>, or directly inside <table>.

❌ Incorrect:

<table>

</table>

✅ Correct:

<table>

<tr>

</tr>

</table>

Interactive elements nested inside interactive elements

A <button> cannot be placed inside an <a> element, and vice versa, because interactive content cannot nest inside other interactive content.

❌ Incorrect:

<ahref="/dashboard">

<button>Go to Dashboard</button>

</a>

✅ Correct (choose one or the other):

<ahref="/dashboard">Go to Dashboard</a>

Or style a link to look like a button using CSS:

<ahref="/dashboard"class="button">Go to Dashboard</a>

Wrapping elements inside `<select>`

The <select> element only allows <option>, <optgroup>, and scripting elements as children.

❌ Incorrect:

<div>

<option>Apple</option>

<option>Banana</option>

</div>

</select>

✅ Correct:

<optgrouplabel="Fruits">

<option>Apple</option>

<option>Banana</option>

</optgroup>

</select>

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

The HTML specification defines maxlength as accepting only a valid non-negative integer — a string of one or more ASCII digits representing a number greater than or equal to zero. An empty string does not satisfy this requirement, so the W3C validator flags it as an error. This commonly happens when a value is dynamically generated by a CMS, template engine, or JavaScript framework and the value ends up blank, or when a developer adds the attribute as a placeholder intending to fill it in later.

Why this matters

While most browsers silently ignore an empty maxlength and impose no character limit, relying on this behavior is problematic for several reasons:

Standards compliance: Invalid HTML can lead to unpredictable behavior across different browsers and versions. What works today may not work tomorrow.
Accessibility: Assistive technologies may read or interpret the maxlength attribute to communicate input constraints to users. An empty value could cause confusing or incorrect announcements.
Maintainability: An empty maxlength is ambiguous — it's unclear whether the developer intended no limit, forgot to set a value, or a bug caused the value to be missing.

How to fix it

You have two options:

Set a valid non-negative integer: Provide a concrete number that represents the maximum number of characters the user can enter, such as maxlength="100".
Remove the attribute: If you don't need to enforce a character limit, simply omit maxlength altogether. There is no need to include it with an empty value.

Valid values for maxlength include "0", "1", "255", or any other non-negative whole number. The following are not valid: empty strings (""), negative numbers ("-1"), decimal numbers ("10.5"), or non-numeric strings ("none").

Where `maxlength` applies

The maxlength attribute is meaningful on text-entry input types: text, search, url, tel, email, password, and also on the textarea element. For non-text input types like number, date, range, or checkbox, the attribute has no effect and should not be used.

Examples

❌ Incorrect: empty string triggers the validation error

<inputtype="text"name="username"maxlength="">

❌ Incorrect: other invalid values

<inputtype="text"name="username"maxlength="-1">

<inputtype="email"name="email"maxlength="none">

<inputtype="text"name="bio"maxlength="10.5">

✅ Correct: explicit maximum length

<inputtype="text"name="username"maxlength="30">

✅ Correct: omit the attribute when no limit is needed

<inputtype="text"name="comment">

✅ Correct: `maxlength` on a `textarea`

<textareaname="bio"maxlength="500"></textarea>

✅ Correct: dynamic value with a fallback

If your maxlength value comes from a template or CMS, make sure you either output a valid number or omit the attribute entirely. For example, in a templating language, use conditional logic:

<inputtype="text"name="username"maxlength="100">

Rather than rendering an empty attribute like maxlength="", ensure your template skips the attribute when no value is configured.

Bad value “” for attribute “min” on element “input”: The empty string is not a valid floating point number.

Examples

Incorrect: tab outside of a tablist

Correct: tabs as direct children of tablist

Correct: using aria-owns when DOM nesting isn't possible

Additional notes

Common as Values

Examples

Incorrect: Missing as attribute

Correct: as attribute included

Note on fonts and crossorigin

Full document example

Examples

Incorrect: columnheader not inside a row

Correct: columnheader inside a row

Correct: Using rowgroup for additional structure

Best practice: Use native table elements

Why this matters

How to fix it

Examples

Literal percent sign not encoded

Incomplete percent-encoding sequence

Non-hexadecimal characters after percent sign

Multiple encoding issues in one URL

Building URLs safely with JavaScript

How to Fix It

Examples

❌ Invalid: Space in the fragment

✅ Fixed: Percent-encode the space

✅ Better fix: Use a hyphenated id and matching fragment

❌ Invalid: Space in fragment linking to another page

✅ Fixed: Matching hyphenated id

A note on id naming conventions

Example with the issue

How to fix it

How to fix it

Examples

Invalid: square brackets in a mailto URL

Fixed: remove the brackets

Invalid: square brackets in a query string

Fixed: percent-encode the brackets

Invalid: unprocessed template syntax in rendered HTML

Fixed: ensure the template renders a valid URL

Examples

❌ Invalid: literal spaces in the query string

✅ Fixed: spaces encoded as %20

✅ Fixed: spaces encoded as + in the query string

❌ Invalid: spaces in multiple query parameters

✅ Fixed: all spaces properly encoded

Using JavaScript to build encoded URLs

Examples

Incorrect — spaces in the query string

Correct — space encoded as %20

Correct — space encoded as + in query string

Incorrect — spaces in the path and query

Correct — all spaces properly encoded

Generating safe URLs in JavaScript

How to Fix

Examples

Incorrect — Cell Without a Row Parent

Incorrect — Intermediate Wrapper Breaking Ownership

Correct — Cells Directly Inside Rows

Correct — Using Rowgroups

Correct — Using Native HTML Instead

Common causes

Why this matters

How to fix it

Examples

Literal % not encoded

Truncated percent-encoded sequence

Invalid hexadecimal characters

Multiple unencoded % in a URL

How to fix it

Examples

❌ Empty srcset attribute

❌ Malformed srcset value

✅ Using pixel density descriptors

✅ Using width descriptors with sizes

✅ Removing srcset when not needed

✅ Single candidate in srcset

Common `as` Values

Incorrect: Missing `as` attribute

Correct: `as` attribute included

Note on fonts and `crossorigin`

Incorrect: `columnheader` not inside a `row`

Correct: `columnheader` inside a `row`

Correct: Using `rowgroup` for additional structure

✅ Better fix: Use a hyphenated `id` and matching fragment

✅ Fixed: Matching hyphenated `id`

A note on `id` naming conventions

✅ Fixed: spaces encoded as `%20`

✅ Fixed: spaces encoded as `+` in the query string

Correct — space encoded as `%20`

Correct — space encoded as `+` in query string

Literal `%` not encoded

Multiple unencoded `%` in a URL

❌ Empty `srcset` attribute

❌ Malformed `srcset` value

✅ Using width descriptors with `sizes`

✅ Removing `srcset` when not needed

✅ Single candidate in `srcset`

❌ Missing `dir` attribute on an Arabic document

✅ Correct: `dir="rtl"` added to the `<html>` tag

❌ Empty `srcset` attribute

Fixed — space encoded as `%20`

Invalid: Missing `T` separator and using AM/PM

Valid: Date-time with `T` separator and 24-hour time

Invalid: empty `target` attribute

Fixed: remove `target` for default behavior

Fixed: target a named `<iframe>`

Fixed: conditionally render `target` in templates

❌ Invalid: Empty `max` attribute

❌ Invalid: Empty `max` on a date input

✅ Fixed: Valid date value for `max`

❌ Invalid: empty `target` attribute

✅ Fixed: remove `target` entirely

✅ Fixed: use `_blank` to open in a new tab

✅ Fixed: use `_self` explicitly