HTML Guides

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

1. Provide at least one valid image URL in the srcset attribute.
2. Optionally add descriptors — use width descriptors (w) when combined with the sizes attribute, or pixel density descriptors (x) for fixed-size images.
3. If you have no image to provide, remove the <source> element entirely rather than leaving srcset empty.
4. 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

<picture>

<source srcset="" type="image/webp">

<img src="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

<picture>

<source srcset="photo.webp 400" type="image/webp">

<img src="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

<picture>

<source srcset="photo.webp" type="image/webp">

<img src="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

<picture>

<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">

<img src="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

<picture>

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

<img src="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:

<picture>

<img src="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.

Spaces in the href attribute of an <a> element are not valid URL characters and must be encoded as %20.

URLs follow the syntax defined in RFC 3986, which does not allow literal space characters in any component of a URI. When a browser encounters a space in an href value, it often silently corrects it, but the HTML is still technically invalid. The W3C validator flags this because the raw space violates the URL specification.

To fix the issue, replace each space in the URL with %20. This is the percent-encoded form of the space character. If the URL points to a local file or path that genuinely contains spaces, the encoding is still required.

Some common situations where this appears:

• Links to files with spaces in their names, like my document.pdf.
• Paths that include folder names with spaces, like /my folder/page.html.
• Query parameters that contain unencoded spaces.

HTML examples

Invalid: space in href

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

Valid: spaces encoded as %20

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

If you control the file or directory names, renaming them to avoid spaces altogether is a simpler long term fix. Use hyphens or underscores instead:

<a href="/my-folder/my-document.pdf">Download</a>

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.

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:

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

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

Valid: ISO 8601 date format

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

Invalid: Missing T separator and using AM/PM

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

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

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

Invalid: Informal time string

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

Valid: Simple time value

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

Invalid: Non-standard duration

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

Valid: ISO 8601 duration

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

Valid: Date-time with timezone offset

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

Valid: Using only the month

<p>Published in <time datetime="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.

The target attribute on the <area> element tells the browser where to display the linked resource — in the current tab, a new tab, a parent frame, or a named <iframe>. According to the WHATWG HTML living standard, a valid navigable target must be either a keyword beginning with an underscore (_self, _blank, _parent, _top) or a name that is at least one character long. An empty string ("") satisfies neither condition, so the W3C validator reports:

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

This commonly happens when templating engines or CMS platforms output target="" as a default, or when a value is conditionally set but the logic fails to produce a result.

Why this matters

• Standards compliance. An empty target violates the HTML specification and produces a validation error.
• Unpredictable browser behavior. While most browsers treat an empty target the same as _self, this is not guaranteed by the spec. Relying on undefined behavior can lead to inconsistencies across browsers or future versions.
• Code clarity. An empty target signals unclear intent. Removing it or using an explicit keyword makes the code easier to understand and maintain.

How to fix it

1. Remove the target attribute if you want the link to open in the same browsing context. This is the default behavior, equivalent to target="_self".
2. Use a valid keyword like _self, _blank, _parent, or _top if you need specific navigation behavior.
3. Use a named browsing context (e.g., target="contentFrame") if you want to direct the link to a specific <iframe> or window. The name must be at least one character long.
4. Fix your template logic if the empty value is being generated dynamically. Ensure the target attribute is only rendered when a non-empty value is available.

Examples

Invalid: empty target attribute

This triggers the validation error because target is set to an empty string:

<img src="floor-plan.png" usemap="#rooms" alt="Floor plan">

<map name="rooms">

<area shape="rect" coords="10,10,100,60" href="/kitchen" alt="Kitchen" target="">

</map>

Fixed: remove target for default behavior

If you want the link to open in the same tab (the default), simply remove the target attribute:

<img src="floor-plan.png" usemap="#rooms" alt="Floor plan">

<map name="rooms">

<area shape="rect" coords="10,10,100,60" href="/kitchen" alt="Kitchen">

</map>

Fixed: use a valid keyword

Use _self to be explicit about same-tab navigation, or _blank to open in a new tab:

