HTML Guides

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

Bad value X for attribute “href” on element “link”: Illegal character in query

URLs used in HTML attributes must follow the URL Living Standard, which defines a specific set of characters that are allowed in each part of a URL. The query component of a URL — everything after the ? — permits most printable ASCII characters, but certain characters are still considered illegal and must be percent-encoded. When the W3C validator encounters one of these forbidden characters in the href of a <link> element, it raises this error.

Common characters that trigger this issue include:

Character	Percent-encoded
`	` (pipe)
`[` (left bracket)	`%5B`
`]` (right bracket)	`%5D`
`{` (left brace)	`%7B`
`}` (right brace)	`%7D`
`^` (caret)	`%5E`
` (backtick)	`%60`
(space)	`%20`

Why this matters

While many modern browsers are lenient and will silently fix malformed URLs, relying on this behavior is risky. Invalid URLs can cause problems in several ways:

Inconsistent browser behavior: Not all user agents handle illegal characters the same way, which can lead to broken stylesheets or resources failing to load.
Interoperability issues: Proxies, CDNs, and other intermediaries may reject or mangle URLs with illegal characters.
Standards compliance: Valid HTML requires valid URLs in attributes. An illegal character in the href makes the entire document non-conforming.
Copy-paste and sharing reliability: Malformed URLs are more likely to break when shared across systems, emails, or documentation.

How to fix it

Identify the illegal characters in your URL's query string and replace each one with its percent-encoded equivalent. If you're generating URLs programmatically, use a proper URL encoding function (e.g., encodeURIComponent() in JavaScript, urlencode() in PHP, or urllib.parse.quote() in Python) to ensure all special characters are encoded correctly.

Examples

❌ Illegal pipe character in the query string

This is a common pattern seen with Google Fonts URLs that use | to separate font families:

✅ Pipe character percent-encoded

❌ Square brackets in the query string

Some APIs or frameworks use bracket notation in query parameters:

✅ Square brackets percent-encoded

❌ Space character in the query string

✅ Space character percent-encoded

Note that for Google Fonts specifically, the modern API (v2) uses a different URL format that avoids the pipe character altogether. Where possible, consider updating to the latest version of an API rather than just encoding the old URL.

Bad value X for attribute “http-equiv” on element “meta”.

Bad value X for attribute “id” on element “pattern”: Not a valid XML 1.0 name.

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

XML 1.0 Name Rules

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

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

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

Why This Matters

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

How to Fix

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

Examples

❌ Invalid: `id` starts with a digit

<defs>

</pattern>

</defs>

</svg>

❌ Invalid: `id` starts with a hyphen

<defs>

</pattern>

</defs>

</svg>

❌ Invalid: `id` contains special characters

<defs>

</pattern>

</defs>

</svg>

✅ Valid: `id` starts with a letter

<defs>

</pattern>

</defs>

</svg>

✅ Valid: `id` starts with an underscore

<defs>

</pattern>

</defs>

</svg>

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

<defs>

</pattern>

</defs>

</svg>

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

Bad value X for attribute “integrity” on element “script”: Invalid base64-value (should be multiple of 4 bytes).

The integrity attribute enables Subresource Integrity (SRI), a security feature that lets browsers verify that a fetched resource (such as a JavaScript file from a CDN) has not been tampered with. The attribute value follows the format [algorithm]-[base64-encoded hash], where the algorithm is typically sha256, sha384, or sha512, and the hash is a base64 representation of the file's cryptographic digest.

Base64 encoding works by converting binary data into a string of ASCII characters drawn from a 64-character alphabet. A key property of valid base64 is that the encoded output must always have a length that is a multiple of 4. When the raw binary data doesn't divide evenly, the output is padded with one or two = characters to reach the correct length. If the base64 string in your integrity attribute has an incorrect length — for instance, it was truncated, manually edited, or copied incompletely — the validator will flag it as invalid.

This matters for several reasons:

Security: If the integrity value is malformed, the browser cannot verify the resource. Depending on the browser, it may block the script entirely, breaking your site's functionality.
Standards compliance: The HTML specification requires the hash portion to be a valid base64 string. An invalid value is a conformance error.
Reliability: A malformed hash will never match any file, so the SRI check will always fail, effectively making the script unusable.

Common causes of this error include:

Copying the hash value incompletely (missing trailing = padding or other characters).
Manually modifying the hash string.
Using a tool that produced an incorrectly encoded output.
Mixing up base64 and base64url encodings (base64url uses - and _ instead of + and /, and often omits padding).

To fix the issue, regenerate the correct SRI hash for the exact file being referenced. You can do this with the command line:

openssl dgst -sha384 -binary script.js | openssl base64 -A

Or using shasum and base64:

shasum -b -a 384 script.js | awk '{print $1}' | xxd -r -p | base64

Online tools like the SRI Hash Generator can also produce the correct value. After generating the hash, prepend the algorithm prefix (e.g., sha384-) and verify that the base64 portion has a length divisible by 4.

Examples

Incorrect: Malformed base64 value

The hash below is not a valid base64 string — its length is not a multiple of 4, and it contains the character !, which is not in the base64 alphabet.

<script

src="https://cdn.example.com/library.js"

integrity="sha384-BadBase64Value!"

crossorigin="anonymous"></script>

Incorrect: Truncated hash missing padding

This hash has been accidentally truncated, losing the trailing = padding characters that make it a valid base64 string.

<script

src="https://cdn.example.com/library.js"

integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9Gh8S7f1bE0q/PuF3LtHac+obYTK2B69B1a8t"

crossorigin="anonymous"></script>

Correct: Properly formatted SRI hash

The base64 hash is the correct length (a multiple of 4) and uses only valid base64 characters. The trailing T completes the final 4-character group without needing padding in this case, but other hashes may end with = or ==.

<script

src="https://cdn.example.com/library.js"

integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9Gh8S7f1bE0q/PuF3LtHac+obYTK2B69B1a8tT"

crossorigin="anonymous"></script>

Correct: Multiple hashes for fallback

You can provide multiple hash values separated by spaces. Each one must be independently valid base64 with the correct length.

<script

src="https://cdn.example.com/library.js"

integrity="sha256-BpfGp+xz0kN9mMKoECQbGRab7fMi/dsRZ7Sy7LVd3CE= sha384-oqVuAfXRKap7fdgcCY5uykM6+R9Gh8S7f1bE0q/PuF3LtHac+obYTK2B69B1a8tT"

crossorigin="anonymous"></script>

Always ensure the hash is generated from the exact file the src attribute points to. If the CDN serves a different version or a minified variant, the hash will not match, and the browser will block the resource regardless of whether the base64 encoding is valid.

Bad value X for attribute “lang” on element “html”: The language subtag X is not a valid ISO language part of a language tag.

The lang attribute on the <html> element tells browsers, screen readers, and search engines what language the page content is written in. Its value must follow the BCP 47 standard, which uses ISO 639 language codes as the primary language subtag. When the validator reports that a language subtag "is not a valid ISO language part of a language tag," it means the code you provided doesn't match any recognized language in the ISO 639 registry.

Common Causes

Typos in the language code

A simple misspelling like emg instead of en, or fre instead of fr, will trigger this error.

Using a country code instead of a language code

Country codes (ISO 3166) and language codes (ISO 639) are different standards. For example, uk is the country code for the United Kingdom, but it's also the valid language code for Ukrainian. Using gb (Great Britain) as a language would be invalid. Similarly, us is not a language code — you need en for English or en-US for American English specifically.

Using made-up or deprecated codes

Codes like xx, en-UK, or other non-standard values will fail validation. Note that while en-US and en-GB are valid (language-region format), en-UK is not because UK is not the correct ISO 3166-1 region subtag for the United Kingdom — GB is.

Why This Matters

Accessibility: Screen readers rely on the lang attribute to select the correct pronunciation rules and voice profile. An invalid language code can cause assistive technology to mispronounce content or fall back to a default language.
SEO: Search engines use the lang attribute as a signal for serving the right content to users in the appropriate language and region.
Browser behavior: Browsers use the language tag for spell-checking, hyphenation, font selection, and other language-sensitive rendering decisions.

How to Fix It

Identify the language your page is written in.
Look up the correct ISO 639-1 two-letter code (preferred) or ISO 639-2 three-letter code for that language.
If you need to specify a regional variant, append a hyphen and the ISO 3166-1 region code (e.g., pt-BR for Brazilian Portuguese).
Replace the invalid value in the lang attribute.

Some commonly used valid language codes:

Language	Code
English	`en`
English (US)	`en-US`
English (UK)	`en-GB`
Spanish	`es`
French	`fr`
German	`de`
Portuguese (Brazil)	`pt-BR`
Chinese (Simplified)	`zh-Hans`
Japanese	`ja`
Arabic	`ar`

Examples

❌ Invalid: Typo in language code

❌ Invalid: Country code used instead of language code

❌ Invalid: Incorrect region subtag

❌ Invalid: Made-up language code

✅ Valid: Correct two-letter language code

✅ Valid: Language with region subtag

✅ Valid: Full document with proper lang attribute

<!DOCTYPE html>

<head>

</head>

<body>

<p>Bonjour le monde !</p>

</body>

</html>

You can verify your language tag using the IANA Language Subtag Registry or the BCP 47 Language Subtag Lookup tool to ensure your code is valid before updating your markup.

Bad value X for attribute “lang” on element “y”: Bad script subtag.

Bad value X for attribute “loading” on element “img”.

loading
img

The loading attribute tells the browser how to prioritize loading an image. Setting it to "lazy" defers loading until the image is near the viewport, which can improve page performance by reducing initial load time and saving bandwidth. Setting it to "eager" instructs the browser to load the image immediately, regardless of its position on the page. When the attribute is omitted, the browser defaults to "eager" behavior.

Any value other than these two exact lowercase strings is invalid according to the HTML specification. Common mistakes include using numeric values like "1" or "0", boolean-style values like "true" or "false", uppercase variants like "Lazy", or misspellings like "laxy". When a browser encounters an invalid value, it ignores the attribute and falls back to the default eager loading behavior. While this means the page won't break visually, the intended lazy-loading optimization won't take effect, and the HTML will fail W3C validation.

This matters for a few reasons:

Performance: If you intended to use "lazy" but provided an invalid value, your images will all load eagerly, defeating the purpose and potentially degrading page speed.
Standards compliance: Invalid attribute values signal potential bugs in your markup and can cause issues with tools and parsers that expect well-formed HTML.
Maintainability: Valid, predictable markup is easier to maintain and debug across teams and over time.

To fix the issue, check the loading attribute value and replace it with one of the two valid options. If you want deferred loading, use "lazy". If you want immediate loading (or don't need to specify), use "eager" or simply remove the attribute.

Examples

Invalid values

Each of these will trigger the validation error:

Correct: lazy loading

Use "lazy" for images that are below the fold or not immediately visible to the user:

Correct: eager loading

Use "eager" for critical images that should load right away, such as hero images or logos:

Correct: omitting the attribute

Since "eager" is the default behavior, you can simply remove the attribute if you want immediate loading:

Practical usage in context

A common and effective pattern is to eagerly load above-the-fold images while lazy-loading everything else:

Note that the loading attribute also works on iframe elements with the same two valid values: "lazy" and "eager".

Bad value X for attribute “media” on element “link”: Parse Error.

Bad value X for attribute “media” on element “link”: The media “projection” has been deprecated

The media attribute on a <link> element specifies which media or device types the linked resource (typically a stylesheet) is designed for. It accepts a valid media query or a comma-separated list of media types. In the current CSS specification (Media Queries Level 4), only three media types remain valid: all, screen, and print. All other media types from older specifications — including projection, handheld, tv, tty, braille, embossed, and aural — have been deprecated.

The projection media type was originally intended to target presentation and projector-based displays. In practice, browser support for it was extremely limited (only Opera had meaningful support), and the use case never gained traction. The CSS Working Group deprecated it because the distinction between a "screen" and a "projection" display is no longer meaningful — modern browsers treat projectors, external displays, and monitors uniformly under the screen type.

Why this matters

Standards compliance: Using deprecated media types causes W3C validation errors, which can signal broader code quality issues.
No practical effect: Modern browsers simply ignore unrecognized media types. If projection is the only value in your media attribute, the stylesheet may not load at all in some browsers. If it appears alongside screen, the browser loads the stylesheet based on the screen match and silently discards projection — meaning the deprecated value adds nothing.
Maintainability: Keeping deprecated values in your code can confuse other developers and create the false impression that the stylesheet has special behavior for projectors.

How to fix it

Remove projection from the media attribute value.
If screen or another valid type was already listed alongside projection, keep the valid type.
If projection was the only value, replace it with screen (since projectors are treated as screens by modern browsers).
If the stylesheet should apply universally, remove the media attribute entirely or set it to all.

Examples

Incorrect

Using the deprecated projection media type alongside screen:

Using projection as the sole media type:

Correct

Remove projection and keep the valid screen type:

Replace projection with screen, since projectors are handled as screens:

Target both screens and print:

If the stylesheet should apply to all devices, omit the media attribute (which defaults to all):

Or explicitly set it to all:

Using media queries instead of media types

If you need more granular control over when a stylesheet applies — for example, targeting large displays commonly used for presentations — you can use a media query with feature conditions instead of relying on deprecated media types:

This approach is standards-compliant and gives you far more precise targeting than the old media types ever provided.

Bad value “X” for attribute “media” on element “link”: unrecognized media “X”.

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

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

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

Why this matters

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

How to fix it

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

Examples

Incorrect: using a deprecated media type

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

Incorrect: misspelled media type

Incorrect: malformed media query

The feature expression is missing its surrounding parentheses.

Correct: using valid media types

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

Correct: replacing deprecated types with modern media queries

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

Correct: using complex media queries

Valid media types reference

Media type	Description
`all`	Matches all devices (default when omitted)
`print`	Matches printers and print preview mode
`screen`	Matches screens (computers, tablets, phones)

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

Bad value X for attribute “multiple” on element “input”.

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

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

An invalid value is assigned to the boolean attribute. Boolean attributes in HTML follow strict rules. Valid syntaxes are: the attribute name alone (multiple), an empty string value (multiple=""), or the attribute's own name as the value (multiple="multiple"). Any other value — including multiple="true", multiple="1", or multiple="yes" — is invalid.
The attribute is used on an unsupported input type. Placing multiple on input types like text, number, password, or url is not valid because those types don't define behavior for this attribute. Browsers will simply ignore it, but it still constitutes invalid markup.

Why this matters

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

How to fix it

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

Examples

Invalid: wrong value on a boolean attribute

Invalid: `multiple` on an unsupported input type

Valid: correct usage of `multiple`

Full corrected document

<!DOCTYPE html>

<head>

<title>Upload Form</title>

</head>

<body>

<label for="recipients">Recipients:</label>

<label for="files">Attachments:</label>

</form>

</body>

</html>

Bad value X for attribute “name” on element “iframe”: Browsing context name started with the underscore.

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

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

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

This matters for several reasons:

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

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

Examples

❌ Invalid: name starts with an underscore

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

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

✅ Fixed: underscore removed from the start

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

✅ Fixed: underscore used elsewhere in the name

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

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

❌ Invalid: using a reserved keyword as a frame name

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

✅ Fixed: descriptive name without underscore prefix

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

How to fix

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

Bad value “X” for attribute “novalidate” on element “form”.

Understanding Boolean Attributes in HTML

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

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

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

Why This Matters

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

About the `novalidate` Attribute

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

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

Examples

❌ Invalid: Arbitrary value on `novalidate`

<label>Email:

</label>

<button>Submit</button>

</form>

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

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

✅ Valid: Attribute name alone (recommended)

<label>Email:

</label>

<button>Submit</button>

</form>

✅ Valid: Empty string value

<label>Email:

</label>

<button>Submit</button>

</form>

✅ Valid: Value matching the attribute name

<label>Email:

</label>

<button>Submit</button>

</form>

✅ Valid: Removing the attribute to enable validation

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

<label>Email:

</label>

<button>Submit</button>

</form>

✅ Using `formnovalidate` on a specific button

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

<label>Email:

</label>

<button>Submit</button>

<button formnovalidate>Save Draft</button>

</form>

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

Bad value X for attribute “ping” on element “a”: Must contain only “http” or “https” URLs.

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

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

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

How to fix it

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

Examples

Incorrect: relative URL

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

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

Incorrect: unsupported scheme

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

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

Incorrect: comma-separated URLs

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

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

Correct: single absolute URL

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

Correct: multiple space-separated absolute URLs

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

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

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

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:

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

Incorrect — space in the filename

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

</video>

Fixed — percent-encoding the spaces

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

</video>

Fixed — removing spaces from the path

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

</video>

Fixed — removing spaces from the filename

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

Bad value X for attribute “poster” on element “video”: Illegal character in path segment. “[” is not allowed.

Bad value “X” for attribute “rel” on element “Y”: The string “X” is not an absolute URL.

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

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

Common causes of this error include:

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

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

Examples

Incorrect: Misspelled keyword

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

Correct: Fixed spelling

Incorrect: Non-standard keyword on an anchor

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

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

Correct: Using a recognized keyword

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

Incorrect: Relative URL as a custom link type

Correct: Absolute URL as a custom link type

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

Correct: Common valid `rel` values

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

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

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

Multiple `rel` values

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

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

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

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

Bad value X for attribute “required” on element “input”.

In HTML, boolean attributes like required work differently from what many developers expect. Their presence on an element means the value is true, and their absence means the value is false. According to the WHATWG HTML specification, a boolean attribute's value must either be the empty string or an ASCII case-insensitive match for the attribute's canonical name. For the required attribute, this means the only valid values are "" (empty string) and "required".

A common mistake is writing required="true" or required="false". The value "true" is not a valid boolean attribute value in HTML and will trigger this validation error. Even more confusingly, writing required="false" does not make the input optional — since the attribute is still present, the browser still treats the field as required. This can lead to subtle bugs where a form field appears to be optional in your code but is actually enforced as required by the browser.

This matters for several reasons:

Standards compliance: Invalid attribute values violate the HTML specification and will cause W3C validation errors.
Code clarity: Using non-standard values like "true" or "false" misleads other developers about how the attribute works.
Unexpected behavior: required="false" still makes the field required, which can cause confusing form behavior.

To make a field optional, simply remove the required attribute entirely rather than setting it to "false".

Examples

Incorrect: Invalid values for `required`

These will all trigger the "Bad value for attribute required" validation error:

Correct: Valid uses of the `required` attribute

All three of these forms are valid and make the input required:

Correct: Making a field optional

To make a field optional, remove the attribute entirely:

Full form example

<label for="name">Name (required):</label>

<label for="notes">Notes (optional):</label>

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

</form>

This same rule applies to other boolean attributes in HTML, such as disabled, checked, readonly, multiple, and autofocus. They all follow the same pattern: use the attribute with no value, with an empty string, or with the attribute's own name as the value. Never assign "true" or "false" to them.

Bad value “X” for attribute “sandbox” on element “iframe”: Setting both “allow-scripts” and “allow-same-origin” is not recommended, because it effectively enables an embedded page to break out of all sandboxing.

The sandbox attribute is one of the most powerful security features available for <iframe> elements. When present with no value (or with specific tokens), it applies a strict set of restrictions to the embedded content — blocking scripts, form submissions, popups, same-origin access, and more. You selectively relax these restrictions by adding space-separated tokens like allow-scripts, allow-forms, or allow-popups.

The problem arises specifically when allow-scripts and allow-same-origin are used together. The allow-scripts token lets the embedded page execute JavaScript, while allow-same-origin lets it retain its original origin (rather than being treated as coming from a unique, opaque origin). With both enabled, the embedded page's JavaScript can access the parent page's DOM via window.parent (if they share the same origin) or, more critically, can use JavaScript to programmatically remove the sandbox attribute from its own <iframe> element. Once the attribute is removed, all sandboxing restrictions are lifted, making the sandbox attribute completely pointless.

This is why the W3C validator flags this combination — it's not technically invalid HTML, but it's a security anti-pattern that renders sandboxing ineffective. The WHATWG HTML specification explicitly warns against this combination for the same reason.

How to fix it

The fix depends on what the embedded content actually needs:

If the embedded page needs scripts but not same-origin access: Remove allow-same-origin. The page can still run JavaScript but will be treated as a unique origin, preventing it from accessing cookies, storage, or the parent frame's DOM.
If the embedded page needs same-origin access but not scripts: Remove allow-scripts. The page retains its origin but cannot execute any JavaScript.
If you believe both are required: Reconsider whether sandboxing is the right approach. If the embedded content truly needs both script execution and same-origin access, the sandbox attribute provides no meaningful security benefit, and you may want to use other security mechanisms like Content-Security-Policy headers instead.

Always follow the principle of least privilege — only grant the permissions the embedded content strictly requires.