HTML Guides

The src attribute is invalid on a <script> element whose type marks it as a data block, because the data lives in the element itself and there is nothing to fetch from elsewhere.

When the type attribute is anything other than a JavaScript MIME type, module, importmap, or speculationrules, the browser treats the element as a data block: inline content that other scripts on the page can read, but that is never downloaded or run. The most common example is application/ld+json structured data. The whole point of a data block is that it carries its content between the opening and closing tags, so pointing src at an external file makes no sense and is not allowed.

This usually happens when the type is set for a data block but the markup was copied from a real external script that still carries its src.

Examples

Invalid: src on a data block

<script type="application/ld+json" src="https://example.com/data.json"></script>

Valid: data block with inline content

<script type="application/ld+json">

{

"@context": "https://schema.org",

"@type": "Organization",

"name": "Example"

}

</script>

Remove the src attribute and place the data inline. If the file really is a script to load and run, fix the type value instead: use a JavaScript MIME type, module, or omit the attribute entirely.

A | (pipe) character in the fragment portion of a URL must be percent-encoded as %7C to be valid.

The href attribute on an <a> element must contain a valid URL. According to the URL specification, certain characters — including the pipe | — are not permitted as literal characters in a URL fragment (the part after #). The W3C validator flags this because the browser may handle it inconsistently, and it violates the URL standard.

To fix it, replace every | in the URL with its percent-encoded equivalent: %7C.

HTML Examples

❌ Invalid: literal pipe in fragment

<a href="https://example.com/page#section|one">Link</a>

✅ Valid: percent-encoded pipe in fragment

<a href="https://example.com/page#section%7Cone">Link</a>

If you control the target page, consider redesigning the fragment identifiers to avoid special characters altogether — for example, using hyphens or underscores like #section-one instead.

The href attribute on an <a> element contains a literal pipe character (|), which is not a valid character in a URL according to RFC 3986.

URLs have a defined set of allowed characters. The pipe character (|) is not among them. While most browsers will silently encode the pipe and follow the link anyway, the HTML specification requires that href values contain valid URLs. Characters outside the allowed set must be percent-encoded before being placed in the markup.

The percent-encoded form of | is %7C. Replace every literal | in the URL with %7C to produce a valid href value.

HTML examples

Invalid

<a href="https://example.com/search?fields=name|date|status">Search</a>

Valid

<a href="https://example.com/search?fields=name%7Cdate%7Cstatus">Search</a>

An <input type="button"> element requires a non-empty value attribute because that attribute provides the button's visible label and its accessible name.

Unlike <input type="submit">, which defaults to a browser-provided label like "Submit", <input type="button"> has no default label. Without a value, the button renders as an empty rectangle with no text, and assistive technologies have nothing to announce to the user. The W3C validator flags this as an error because the HTML specification mandates that <input type="button"> must have a value attribute, and it must not be empty.

If you need a button without visible text (for example, an icon-only button), use a <button> element instead. The <button> element can contain child elements like <img> or <span>, and you can give it an accessible name through aria-label or visually hidden text. The <input> element cannot contain child content, so value is its only mechanism for labeling.

Invalid example

<input type="button" onclick="doSomething()">

Valid examples

Add a non-empty value attribute:

<input type="button" value="Click me" onclick="doSomething()">

Or switch to a <button> element, which is more flexible:

<button type="button" onclick="doSomething()">Click me</button>

Microdata is an HTML specification that lets you embed machine-readable data into your content using three main attributes: itemscope, itemtype, and itemprop. The itemscope attribute creates a new item (a group of name-value pairs), itemtype specifies what kind of thing the item is (using a vocabulary URL like Schema.org), and itemprop defines individual properties within that item. These attributes work together — itemprop only makes sense in the context of an itemscope.

When the validator encounters an itemprop attribute on an element that isn't a descendant of any element with itemscope, it has no way to associate that property with an item. The property is essentially orphaned. This is a problem for several reasons:

• Search engines can't use the data. Structured data consumers like Google, Bing, and other crawlers rely on the itemscope/itemprop hierarchy to understand your content. An orphaned itemprop is ignored or misinterpreted.
• Standards compliance. The WHATWG HTML living standard requires that an element with itemprop must be a property of an item — meaning it must have an ancestor with itemscope, or be explicitly referenced via the itemref attribute on an itemscope element.
• Maintenance issues. Orphaned itemprop attributes suggest that surrounding markup was refactored and the microdata structure was accidentally broken.

The most common causes of this error are:

1. Missing itemscope — You added itemprop attributes but forgot to define the containing item with itemscope.
2. Moved elements — An element with itemprop was moved outside of its original itemscope container during a refactor.
3. Copy-paste errors — You copied a snippet that included itemprop but not the parent itemscope.

To fix the issue, either wrap the itemprop elements inside an itemscope container, use itemref to associate distant properties with an item, or remove the itemprop attribute if structured data is not intended.

Examples

Incorrect: itemprop without itemscope

This triggers the validation error because there is no itemscope ancestor:

<div>

<p>My name is <span itemprop="name">Liza</span>.</p>

</div>

Correct: itemprop inside an itemscope container

Adding itemscope (and optionally itemtype) to an ancestor element fixes the issue:

<div itemscope itemtype="https://schema.org/Person">

<p>My name is <span itemprop="name">Liza</span>.</p>

</div>

Correct: nested items with their own scope

When an item contains a sub-item, the nested item needs its own itemscope:

<div itemscope itemtype="https://schema.org/Person">

<p itemprop="name">Liza</p>

<div itemprop="address" itemscope itemtype="https://schema.org/PostalAddress">

<span itemprop="addressLocality">Portland</span>,

<span itemprop="addressRegion">OR</span>

</div>

</div>

Correct: using itemref for properties outside the scope

If you can't restructure your HTML to nest itemprop inside itemscope, use itemref to reference elements by their id:

<div itemscope itemtype="https://schema.org/Person" itemref="user-name"></div>

<p id="user-name">

My name is <span itemprop="name">Liza</span>.

</p>

In this case, the itemprop="name" element is not a descendant of the itemscope element, but the itemref="user-name" attribute explicitly pulls the referenced element's tree into the item, making it valid.

Incorrect: scope broken after refactoring

A common real-world scenario where the error appears after restructuring:

<div itemscope itemtype="https://schema.org/Product">

<span itemprop="name">Widget</span>

</div>

<!-- This was moved out of the div above -->

<span itemprop="price">9.99</span>

Fix this by either moving the element back inside the itemscope container, using itemref, or removing the orphaned itemprop.

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

This issue usually arises from one of these common scenarios:

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

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

Examples

Incorrect: duplicate # in the URL

The double ## makes the fragment identifier invalid:

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

Correct: single # delimiter

Remove the extra # so that pricing is the fragment:

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

Incorrect: extra # inside the fragment

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

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

Correct: percent-encode the literal #

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

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

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

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

Incorrect: programmatic concatenation error

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

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

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

Correct: ensure only one # is present

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

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

Fragment-only links

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

<!-- Incorrect -->

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

<!-- Correct -->

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

The URL specification (defined by WHATWG and RFC 3986) restricts which characters can appear unencoded in different parts of a URL. Square brackets are reserved characters that have a specific meaning in URLs — they are only permitted in the host portion (to wrap IPv6 addresses like [::1]). In the query string, they must be percent-encoded.

This issue commonly appears when frameworks (especially PHP, Ruby on Rails, or JavaScript libraries) generate URLs with array-style query parameters like ?filter[color]=red. While many browsers and servers are lenient and will interpret these URLs correctly, they are technically invalid according to the URL standard. The W3C validator enforces this rule strictly.

Beyond standards compliance, using unencoded square brackets can cause problems in practice. Some HTTP clients, proxies, or caching layers may reject or mangle URLs containing raw brackets. Percent-encoding these characters ensures your URLs are universally safe and interoperable across all systems.

How to fix it

You have two main approaches:

1. Percent-encode the brackets. Replace every [ with %5B and every ] with %5D in the URL. This preserves the parameter structure that your server or framework expects, while making the URL valid.

2. Restructure the query parameters. If your backend allows it, use flat parameter names with dot notation, underscores, or dashes instead of bracket syntax. For example, change size[width] to size_width or size.width.

If you're generating URLs in JavaScript, the built-in encodeURI() function does not encode square brackets. Use encodeURIComponent() on individual parameter names or values, or manually replace [ and ] after constructing the URL.

Examples

❌ Invalid: unencoded square brackets in query string

<img src="/images/photo.jpg?size[width]=300&size[height]=200" alt="A sample photo">

The literal [ and ] characters in the query string trigger the validation error.

✅ Fixed: percent-encoded brackets

<img src="/images/photo.jpg?size%5Bwidth%5D=300&size%5Bheight%5D=200" alt="A sample photo">

Replacing [ with %5B and ] with %5D makes the URL valid. Most servers and frameworks will decode these automatically and interpret the parameters the same way.

✅ Fixed: flat parameter names without brackets

<img src="/images/photo.jpg?size_width=300&size_height=200" alt="A sample photo">

If you control the server-side logic, you can avoid brackets altogether by using a flat naming convention for your parameters.

❌ Invalid: brackets in more complex query strings

<img

src="/api/image?filters[type]=jpeg&filters[quality]=80&crop[x]=10&crop[y]=20"

alt="Processed image">

✅ Fixed: all brackets encoded

<img

src="/api/image?filters%5Btype%5D=jpeg&filters%5Bquality%5D=80&crop%5Bx%5D=10&crop%5By%5D=20"

alt="Processed image">

Encoding in JavaScript

If you build image URLs dynamically, handle the encoding in your code:

// Manual replacement approach

const url = "/images/photo.jpg?size[width]=300&size[height]=200";

const safeUrl = url.replace(/\[/g, "%5B").replace(/\]/g, "%5D");

img.src = safeUrl;

// Using URLSearchParams (automatically encodes brackets)

const params = new URLSearchParams();

params.set("size[width]", "300");

params.set("size[height]", "200");

img.src = `/images/photo.jpg?${params.toString()}`;

Both approaches produce a valid, properly encoded URL that will pass W3C validation.

Why This Matters

While HTML5 is quite permissive with id values (allowing almost anything except spaces), elements within XML-based vocabularies like SVG and MathML are held to stricter rules. When these elements appear in your HTML document, their attributes must still conform to XML 1.0 naming conventions as defined by the relevant specification.

XML 1.0 names must follow these rules:

• Must start with a letter (a–z, A–Z) or an underscore (_)
• Subsequent characters can be letters, digits (0–9), hyphens (-), underscores (_), and periods (.)
• Cannot contain spaces, colons (outside of namespaced contexts), or special characters like @, #, $, !, etc.

This error typically appears when design tools (such as Figma, Illustrator, or Sketch) export SVG files with auto-generated id values that include spaces or other invalid characters. Browsers may still render the content, but relying on non-conformant names can cause problems with CSS selectors, JavaScript's getElementById(), URL fragment references, and accessibility tools that depend on valid identifiers.

How to Fix It

1. Remove spaces — replace them with hyphens or underscores, or use camelCase.
2. Ensure the name starts with a letter or underscore — if it starts with a digit, prefix it with a letter or underscore.
3. Strip out special characters — remove or replace characters like @, #, (, ), etc.
4. Review exported SVG files — if you're embedding SVGs from design tools, clean up the generated id values before adding them to your HTML.

Examples

Invalid: Space in the id value

The space in "Group 270" makes this an invalid XML 1.0 name:

<svg viewBox="0 0 100 100" xmlns="http://www.w3.org/2000/svg">

<g id="Group 270">

<circle cx="50" cy="50" r="40" />

</g>

</svg>

Invalid: Name starts with a digit

XML 1.0 names cannot begin with a number:

<svg viewBox="0 0 100 100" xmlns="http://www.w3.org/2000/svg">

<rect id="1st-rectangle" width="100" height="50" />

</svg>

Invalid: Special characters in the name

Characters like ( and ) are not allowed:

<svg viewBox="0 0 200 100" xmlns="http://www.w3.org/2000/svg">

<path id="icon(home)" d="M10 80 L50 10 L90 80 Z" />

</svg>

Fixed: Valid XML 1.0 names

Replace spaces with hyphens, prefix digit-leading names with a letter, and remove special characters:

<svg viewBox="0 0 200 100" xmlns="http://www.w3.org/2000/svg">

<g id="group-270">

<circle cx="50" cy="50" r="40" />

</g>

<rect id="first-rectangle" width="100" height="50" />

<path id="icon-home" d="M10 80 L50 10 L90 80 Z" />

</svg>

Tip: Cleaning up exported SVGs

Design tools often produce id values like "Frame 42", "Vector (Stroke)", or "123_layer". A quick find-and-replace workflow can fix these before they land in your codebase. You can also use tools like SVGO to optimize and clean up SVG output, including stripping or renaming invalid identifiers.

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

XML 1.0 Name Rules

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

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

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

Why This Matters

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

How to Fix

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

Examples

❌ Invalid: id starts with a digit

<svg width="200" height="200" xmlns="http://www.w3.org/2000/svg">

<defs>

<pattern id="1stPattern" width="10" height="10" patternUnits="userSpaceOnUse">

<circle cx="5" cy="5" r="3" fill="blue" />

</pattern>

</defs>

<rect width="200" height="200" fill="url(#1stPattern)" />

</svg>

❌ Invalid: id starts with a hyphen

<svg width="200" height="200" xmlns="http://www.w3.org/2000/svg">

<defs>

<pattern id="-stripe-bg" width="10" height="10" patternUnits="userSpaceOnUse">

<rect width="5" height="10" fill="red" />

</pattern>

</defs>

<rect width="200" height="200" fill="url(#-stripe-bg)" />

</svg>

❌ Invalid: id contains special characters

<svg width="200" height="200" xmlns="http://www.w3.org/2000/svg">

<defs>

<pattern id="my pattern!" width="10" height="10" patternUnits="userSpaceOnUse">

<circle cx="5" cy="5" r="3" fill="green" />

</pattern>

</defs>

<rect width="200" height="200" fill="url(#my pattern!)" />

</svg>

✅ Valid: id starts with a letter

<svg width="200" height="200" xmlns="http://www.w3.org/2000/svg">

<defs>

<pattern id="firstPattern" width="10" height="10" patternUnits="userSpaceOnUse">

<circle cx="5" cy="5" r="3" fill="blue" />

</pattern>

</defs>

<rect width="200" height="200" fill="url(#firstPattern)" />

</svg>

✅ Valid: id starts with an underscore

<svg width="200" height="200" xmlns="http://www.w3.org/2000/svg">

<defs>

<pattern id="_stripe-bg" width="10" height="10" patternUnits="userSpaceOnUse">

<rect width="5" height="10" fill="red" />

</pattern>

</defs>

<rect width="200" height="200" fill="url(#_stripe-bg)" />

</svg>

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

<svg width="200" height="200" xmlns="http://www.w3.org/2000/svg">

<defs>

<pattern id="dot-grid_v2" width="10" height="10" patternUnits="userSpaceOnUse">

<circle cx="5" cy="5" r="3" fill="green" />

</pattern>

</defs>

<rect width="200" height="200" fill="url(#dot-grid_v2)" />

</svg>

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

The lang attribute on the <html> element declares the primary language of the document. The W3C validator uses heuristics to analyze the text content of your page, and when it detects a mismatch between the declared language and the apparent language, it raises this warning. For example, if your page content is written in English but lang="fr" (French) is set, the validator will flag this inconsistency.

Why This Matters

The lang attribute plays a critical role in several areas:

• Accessibility: Screen readers use the lang attribute to select the correct pronunciation rules and voice profile. If a page is written in English but declares French, a screen reader may attempt to read the content with French pronunciation, making it unintelligible to the user.
• Search engines: Search engines use the lang attribute to understand what language a page is in, which affects how the page is indexed and served in search results for different regions.
• Browser features: Browsers rely on the lang attribute for built-in translation prompts, spell-checking, hyphenation, and font selection. An incorrect value can cause unexpected behavior in all of these areas.

How to Fix It

1. Identify the primary language of your content. Look at the actual text on your page — what language is the majority of it written in?
2. Update the lang attribute to the correct BCP 47 language tag for that language (e.g., en for English, fr for French, es for Spanish).
3. If the lang attribute is already correct and the validator's heuristic is wrong (e.g., your page genuinely is in another language but contains some English text or code), you can safely ignore this warning.

For pages with mixed-language content, set the lang attribute on <html> to the primary language, then use lang attributes on specific elements to mark sections in other languages.

Examples

❌ Incorrect: Content is in English but lang declares French

<!DOCTYPE html>

<html lang="fr">

<head>

<title>My Website</title>

</head>

<body>

<h1>Welcome to my website</h1>

<p>This is an English paragraph about web development.</p>

</body>

</html>

The validator detects that the content is English, but lang="fr" says it's French.

✅ Fixed: lang attribute matches the content language

<!DOCTYPE html>

<html lang="en">

<head>

<title>My Website</title>

</head>

<body>

<h1>Welcome to my website</h1>

<p>This is an English paragraph about web development.</p>

</body>

</html>

✅ Mixed-language content with proper lang attributes

If your page is primarily in English but contains sections in another language, set the document language to en and annotate the foreign-language sections individually:

<!DOCTYPE html>

<html lang="en">

<head>

<title>Language Examples</title>

</head>

<body>

<h1>Welcome</h1>

<p>This page is mostly in English.</p>

<blockquote lang="fr">

<p>Ceci est une citation en français.</p>

</blockquote>

</body>

</html>

This approach ensures screen readers switch pronunciation only for the French <blockquote>, while the rest of the page is correctly read as English.

The X-UA-Compatible header tells Internet Explorer which rendering engine to use for a page. Setting it to IE=edge instructs IE to use the highest available standards mode, ensuring the best compatibility and avoiding legacy rendering quirks. The ,chrome=1 directive was an addition that told browsers with the Google Chrome Frame plugin installed to use Chrome's rendering engine instead of IE's. Google discontinued Chrome Frame in 2014, and the W3C validator only accepts IE=edge as a valid value for this header.

Including the deprecated chrome=1 directive causes a validation error and serves no practical purpose on modern websites. No current browser recognizes or acts on it, so it's dead code that only creates noise in your markup.

The fix is straightforward: remove ,chrome=1 from the content attribute, leaving only IE=edge.

Examples

Incorrect

The following triggers the validation error because of the ,chrome=1 suffix:

<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">

Correct

Simply use IE=edge as the sole value:

<meta http-equiv="X-UA-Compatible" content="IE=edge">

Full document example

If you include this meta tag in a complete HTML document, place it early in the <head>:

<!DOCTYPE html>

<html lang="en">

<head>

<meta charset="utf-8">

<meta http-equiv="X-UA-Compatible" content="IE=edge">

<title>My Web Page</title>

</head>

<body>

<h1>Hello World</h1>

</body>

</html>

Server-side configuration

If you set X-UA-Compatible as an HTTP response header rather than a meta tag, apply the same fix there. For example, in an Apache .htaccess file:

<IfModule mod_headers.c>

Header set X-UA-Compatible "IE=edge"

</IfModule>

In Nginx:

add_header X-UA-Compatible "IE=edge";

Is this meta tag still needed?

With Internet Explorer reaching end of life, the X-UA-Compatible meta tag itself is largely unnecessary for new projects. If your site no longer needs to support IE, you can safely remove the tag entirely. If you do keep it for legacy support, ensure the value is exactly IE=edge with no additional directives.

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

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

Why it matters

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

How to fix it

There are two main approaches:

1. Percent-encode the brackets. Replace every [ with %5B and every ] with %5D in the URL. The server will decode them back to brackets automatically, so functionality is preserved.

2. Use alternative parameter naming. If you control the server, switch to a naming convention that avoids brackets altogether, such as dot notation (filters.category) or underscores (filters_category). This keeps the URL valid without any encoding.

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

Examples

Incorrect — raw brackets in the query string

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

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

Fixed — percent-encoded brackets

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

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

Fixed — alternative parameter naming

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

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

Generating encoded URLs in JavaScript

<iframe id="content-frame"></iframe>

<script>

const url = new URL("https://example.com/embed");

url.searchParams.set("filters[category]", "news");

url.searchParams.set("filters[tags]", "web");

document.getElementById("content-frame").src = url.href;

// Result: https://example.com/embed?filters%5Bcategory%5D=news&filters%5Btags%5D=web

</script>

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

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

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

Why this matters

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

How to fix it

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

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

Examples

Incorrect: literal brackets in the query string

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

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

Correct: percent-encoded brackets

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

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

Incorrect: array-style parameters with brackets

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

Correct: array-style parameters encoded

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

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

Incorrect: brackets in a simple value

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

Correct: encoded brackets in a simple value

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

Note on brackets in the host (valid use)

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

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

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

The lang attribute on the <html> element tells browsers, search engines, and assistive technologies what language the page content is written in. The validator uses heuristic analysis of the actual text on the page to detect the likely language, and when there's a mismatch, it flags the discrepancy.

Why This Matters

An incorrect lang attribute causes real problems for users and systems that rely on it:

• Screen readers use the lang attribute to select the correct pronunciation engine. A French document marked as English will be read aloud with English pronunciation rules, making it incomprehensible.
• Search engines use the language declaration for indexing and serving results to users searching in a specific language.
• Browser features like automatic translation prompts and spell-checking rely on the declared language.
• Hyphenation and typographic rules in CSS also depend on the correct language being declared.

Common Causes

1. Copy-pasting a boilerplate — Starting from an English template but writing content in another language without updating lang.
2. Multilingual sites — Using the same base template for all language versions without dynamically setting the lang value.
3. Incorrect language subtag — Using the wrong BCP 47 language tag (e.g., lang="en" instead of lang="de" for German content).

When You Can Safely Ignore This Warning

This is a warning, not an error. The validator's language detection is heuristic and not always accurate. You may safely ignore it if:

• Your page contains very little text, making detection unreliable.
• The page has significant amounts of content in multiple languages, but the lang attribute correctly reflects the primary language.
• The detected language is simply wrong (e.g., short text snippets can confuse the detector).

If you're confident the lang attribute is correct, you can disregard the warning.

How to Fix It

Identify the primary language of your document's content and set the lang attribute to the appropriate BCP 47 language tag. Common tags include en (English), fr (French), de (German), es (Spanish), pt (Portuguese), ja (Japanese), and zh (Chinese).

Examples

Incorrect: Content in French, but lang set to English

<!DOCTYPE html>

<html lang="en">

<head>

<meta charset="utf-8">

<title>Mon site</title>

</head>

<body>

<h1>Bienvenue sur notre site</h1>

<p>Nous sommes ravis de vous accueillir sur notre plateforme.</p>

</body>

</html>

This triggers the warning because the validator detects French content but sees lang="en".

Fixed: lang attribute matches the content language

<!DOCTYPE html>

<html lang="fr">

<head>

<meta charset="utf-8">

<title>Mon site</title>

</head>

<body>

<h1>Bienvenue sur notre site</h1>

<p>Nous sommes ravis de vous accueillir sur notre plateforme.</p>

</body>

</html>

Handling mixed-language content

If your page is primarily in one language but contains sections in another, set the lang attribute on the <html> element to the primary language and use lang on specific elements for the other language:

<!DOCTYPE html>

<html lang="en">

<head>

<meta charset="utf-8">

<title>Our Global Site</title>

</head>

<body>

<h1>Welcome to our site</h1>

<p>We are glad you are here.</p>

<blockquote lang="fr">

<p>La vie est belle.</p>

</blockquote>

</body>

</html>

This tells assistive technologies that the page is in English, but the blockquote should be read using French pronunciation rules. The validator should not flag this as a mismatch because the majority of the content is in English.

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

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

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

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

Examples

Invalid: space in fragment and id

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

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

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

Fixed: hyphen-separated fragment and id

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

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

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

Fixed: underscore-separated fragment and id

Underscores work equally well if you prefer that convention.

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

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

Alternative: percent-encoding the space

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

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

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

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

Full valid document

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

<!doctype html>

<html lang="en">

<head>

<title>Page sections</title>

</head>

<body>

<nav>

<ul>

<li><a href="#getting-started">Getting Started</a></li>

<li><a href="#advanced-usage">Advanced Usage</a></li>

<li><a href="#frequently-asked-questions">FAQ</a></li>

</ul>

</nav>

<h2 id="getting-started">Getting Started</h2>

<p>Introduction content here.</p>

<h2 id="advanced-usage">Advanced Usage</h2>

<p>Advanced content here.</p>

<h2 id="frequently-asked-questions">Frequently Asked Questions</h2>

<p>FAQ content here.</p>

</body>

</html>

The aria-rowspan attribute is used in ARIA-based grid and table structures to indicate how many rows a cell spans. It serves a similar purpose to the rowspan attribute on native HTML <td> and <th> elements, but is designed for custom widgets built with ARIA roles like gridcell, rowheader, and columnheader within grid or treegrid structures.

According to the WAI-ARIA specification, the value of aria-rowspan must be a positive integer — a whole number greater than zero. A value of "0" is invalid because it implies the cell spans no rows, which is semantically meaningless. Note that this differs from native HTML's rowspan attribute, where "0" has a special meaning (span all remaining rows in the row group). The ARIA attribute does not support this behavior.

This matters primarily for accessibility. Screen readers and other assistive technologies rely on aria-rowspan to convey the structure of custom grids to users. An invalid value of "0" can confuse assistive technology, potentially causing it to misrepresent the grid layout or skip the cell entirely. Ensuring valid values helps users who depend on these tools navigate your content correctly.

To fix this issue, determine how many rows the cell actually spans and set aria-rowspan to that number. If the cell occupies a single row, use "1". If it spans multiple rows, use the appropriate count. If you don't need row spanning at all, you can simply remove the aria-rowspan attribute entirely, since the default behavior is to span one row.

Examples

Incorrect: aria-rowspan set to zero

<div role="grid">

<div role="row">

<div role="gridcell" aria-rowspan="0">Name</div>

<div role="gridcell">Value</div>

</div>

</div>

The value "0" is not a positive integer, so the validator reports an error.

Correct: aria-rowspan set to a positive integer

If the cell spans a single row, use "1" (or remove the attribute, since one row is the default):

<div role="grid">

<div role="row">

<div role="gridcell" aria-rowspan="1">Name</div>

<div role="gridcell">Value</div>

</div>

</div>

Correct: aria-rowspan for a cell spanning multiple rows

If the cell genuinely spans two rows, set the value accordingly:

<div role="grid">

<div role="row">

<div role="gridcell" aria-rowspan="2">Category</div>

<div role="gridcell">Item A</div>

</div>

<div role="row">

<div role="gridcell">Item B</div>

</div>

</div>

Correct: removing the attribute when no spanning is needed

If the cell doesn't span multiple rows, the simplest fix is to remove aria-rowspan altogether:

<div role="grid">

<div role="row">

<div role="gridcell">Name</div>

<div role="gridcell">Value</div>

</div>

</div>

When to use aria-rowspan vs. native HTML

If you're building a data table, prefer native HTML <table>, <tr>, <td>, and <th> elements with the standard rowspan attribute. Native table semantics are automatically understood by browsers and assistive technologies without any ARIA attributes. Reserve aria-rowspan for custom interactive widgets (like spreadsheet-style grids or tree grids) where native table elements aren't appropriate. The aria-rowspan value should always match the actual visual and structural layout of your grid to avoid confusing assistive technology users.

A <tr> element already has an implicit ARIA role of row, so adding role="row" is redundant when the parent <table> uses its default semantics or has a role of table, grid, or treegrid.

HTML tables come with built-in accessibility semantics. The <table> element implicitly has role="table", and <tr> implicitly has role="row". Browsers and assistive technologies already understand this structure, so explicitly adding these roles is unnecessary and flagged by the W3C validator.

The only time you'd need to add a role to a <tr> is when the table's native semantics have been overridden — for example, if the <table> has been repurposed with a non-table role like role="presentation" or role="none". In that case, you'd need explicit ARIA roles to restore row semantics.

Incorrect Example

<table>

<tr role="row">

<th>Name</th>

<th>Email</th>

</tr>

<tr role="row">

<td>Alice</td>

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

</tr>

</table>

Fixed Example

Simply remove the redundant role="row" from the <tr> elements:

<table>

<tr>

<th>Name</th>

<th>Email</th>

</tr>

<tr>

<td>Alice</td>

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

</tr>

</table>

The same fix applies if your <table> explicitly has role="table", role="grid", or role="treegrid" — the <tr> elements still don't need an explicit role="row" because the browser infers it automatically.

A URL follows a specific structure defined by RFC 3986. The general format is:

scheme://host/path?query#fragment

The # character serves as the delimiter that introduces the fragment portion of the URL. It may only appear once in this role. Once the parser encounters the first #, everything after it is treated as the fragment identifier. A second # within that fragment is an illegal character because the fragment production in the URL specification does not permit unescaped # characters.

This validation error commonly arises from:

• Duplicate # characters — e.g., accidentally including two hash marks like /#?param=value#section.
• Misplaced query strings — putting ?key=value after the # instead of before it. While this may work in some single-page application routers, it results in the query being part of the fragment, and adding another # after that creates an invalid URL.
• Copy-paste errors — assembling URLs from multiple parts and inadvertently introducing an extra #.

This matters for several reasons. Browsers may handle malformed URLs inconsistently — some may silently truncate or ignore part of the URL, while others may fail to load the resource entirely. The W3C validator flags this because it violates the HTML specification's requirement that the src attribute contain a valid URL. Invalid URLs can also cause issues with assistive technologies, link sharing, and automated tools that parse your HTML.

How to fix it

1. Locate all # characters in the URL and determine which one is the intended fragment delimiter.
2. Remove any duplicate # characters that were added by mistake.
3. Move query parameters before the fragment — the ?query portion must come before the #fragment in a well-formed URL.
4. Percent-encode if needed — if a literal # must appear as data within the fragment or query value (not as a delimiter), encode it as %23.

Examples

Incorrect: multiple # characters

The second # inside the fragment is illegal:

<iframe src="https://example.com/#?secret=123#abc"></iframe>

Correct: query before fragment

Move the query string before the # so the URL has a proper structure:

<iframe src="https://example.com/?secret=123#abc"></iframe>

Correct: single fragment, no query

If you only need a fragment identifier, use a single #:

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

Correct: percent-encoding a literal # in a value

If the fragment itself must contain a # as data (not as a delimiter), percent-encode it:

<iframe src="https://example.com/?secret=123#color=%23ff0000"></iframe>

Here, %23ff0000 represents the literal string #ff0000 within the fragment value, which is valid because the # is encoded.

Incorrect: hash-based routing with duplicate #

Some single-page app embed URLs use hash-based routing, which can lead to accidental double hashes:

<iframe src="https://app.example.com/#/dashboard#settings"></iframe>

Correct: use a single fragment for the route

Restructure the URL to use a single # with a combined path:

<iframe src="https://app.example.com/#/dashboard/settings"></iframe>

Or, if the application supports it, use standard path-based routing instead:

<iframe src="https://app.example.com/dashboard/settings"></iframe>

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

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

Why this matters

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

How to fix it

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

Examples

Incorrect: backslashes in a relative path

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

Correct: forward slashes in a relative path

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

Incorrect: backslashes in an absolute URL

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

Correct: forward slashes in an absolute URL

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

Incorrect: Windows file path pasted directly

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

Correct: converted to a proper relative URL

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

Incorrect: mixed slashes

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

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

Correct: all forward slashes

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

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

Square brackets ([ and ]) are not valid characters in URLs according to RFC 3986 and must be percent-encoded in the href attribute of <a> elements.

URLs have a strict set of allowed characters. Square brackets are reserved exclusively for IPv6 addresses in the host portion of a URL (e.g., http://[::1]/). Anywhere else in a URL, including query strings, they must be percent-encoded: [ becomes %5B and ] becomes %5D.

This issue commonly appears when linking to URLs that use square brackets in query parameters, a pattern found in some PHP frameworks and APIs (e.g., ?filter[name]=value). While most browsers handle unencoded brackets without problems, the HTML specification requires valid URLs, and the W3C validator flags the violation.

Invalid example

<a href="https://example.com/results?filter[status]=active&filter[role]=admin">

View results

</a>

Valid example

Replace [ with %5B and ] with %5D:

<a href="https://example.com/results?filter%5Bstatus%5D=active&filter%5Brole%5D=admin">

View results

</a>

The browser will decode the percent-encoded characters when sending the request, so the server receives the same query string either way.

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

This issue commonly arises in a few scenarios:

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

Why This Matters

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

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

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

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

How to Fix It

The fix depends on why the curly braces are there:

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

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

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

Examples

Incorrect: Raw curly braces in href

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

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

Correct: Percent-encoded curly braces

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

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

Correct: Resolved template variable

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

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

Incorrect: Curly braces in a fragment identifier

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

Correct: Percent-encoded fragment

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

Incorrect: Curly braces in query parameters

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

Correct: Percent-encoded query parameter

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

Using JavaScript for dynamic URLs

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

<a id="dynamic-link" href="https://example.com">Dynamic Link</a>

<script>

var value = "{some-value}";

var link = document.getElementById("dynamic-link");

link.href = "https://example.com/path?param=" + encodeURIComponent(value);

</script>

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

A # character inside the fragment portion of a URL is not valid and must be percent-encoded as %23.

The fragment identifier in a URL is everything after the first # character. Because # itself is the delimiter that starts the fragment, any additional # characters within the fragment are illegal according to RFC 3986. Browsers may handle these gracefully, but the markup is technically invalid.

This commonly happens when an id value on the target element contains a #, or when a URL is copied from somewhere and pasted without encoding. The fix is to replace any extra # inside the href fragment with %23. Better yet, avoid using # in id values altogether.

Invalid example

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

The fragment section#2 contains a second #, which is not allowed.

Fixed example

Option 1: percent-encode the # inside the fragment.

<a href="#section%232">Go to section</a>

Option 2 (preferred): change the target id so it does not contain # at all.

<h2 id="section-2">Section 2</h2>

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

A space character in the href attribute of a <link> element is not valid in a URL and must be encoded as %20.

URLs follow strict syntax rules defined in RFC 3986. Spaces are not permitted anywhere in a URL, including the query string (the part after the ?). When a URL needs to represent a space, it must be percent-encoded as %20.

Browsers are forgiving and will often handle spaces by silently encoding them, but the HTML is still technically invalid. This can lead to unexpected behavior in less forgiving environments like HTML emails, web crawlers, or certain HTTP clients.

Invalid Example

<link rel="stylesheet" href="https://example.com/styles?family=Open Sans">

Fixed Example

Replace every space with %20:

<link rel="stylesheet" href="https://example.com/styles?family=Open%20Sans">

If your URL has multiple spaces or special characters, make sure each one is properly percent-encoded. Common replacements include %20 for spaces, %26 for & inside already-encoded contexts, and %3D for =. Most programming languages offer a URL-encoding function (e.g., encodeURI() in JavaScript) to handle this automatically.

A | (pipe) character in a link element's href attribute is not valid in a URL because it is not a legal character in a query string without being percent-encoded.

This error commonly appears when loading multiple Google Fonts in a single <link> tag using the older Google Fonts API v1 syntax, which used the pipe character to separate font families:

fonts.googleapis.com/css?family=Open+Sans|Roboto

The | character must be encoded as %7C to be valid in a URL. However, even with encoding, the Google Fonts API v1 no longer supports loading multiple families this way. The current Google Fonts API v2 (/css2) uses separate family parameters instead.

Bad example

<link rel="stylesheet"

href="https://fonts.googleapis.com/css?family=Open+Sans|Roboto">

Good example

Use the Google Fonts API v2 with separate family parameters:

<link rel="stylesheet"

href="https://fonts.googleapis.com/css2?family=Open+Sans&family=Roboto&display=swap">

If you are not using Google Fonts and cannot change the URL structure, percent-encode the pipe character:

<link rel="stylesheet"

href="https://example.com/css?param1=a%7Cparam2=b">

When the browser's HTML parser encounters a src attribute, it expects the value between the opening and closing quotes to be a valid URL. URLs have strict rules about which characters are permitted — a literal double quote (") is not one of them. If a " character appears inside the URL, the validator flags it as an illegal character in the query string (or other parts of the URL).

This error often doesn't stem from an intentionally embedded quote in the URL itself. Instead, it's usually a symptom of malformed HTML around the attribute. Common causes include:

• Stray quotes after the attribute value, such as writing src="https://example.com/script.js"async"" instead of properly separating attributes.
• Accidentally doubled closing quotes, like src="https://example.com/script.js"".
• Boolean attributes given empty-string values incorrectly, such as async"" instead of just async, which causes the parser to interpret the extra quotes as part of the preceding src value.
• Copy-paste errors that introduce smart quotes (" ") or extra quotation marks into the URL.

This matters for several reasons. Malformed src attributes can cause the script to fail to load entirely, breaking functionality on your page. It also violates the HTML specification, which can lead to unpredictable behavior across different browsers as each parser tries to recover from the error differently.

To fix the issue, carefully inspect the <script> tag and ensure that:

1. The src attribute value contains only a valid URL with no unescaped " characters.
2. The opening and closing quotes around the attribute value are properly balanced.
3. Attributes are separated by whitespace — not jammed together.
4. Boolean attributes like async and defer are written as bare keywords without values.

If you genuinely need a double quote character in a query string (which is rare), encode it as %22.

Examples

Incorrect — stray quotes between attributes

In this example, the async attribute is malformed as async"", which causes the parser to interpret the extra quotes as part of the src URL:

<script src="https://example.com/js/app.js?ver=3.1" async""></script>

Incorrect — doubled closing quote

Here, an extra " at the end of the src value creates an illegal character in the URL:

<script src="https://example.com/js/app.js?ver=3.1""></script>

Incorrect — smart quotes from copy-paste

Curly/smart quotes copied from a word processor are not valid HTML attribute delimiters and get treated as part of the URL:

<script src="https://example.com/js/app.js?ver=3.1"></script>

Correct — clean attributes with proper quoting

<script src="https://example.com/js/app.js?ver=3.1" async></script>

Correct — boolean attribute written as a bare keyword

Boolean attributes like async and defer don't need a value. Simply include the attribute name:

<script src="https://example.com/js/app.js?ver=3.1" defer></script>

While async="async" is technically valid per the spec, the cleanest and most common form is the bare attribute. Avoid empty-string patterns like async="" placed without proper spacing, as they can lead to the exact quoting errors described here.

Correct — full valid document

<!DOCTYPE html>

<html lang="en">

<head>

<title>Valid Script Example</title>

<script src="https://example.com/js/app.js?ver=3.1" async></script>

</head>

<body>

<p>Page content here.</p>

</body>

</html>

If you're generating <script> tags dynamically (through a CMS, template engine, or build tool), check the template source rather than just the rendered output. The stray quotes are often introduced by incorrect string concatenation or escaping logic in the server-side code.