<img src="floor-plan.png" usemap="#rooms" alt="Floor plan">

<map name="rooms">

<area shape="rect" coords="10,10,100,60" href="/kitchen" alt="Kitchen" target="_self">

<area shape="rect" coords="110,10,200,60" href="/bedroom" alt="Bedroom" target="_blank">

</map>

Fixed: target a named <iframe>

If you want to load the linked resource into a specific <iframe>, give the <iframe> a name attribute and reference it in target:

<iframe name="detailView" src="about:blank" title="Room details"></iframe>

<img src="floor-plan.png" usemap="#rooms" alt="Floor plan">

<map name="rooms">

<area shape="rect" coords="10,10,100,60" href="/kitchen" alt="Kitchen" target="detailView">

</map>

Fixed: conditionally render target in templates

If your target value comes from a variable, make sure the attribute is only output when the value is non-empty. For example, in a Jinja-style template:

<area shape="rect" coords="10,10,100,60" href="/kitchen" alt="Kitchen"

{% if target_value %} target="{{ target_value }}"{% endif %}>

This prevents target="" from appearing in your HTML when no value is set.

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

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

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

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

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

How to Fix It

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

Examples

❌ Invalid: Empty max attribute

<label for="quantity">Quantity:</label>

<input type="number" id="quantity" name="quantity" max="">

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

✅ Fixed: Providing a valid numeric value

<label for="quantity">Quantity:</label>

<input type="number" id="quantity" name="quantity" max="100">

✅ Fixed: Removing the attribute entirely

<label for="quantity">Quantity:</label>

<input type="number" id="quantity" name="quantity">

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

❌ Invalid: Empty max on a date input

<label for="end-date">End date:</label>

<input type="date" id="end-date" name="end-date" max="">

✅ Fixed: Valid date value for max

<label for="end-date">End date:</label>

<input type="date" id="end-date" name="end-date" max="2025-12-31">

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

Fixing dynamic templates

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

<input type="number" id="price" name="price"

{% if max_price %}max="{{ max_price }}"{% endif %}>

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

Spaces in the src attribute of a <source> element are not valid URL characters and must be encoded or removed.

URLs follow strict syntax rules defined in RFC 3986. A space character is not permitted in any part of a URL path. When a file name or path contains spaces, you must replace each space with %20 (the percent-encoded form) or rename the file to avoid spaces altogether.

This applies to all elements that accept a URL, including <source>, <img>, <a>, <script>, and <link>. Browsers often handle spaces gracefully by encoding them automatically, but the HTML is still technically invalid and can cause issues in some contexts, such as when URLs are copied, shared, or processed by other tools.

The best practice is to avoid spaces in file names entirely. Use hyphens (-) or underscores (_) instead. If you can't rename the files, percent-encode the spaces.

Bad Example

<video controls>

<source src="videos/my cool video.mp4" type="video/mp4">

</video>

Good Example — Percent-Encoded Spaces

<video controls>

<source src="videos/my%20cool%20video.mp4" type="video/mp4">

</video>

Good Example — No Spaces in File Name

<video controls>

<source src="videos/my-cool-video.mp4" type="video/mp4">

</video>

Spaces in the src attribute of an img element are not valid URL characters and must be encoded as %20 or replaced with hyphens/underscores.

URLs follow the rules defined in RFC 3986, which does not allow literal space characters in any part of a URL. When a browser encounters a space in a src value, it may try to percent-encode it automatically, but this behavior is not guaranteed across all contexts. The W3C validator flags this because the HTML specification requires attribute values containing URLs to hold valid URL strings.

There are two ways to fix this: rename the file to remove spaces, or percent-encode the spaces as %20. Renaming is the better long term approach because it avoids encoding issues entirely and makes URLs easier to read and share.

Examples

Invalid: space in the file name

<img src="my photo.jpg" alt="A photo">

Valid: percent-encoded space

<img src="my%20photo.jpg" alt="A photo">

Valid: renamed file with no spaces

<img src="my-photo.jpg" alt="A photo">

A mailto: link must not contain spaces between the colon and the email address.

The href attribute on an <a> element accepts mailto: URLs as defined in RFC 6068. The email address must immediately follow the colon with no whitespace. Browsers may still attempt to open the mail client, but the space makes the URL technically invalid and triggers a W3C validation error.

This applies to all parts of the mailto: URL. Spaces before the address, between multiple addresses, or before query parameters like ?subject= are all invalid. If you need to include a space in a subject or body parameter, encode it as %20.

HTML examples

Invalid

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

Valid

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

An <li> element inside a <ul>, <ol>, or <menu> must not be assigned any ARIA role other than listitem.

When an <li> sits inside a standard list container (<ul>, <ol>, or <menu>) that has no explicit role attribute, the browser already treats the <li> as having an implicit role of listitem. Assigning a different role, such as role="presentation", role="option", or role="tab", contradicts the semantics of the parent-child relationship between the list and its items. Screen readers and other assistive technologies rely on this relationship to convey list structure to users.

The same restriction applies when the parent element has role="list" set explicitly. In that context, child <li> elements are still expected to carry only the listitem role.

If you need a different role on the items, restructure the markup. For example, use <div> elements instead of <ul> and <li>, and apply the appropriate roles directly. Or, if the items genuinely are list items, remove the conflicting role attribute.

Examples

Invalid: li with a non-listitem role inside a ul

<ul>

<li role="tab">Dashboard</li>

<li role="tab">Settings</li>

<li role="tab">Profile</li>

</ul>

Fixed: use appropriate elements when a different role is needed

If the items are tabs, drop the list markup and use elements that match the intended semantics:

<div role="tablist">

<button role="tab" aria-selected="true">Dashboard</button>

<button role="tab" aria-selected="false">Settings</button>

<button role="tab" aria-selected="false">Profile</button>

</div>

Fixed: keep the list but remove the conflicting role

If the content really is a list, remove the extra role:

<ul>

<li>Dashboard</li>

<li>Settings</li>

<li>Profile</li>

</ul>

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:

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

Examples

❌ Invalid: empty target attribute

<a href="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:

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

✅ Fixed: use _blank to open in a new tab

<a href="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:

<a href="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:

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

<a href="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:

<!-- Instead of always outputting target -->

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

<!-- Only include target when a value exists -->

<a href="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.

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:

1. Check the email address for typos. Remove any accidental spaces in the local part (before @) or the domain part (after @).
2. Percent-encode spaces in query parameters. If you're using subject, body, or cc parameters in the mailto: URI, replace spaces with %20.
3. 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:

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

Valid — corrected email address

Remove the space to form a valid email address:

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

Invalid — space in the local part

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

Valid — space removed from local part

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

Invalid — unencoded spaces in subject parameter

<a href="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:

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

Valid — full mailto with multiple parameters

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

Report a Bug

</a>

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>

<li>Item one</li>

<li>Item two</li>

</div>

</ul>

✅ Correct:

<ul>

<li>Item one</li>

<li>Item two</li>

</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.

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

</p>

✅ Correct:

<p>Here is some text.</p>

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

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

<p>

Here is some text.

<span class="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>

<td>Name</td>

<td>Age</td>

</table>

✅ Correct:

<table>

<tr>

<td>Name</td>

<td>Age</td>

</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:

<a href="/dashboard">

<button>Go to Dashboard</button>

</a>

✅ Correct (choose one or the other):

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

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

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

Wrapping elements inside <select>

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

❌ Incorrect:

<select>

<div>

<option>Apple</option>

<option>Banana</option>

</div>

</select>

✅ Correct:

<select>

<optgroup label="Fruits">

<option>Apple</option>

<option>Banana</option>

</optgroup>

</select>

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:

1. 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".
2. 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

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

❌ Incorrect: other invalid values

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

<input type="email" name="email" maxlength="none">

<input type="text" name="bio" maxlength="10.5">

✅ Correct: explicit maximum length

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

✅ Correct: omit the attribute when no limit is needed

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

✅ Correct: maxlength on a textarea

<textarea name="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:

<!-- Only render maxlength if the value is set -->

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

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

The min attribute defines the minimum acceptable value for form input types such as number, range, date, time, datetime-local, week, and month. When the browser or the W3C validator encounters min="", it attempts to parse the empty string as a floating point number and fails because the empty string is not a valid representation of any number according to the HTML specification's rules for parsing floating point numbers.

This issue commonly arises when templating engines or server-side code dynamically set the min attribute but output an empty value when no minimum is configured, or when developers add the attribute as a placeholder intending to fill it in later.

Why this matters

• Standards compliance: The HTML specification explicitly requires the min attribute's value to be a valid floating point number (for numeric types) or a valid date/time string (for date/time types). An empty string satisfies neither requirement.
• Unpredictable browser behavior: When browsers encounter an invalid min value, they typically ignore the attribute entirely. This means your intended constraint silently disappears, potentially allowing users to submit out-of-range values.
• Accessibility concerns: Assistive technologies may rely on min and max to communicate valid input ranges to users. An invalid value can lead to confusing or missing guidance for screen reader users.
• Form validation issues: Built-in browser validation using the Constraint Validation API depends on valid min values. An empty string can cause the browser's native validation to behave inconsistently across different browsers.

How to fix it

You have two straightforward options:

1. Provide a valid value: Set min to the actual minimum number or date/time string you want to enforce.
2. Remove the attribute: If no minimum constraint is needed, simply omit the min attribute. The input will then accept any value within its type's natural range.

If your min value comes from dynamic server-side or JavaScript logic, make sure the attribute is only rendered when a valid value is available, rather than outputting an empty string as a fallback.

Examples

❌ Invalid: empty string for min

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

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

✅ Fixed: provide a valid number

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

✅ Fixed: remove min if no minimum is needed

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

❌ Invalid: empty min on a range input

<input type="range" min="" max="100" step="5">

✅ Fixed: valid min on a range input

<input type="range" min="0" max="100" step="5">

❌ Invalid: empty min on a date input

<input type="date" min="" max="2025-12-31">

For date inputs, min must be a valid date string in YYYY-MM-DD format — an empty string is equally invalid here.

✅ Fixed: valid min on a date input

<input type="date" min="2025-01-01" max="2025-12-31">

Handling dynamic values in templates

If you're using a templating language and the minimum value might not always exist, conditionally render the attribute rather than outputting an empty value. For example, in a generic template pseudocode:

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

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

<!-- Only include it when a value is available: -->

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

In practice, use your templating engine's conditional logic (e.g., {% if min_value %}min="{{ min_value }}"{% endif %} in Jinja2, or similar constructs) to ensure min is only present when it holds a valid value.

Spaces in the href attribute of a <link> element are not valid URL characters and must be encoded as %20.

URLs follow the syntax defined in RFC 3986, which does not allow literal space characters in any component of a URI. The <link> element points to external resources such as stylesheets, icons, and preloaded files, and its href must be a valid URL. A browser often corrects the space on its own, but the markup is still invalid, so the validator flags it.

To fix the issue, replace each space in the URL with %20, the percent-encoded form of the space character. If the resource genuinely lives at a path that contains spaces, the encoding is still required for the reference to be valid.

This often appears with files whose names contain spaces, like an icon exported as Capture 2026-06-23.webp, or with folder names that include spaces.

HTML examples

Invalid: space in href

<link rel="icon" href="https://example.com/files/Capture 2026-06-23.webp">

Valid: spaces encoded as %20

<link rel="icon" href="https://example.com/files/Capture%202026-06-23.webp">

If you control the file or directory names, renaming them to avoid spaces is a simpler long term fix. Use hyphens or underscores instead:

<link rel="icon" href="https://example.com/files/capture-2026-06-23.webp">

The HTML specification defines a strict content model for the <ul> (unordered list) element: its permitted content is zero or more <li> elements, optionally intermixed with <script> and <template> elements. A <div> is not among these allowed children, so placing one directly inside a <ul> produces a validation error.

This issue commonly arises when developers try to group or wrap list items for styling or layout purposes. For example, you might want to add a container around certain <li> elements for flexbox or grid alignment, or you might be using a templating system that injects wrapper <div> elements into your list markup.

Why this matters

• Browser parsing inconsistencies: When browsers encounter invalid nesting, they attempt to fix the DOM structure automatically, but different browsers may handle it differently. This can lead to unexpected rendering where list items appear outside their intended container or styles break unpredictably.
• Accessibility: Screen readers and assistive technologies rely on correct semantic structure to convey list relationships to users. A <div> breaking the <ul> → <li> relationship can cause assistive tools to misinterpret or skip list content entirely.
• Standards compliance: Invalid HTML can cause cascading parser errors — note that the validator message says "Suppressing further errors from this subtree," meaning additional issues within that structure may be hidden from you.

How to fix it

1. Move the <div> inside the <li>: If you need a wrapper for styling, place it inside the list item rather than around it.
2. Remove the <div> entirely: If it serves no purpose, simply remove it and let the <li> elements sit directly inside the <ul>.
3. Use CSS on the <li> elements: In many cases, you can apply the styles you need directly to the <li> elements without an extra wrapper.
4. Use role="list" on a <div> parent: If your layout truly requires <div> wrappers, consider restructuring with ARIA roles, though native semantic elements are always preferred.

Examples

❌ Incorrect: <div> as a direct child of <ul>

<ul>

<div>

<li>Apples</li>

<li>Bananas</li>

</div>

<div>

<li>Carrots</li>

<li>Dates</li>

</div>

</ul>

✅ Correct: Move the <div> inside each <li>

<ul>

<li><div>Apples</div></li>

<li><div>Bananas</div></li>

<li><div>Carrots</div></li>

<li><div>Dates</div></li>

</ul>

✅ Correct: Remove the <div> entirely

<ul>

<li>Apples</li>

<li>Bananas</li>

<li>Carrots</li>

<li>Dates</li>

</ul>

❌ Incorrect: Using a <div> as a styling wrapper around list items

<ul class="product-list">

<div class="row">

<li>Product A</li>

<li>Product B</li>

<li>Product C</li>

</div>

</ul>

✅ Correct: Apply layout styles directly to the <ul> and <li> elements

<ul class="product-list row">

<li>Product A</li>

<li>Product B</li>

<li>Product C</li>

</ul>

❌ Incorrect: Template or component wrapper inserting a <div>

This often happens in frameworks where a component renders a wrapping <div>:

<ul>

<div class="list-item-wrapper">

<li>Item 1</li>

</div>

<div class="list-item-wrapper">

<li>Item 2</li>

</div>

</ul>

✅ Correct: Move the wrapper class to the <li> itself

<ul>

<li class="list-item-wrapper">Item 1</li>

<li class="list-item-wrapper">Item 2</li>

</ul>

The same rule applies to <ol> (ordered list) elements — they share the same content model restriction. Always ensure that <li> is the direct child of <ul> or <ol>, and place any additional wrapper elements inside the <li> rather than around it.

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

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

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

Why this matters

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

How to fix it

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

Examples

❌ Invalid: empty maxlength value

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

<label for="msg">Message</label>

<textarea id="msg" name="message" maxlength=""></textarea>

❌ Invalid: non-numeric maxlength value

Strings, decimals, and negative numbers are also invalid.

<label for="bio">Bio</label>

<textarea id="bio" name="bio" maxlength="none"></textarea>

<label for="notes">Notes</label>

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

✅ Fixed: specific integer value

Set maxlength to the desired character limit.

<label for="msg">Message (max 200 characters)</label>

<textarea id="msg" name="message" maxlength="200"></textarea>

✅ Fixed: attribute omitted entirely

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

<label for="msg">Message</label>

<textarea id="msg" name="message"></textarea>

✅ Fixed: conditional rendering in a template

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

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

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

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

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

<label for="feedback">Feedback</label>

<textarea id="feedback" name="feedback" maxlength="500"></textarea>

URLs follow strict syntax rules defined by RFC 3986, which does not allow literal space characters. When the W3C validator encounters a space in the src attribute of an <img> element, it reports it as an illegal character in the scheme data. While most modern browsers will attempt to handle spaces in URLs by automatically encoding them, relying on this behavior is not standards-compliant and can lead to broken images in certain contexts, such as when URLs are processed by other tools, APIs, or older browsers.

This issue commonly arises when file names contain spaces (e.g., my photo.jpg) and the path is copied directly into the HTML. It can also happen when a URL is incorrectly constructed by concatenating strings with unencoded values.

Beyond validation, unencoded spaces can cause real problems. A URL with a space may break when shared, copied, or passed through redirects. Email clients and messaging apps may truncate the URL at the space. Search engine crawlers might fail to index the resource correctly.

How to fix it

There are several ways to resolve this issue:

1. Percent-encode spaces as %20 — Replace every literal space in the URL with %20.
2. Rename the file — Remove spaces from file names entirely, using hyphens (-), underscores (_), or camelCase instead.
3. Use proper URL encoding functions — If generating URLs dynamically (e.g., in JavaScript or a server-side language), use built-in encoding functions like encodeURI() or encodeURIComponent().

Renaming files to avoid spaces is generally the best long-term practice, as it prevents encoding issues across your entire workflow.

Examples

❌ Invalid: spaces in the src attribute

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

<img src="/assets/blog posts/header image.png" alt="Blog header">

Both of these will trigger the validation error because the src value contains literal space characters.

✅ Fixed: spaces encoded as %20

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

<img src="/assets/blog%20posts/header%20image.png" alt="Blog header">

✅ Fixed: file renamed to remove spaces

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

<img src="/assets/blog-posts/header-image.png" alt="Blog header">

A note on + vs %20

You may see spaces encoded as + in some contexts (e.g., query strings in form submissions using application/x-www-form-urlencoded). However, + is not a valid substitute for a space in a URL path. Always use %20 for spaces in the src attribute.

<!-- ❌ Incorrect: + does not represent a space in a URL path -->

<img src="images/my+photo.jpg" alt="A vacation photo">

<!-- ✅ Correct -->

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

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

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

How to fix it

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

Examples

Incorrect: callto: with spaces and slashes

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

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

Incorrect: tel: with spaces

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

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

Correct: tel: with digits only

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

Correct: International number with + prefix

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

Correct: Using hyphens for readability

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

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

Displaying a formatted number to the user

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

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

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

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

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

Why this matters

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

How to fix it

Choose the appropriate fix depending on your intent:

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

Examples

❌ Invalid: step set to zero

<label for="price">Price:</label>

<input id="price" name="price" type="number" step="0" min="0">

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

✅ Fixed: using a specific step value

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

<label for="price">Price:</label>

<input id="price" name="price" type="number" step="0.01" min="0">

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

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

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

<label for="price">Price:</label>

<input id="price" name="price" type="number" step="any" min="0">

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

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

<label for="quantity">Quantity:</label>

<input id="quantity" name="quantity" type="number" step="2" min="1.3">

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

✅ Fixed: removing the attribute entirely

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

<label for="amount">Amount:</label>

<input id="amount" name="amount" type="number" min="0">

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

URLs follow strict syntax rules defined by RFC 3986, which does not permit literal space characters anywhere in the URI — including path segments, query strings, and fragment identifiers. When the W3C HTML Validator encounters a space in the src attribute of a <script> element, it flags it as an illegal character because the attribute value is not a valid URL.

While most modern browsers will silently fix this by encoding the space before making the request, 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 a literal space is technically malformed.
• Cross-browser reliability: Not all user agents, proxies, or CDNs handle malformed URLs the same way. What works in one browser may fail in another context.
• Interoperability: Other tools that consume your HTML — such as linters, crawlers, screen readers, and build pipelines — may not be as forgiving as browsers.
• Copy-paste and linking issues: Literal spaces in URLs cause problems when users copy links or when URLs appear in plain-text contexts like emails, where the space may break the URL in two.

How to fix it

You have three options, listed from most recommended to least:

1. Rename the file or directory to eliminate spaces entirely (e.g., use hyphens or underscores). This is the cleanest solution.
2. Percent-encode the space as %20 in the src attribute value.
3. Use a build tool or bundler that generates references with properly encoded or space-free paths automatically.

Avoid using + as a space replacement in path segments. The + character represents a space only in application/x-www-form-urlencoded query strings, not in URL path segments.

Examples

❌ Invalid: space in the path segment

<script src="https://example.com/media assets/app.js"></script>

The space between media and assets makes this an invalid URL.

✅ Fixed: percent-encode the space

<script src="https://example.com/media%20assets/app.js"></script>

Replacing the space with %20 produces a valid, standards-compliant URL.

✅ Better: rename to avoid spaces entirely

<script src="https://example.com/media-assets/app.js"></script>

Using a hyphen (or underscore) instead of a space is the preferred approach. It keeps URLs clean, readable, and free of encoding issues.

❌ Invalid: space in a local relative path

This issue isn't limited to absolute URLs. Relative paths trigger the same error:

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

✅ Fixed: encode or rename the local file

<script src="js/my%20script.js"></script>

Or, better yet:

<script src="js/my-script.js"></script>

Multiple spaces and other special characters

If a URL contains multiple spaces or other special characters, each one must be individually encoded. For example, { becomes %7B and } becomes %7D. A quick reference for common characters:

<!-- Invalid -->

<script src="libs/my library [v2].js"></script>

<!-- Valid -->

<script src="libs/my%20library%20%5Bv2%5D.js"></script>

<!-- Best: rename the file -->

<script src="libs/my-library-v2.js"></script>

Note that this same rule applies to the src attribute on other elements like <img>, <iframe>, <audio>, and <video>, as well as the href attribute on <a> and <link>. Whenever you reference a URL in HTML, make sure it contains no literal spaces.

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.

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

Common causes of this issue include:

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

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

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

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

Examples

Incorrect: Space in the path

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

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

Fixed: Percent-encode the space

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

Better fix: Rename the file to avoid spaces

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

Incorrect: Template placeholder left unresolved

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

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

Fixed: Use a valid resolved path

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

Incorrect: Backslash used as path separator

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

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

Fixed: Use forward slashes

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

Incorrect: Pipe character in the URL

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

Fixed: Percent-encode the pipe character

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

Full valid document example

<!DOCTYPE html>

<html lang="en">

<head>

<meta charset="utf-8">

<title>My Webpage</title>

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

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

</head>

<body>

<h1>Welcome to my webpage!</h1>

<p>Here is some content.</p>

</body>

</html>

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

The <dialog> element triggers an informational warning from the W3C validator, not an error. The markup is valid HTML, and no code change is needed to resolve this message.

The <dialog> element is a native HTML element for modal and non-modal dialog boxes. It was part of the HTML specification for years before all major browsers implemented it. As of 2022, all major browsers (Chrome, Firefox, Safari, and Edge) support <dialog> natively. The W3C validator warning is outdated for most practical purposes, since browser support is now widespread.

The <dialog> element provides built-in features that are difficult to replicate with custom markup: a showModal() method that creates a top-layer modal with a backdrop, automatic focus trapping, and Esc key dismissal. It also exposes the correct ARIA role (dialog) by default, which improves accessibility without extra attributes.

If you still need to support older browsers (such as Internet Explorer or pre-2022 Safari), you can include the dialog-polyfill library. Otherwise, the warning can be safely ignored.

HTML example

<dialog id="confirm">

<form method="dialog">

<p>Are you sure?</p>

<button value="no">Cancel</button>

<button value="yes">Confirm</button>

</form>

</dialog>

<button onclick="document.getElementById('confirm').showModal()">

Open dialog

</button>

Using method="dialog" on the form allows the dialog to close automatically when a button inside it is clicked, with the button's value available through the dialog's returnValue property.