HTML Guides

The id attribute uniquely identifies an element within a document. According to the WHATWG HTML living standard, if the id attribute is specified, its value must be non-empty and must not contain any ASCII whitespace characters. The attribute itself is optional — you don't need to include it — but when you do, it must have a valid value. Setting id="" violates this rule because the empty string is not a valid identifier.

This issue commonly occurs when code is generated dynamically (e.g., by a templating engine or JavaScript framework) and the variable intended to populate the id value resolves to an empty string. It can also happen when developers add the attribute as a placeholder and forget to fill it in.

Why this matters

Standards compliance: An empty id violates the HTML specification, making your document invalid.
Accessibility: Assistive technologies like screen readers rely on id attributes to associate <label> elements with form controls. An empty id breaks this association, making forms harder to use for people who depend on these tools.
JavaScript and CSS: Methods like document.getElementById("") and selectors like # (with no identifier) will not work as expected. An empty id can cause subtle, hard-to-debug issues in your scripts and styles.
Browser behavior: While browsers are generally forgiving, an empty id leads to undefined behavior. Different browsers may handle it inconsistently.

How to fix it

Assign a meaningful value: Give the id a descriptive, unique value that identifies the element's purpose (e.g., id="country-select").
Remove the attribute: If you don't need the id, simply remove it from the element altogether.
Fix dynamic generation: If a templating engine or framework is producing the empty value, add a conditional check to either output a valid id or omit the attribute entirely.

Examples

❌ Incorrect: empty `id` attribute

<label for="country">Country</label>

<option value="us">United States</option>

<option value="ca">Canada</option>

</select>

This triggers the validation error because id="" is an empty string.

✅ Correct: meaningful `id` value

<label for="country">Country</label>

<option value="us">United States</option>

<option value="ca">Canada</option>

</select>

The id now has a valid, non-empty value, and the <label> element's for attribute correctly references it.

✅ Correct: `id` attribute removed entirely

<label>

Country

<option value="us">United States</option>

<option value="ca">Canada</option>

</select>

</label>

If you don't need the id, remove it. Here, the <label> wraps the <select> directly, so the for/id association isn't needed — the implicit label works just as well.

Bad value “” for attribute “id” on element X: An ID must not be the empty string.

The validator reports “Bad value “” for attribute id on element X: An ID must not be the empty string” when any element includes an empty id attribute. Per the HTML standard, id is a global attribute used as a unique document-wide identifier. An empty identifier is not a valid value and is ignored by some features, leading to hard-to-debug issues.

This matters for accessibility and interoperability. Features that depend on IDs—fragment navigation (#target), <label for>, ARIA attributes like aria-labelledby/aria-controls, and DOM APIs such as document.getElementById()—require a non-empty, unique value. Empty IDs break these links, can degrade assistive technology output, and violate conformance, which may hide bugs across browsers.

How to fix:

If the element doesn’t need an identifier, remove the id attribute entirely.
If it needs one, provide a non-empty, unique value, e.g., id="main-content".
Ensure uniqueness across the page; each id must occur only once.
Use simple, predictable tokens: avoid spaces, prefer lowercase letters, digits, hyphens, and underscores (e.g., feature-1). While the spec allows a broad range of characters, sticking to URL- and selector-friendly characters avoids pitfalls.

Examples

Example that triggers the validator error (empty id)

Correct: remove an unnecessary empty id

Correct: provide a meaningful, unique id

Problematic label association with empty id (invalid)

<label for="">Email</label>

Correct label–control association

<label for="email">Email</label>

Correct ARIA relationship

<h2 id="pricing-heading">Pricing</h2>

<p>Choose a plan.</p>

</section>

Correct fragment navigation target

<nav>

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

</nav>

<h2>Contact us</h2>

</section>

Minimal full document (validated) demonstrating proper ids

<!doctype html>

<head>

<title>Valid IDs Example</title>

</head>

<body>

<h1 id="page-title">Welcome</h1>

<p>Jump to the <a href="#details">details</a>.</p>

<h2>Details</h2>

</section>

<form>

<label for="email">Email</label>

</form>

</main>

</body>

</html>

Bad value “” for attribute “imagesizes” on element “link”: Must not be empty.

The imagesizes attribute is used exclusively on <link> elements that have rel="preload" and as="image". It works in tandem with the imagesrcset attribute to allow the browser to preload the most appropriate image from a set of candidates — mirroring how sizes and srcset work on an <img> element. When the browser encounters these attributes on a <link>, it can begin fetching the right image resource early, before it even parses the <img> tag in the document body.

When imagesizes is set to an empty string (""), the browser has no information about the intended display size of the image, which defeats the purpose of responsive image preloading. The browser cannot select the best candidate from imagesrcset without knowing how large the image will be rendered. An empty value is invalid per the HTML specification, which requires the attribute to contain a valid source size list (the same syntax used by the sizes attribute on <img>).

This matters for both performance and standards compliance. Responsive preloading is a performance optimization — an empty imagesizes undermines that by leaving the browser unable to make an informed choice. From a standards perspective, the validator correctly rejects the empty value because the attribute's defined value space does not include the empty string.

How to fix it

Provide a valid sizes value that matches the sizes attribute on the corresponding <img> element in your page. This tells the browser how wide the image will be at various viewport widths.
Remove imagesizes entirely if you don't need responsive preloading. If you're preloading a single image (using href instead of imagesrcset), you don't need imagesizes at all.

Examples

❌ Bad: empty `imagesizes` attribute

<link

rel="preload"

as="image"

imagesrcset="hero-480.jpg 480w, hero-800.jpg 800w, hero-1200.jpg 1200w"

imagesizes="">

The empty imagesizes="" triggers the validation error and prevents the browser from selecting the correct image candidate.

✅ Fixed: providing a valid sizes value

<link

rel="preload"

as="image"

imagesrcset="hero-480.jpg 480w, hero-800.jpg 800w, hero-1200.jpg 1200w"

imagesizes="(max-width: 600px) 480px, (max-width: 1000px) 800px, 1200px">

The imagesizes value uses the same syntax as the sizes attribute on <img>. It provides media conditions paired with lengths, with a fallback length at the end. This value should match the sizes attribute on the corresponding <img> element in your markup.

✅ Fixed: simple full-width image

<link

rel="preload"

as="image"

imagesrcset="banner-640.jpg 640w, banner-1280.jpg 1280w"

imagesizes="100vw">

If the image spans the full viewport width, 100vw is a straightforward and valid value.

✅ Fixed: removing the attribute when not needed

If you're preloading a single, non-responsive image, omit both imagesrcset and imagesizes and use the href attribute instead. The imagesizes attribute is only meaningful when paired with imagesrcset.

Bad value “” for attribute “imagesrcset” on element “link”: Must contain one or more image candidate strings.

Bad value “” for attribute “is” on element “a”: Must be non-empty.

Bad value “” for attribute “itemprop” on element “div”.

itemprop
div

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

max
input

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

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

Why this matters

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

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

How to fix it

You have two options:

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

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

Where `maxlength` applies

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

Examples

❌ Incorrect: empty string triggers the validation error

❌ Incorrect: other invalid values

✅ Correct: explicit maximum length

✅ Correct: omit the attribute when no limit is needed

✅ Correct: `maxlength` on a `textarea`

✅ Correct: dynamic value with a fallback

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

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

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

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

Bad value “” for attribute “name” on element “a”: An ID must not be the empty string.

The name attribute on <a> elements was historically used to create named anchors — fragment targets that could be linked to with href="#anchorName". In modern HTML (the WHATWG living standard), the name attribute on <a> is considered obsolete for this purpose. The id attribute is now the standard way to create fragment targets, and it can be placed on any element, not just <a> tags.

Regardless of whether you use name or id, the value must be a non-empty string. The W3C validator enforces this rule because an empty identifier serves no functional purpose — it cannot be referenced by a fragment link, it cannot be targeted by JavaScript, and it creates invalid markup. Browsers may silently ignore it, but it pollutes the DOM and signals a likely mistake in the code.

Empty name attributes often appear in content migrated from older CMS platforms or WYSIWYG editors that inserted placeholder anchors like <a name=""></a>. They can also result from templating systems where a variable intended to populate the attribute resolved to an empty string.

Why this matters

Standards compliance: Both the WHATWG HTML living standard and the W3C HTML specification require that identifier-like attributes (id, name) must not be empty strings.
Accessibility: Screen readers and assistive technologies may attempt to process named anchors. Empty identifiers create noise without providing any navigational value.
Functionality: An empty name or id cannot be used as a fragment target, so the element is effectively useless as a link destination.

How to fix it

Remove the element entirely if the empty anchor serves no purpose — this is the most common fix.
Replace name with id and provide a meaningful, non-empty value if you need a fragment target.
Move the id to a nearby semantic element instead of using a standalone empty <a> tag. For example, place the id directly on a heading, section, or paragraph.
Ensure uniqueness — every id value in a document must be unique.

Examples

❌ Empty `name` attribute triggers the error

<h2>Introduction</h2>

<p>Welcome to the guide.</p>

❌ Empty `name` generated by a template

<p>This anchor was meant to be a target but the value is missing.</p>

<a href="#">Jump to section</a>

✅ Remove the empty anchor if it's unnecessary

<h2>Introduction</h2>

<p>Welcome to the guide.</p>

✅ Use `id` on the target element directly

<h2 id="introduction">Introduction</h2>

<p>Welcome to the guide.</p>

<a href="#introduction">Go to Introduction</a>

✅ Use `id` on a standalone anchor if needed

If you need a precise anchor point that doesn't correspond to an existing element, use an <a> tag with a valid, non-empty id:

<p>This paragraph follows the anchor point.</p>

<a href="#section-start">Jump to section start</a>

✅ Migrate legacy `name` to `id`

If your existing code uses the obsolete name attribute with a valid value, update it to use id instead:

<h2 id="contact">Contact Us</h2>

Bad value “” for attribute “name” on element “form”: Must not be empty.

name
form

The HTML specification requires that if the name attribute is used on a <form> element, its value must be a non-empty string. An empty name="" attribute serves no practical purpose — it doesn't register the form in the document.forms named collection, and it can't be used as a valid reference in scripts. The W3C validator flags this as an error because it violates the content model defined in the WHATWG HTML Living Standard.

The name attribute on a form is primarily used to access the form programmatically through document.forms["formName"]. When the value is empty, this lookup mechanism doesn't work, so the attribute becomes meaningless. This is different from the id attribute, which also identifies elements but participates in fragment navigation and CSS targeting. The name attribute on <form> is specifically for the legacy document.forms named getter interface.

It's worth noting that the name attribute value on a form must not equal an empty string, and it should be unique among the form elements in the forms collection. While duplicate names won't cause a validation error, they can lead to unexpected behavior when accessing forms by name in JavaScript.

How to fix

You have two options:

Remove the attribute entirely. If you're not referencing the form by name in JavaScript, the name attribute is unnecessary. You can use id instead for CSS or JavaScript targeting.
Provide a meaningful, non-empty value. If you need to reference the form through document.forms, give it a descriptive name that reflects its purpose.

Examples

❌ Invalid: empty `name` attribute

<label for="email">Email</label>

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

</form>

This triggers the validator error because the name attribute is present but has an empty string value.

✅ Fixed: attribute removed

<form>

<label for="email">Email</label>

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

</form>

If you don't need to reference the form by name, simply remove the attribute.

✅ Fixed: meaningful name provided

<label for="email">Email</label>

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

</form>

With a non-empty name, you can now access the form in JavaScript using document.forms["subscriptionForm"] or document.forms.subscriptionForm.

✅ Alternative: using `id` instead

<label for="email">Email</label>

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

</form>

In modern development, using id with document.getElementById() or document.querySelector() is often preferred over the name attribute for form identification. The name attribute on <form> is a legacy feature that remains valid but isn't required for most use cases.

Bad value “” for attribute “name” on element “input”: Must not be empty.

The name attribute on an <input> element identifies the form control's data when the form is submitted. It acts as the key in the key-value pair sent to the server (e.g., email=user@example.com). When you set name="", the attribute is present but contains an empty string, which the HTML specification considers an invalid value. An empty name means the input's data will be excluded from the form's submission payload in most browsers, making it functionally useless for form processing.

This issue matters for several reasons:

Form functionality: Inputs with empty names are typically omitted from form data, so the server never receives the user's input.
Standards compliance: The HTML specification requires that if the name attribute is present, its value must not be empty.
JavaScript references: An empty name makes it difficult to reference the element using methods like document.getElementsByName() or FormData.
Accessibility: Screen readers and assistive technologies may use the name attribute to help identify form controls, and an empty value provides no useful information.

Note that the name attribute is not technically required on every <input> element — it's perfectly valid to omit it entirely. For example, inputs used purely for client-side JavaScript interactions without form submission don't need a name. The error specifically arises when the attribute is present but set to an empty string.

To fix the issue, either assign a meaningful name that describes the data the input collects, or remove the name attribute altogether if the input isn't part of a form submission.

Examples

❌ Empty `name` attribute triggers the error

<label for="email">Email:</label>

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

</form>

✅ Providing a meaningful `name` value

<label for="email">Email:</label>

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

</form>

✅ Removing `name` when the input isn't submitted

If the input is only used for client-side interaction and doesn't need to be part of form data, simply omit the attribute:

<label for="search">Filter results:</label>

❌ Multiple inputs with empty names

This pattern sometimes appears when inputs are generated dynamically with placeholder attributes:

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

</form>

✅ Each input gets a descriptive name

<label for="username">Username:</label>

<label for="password">Password:</label>

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

</form>

Bad value “” for attribute “poster” on element “video”: Must be non-empty.

poster
video

Bad value “” for attribute “role” on element “div”.

Bad value “” for attribute “rows” on element “textarea”: The empty string is not a valid positive integer.

The <textarea> element represents a multi-line plain-text editing control, commonly used for comments, feedback forms, and other free-form text input. The rows attribute specifies the number of visible text lines the textarea should display. According to the HTML specification, when the rows attribute is present, its value must be a valid positive integer — meaning a string of one or more digits representing a number greater than zero (e.g., 1, 5, 20). An empty string ("") does not meet this requirement.

This issue typically occurs when a template engine, CMS, or JavaScript framework dynamically sets the rows attribute but outputs an empty value instead of a number, or when a developer adds the attribute as a placeholder intending to fill it in later.

Why this matters

Standards compliance: The HTML specification explicitly requires rows to be a positive integer when present. An empty string violates this rule.
Unpredictable rendering: Browsers fall back to a default value (typically 2) when they encounter an invalid rows value, but this behavior isn't guaranteed to be consistent across all browsers and versions.
Maintainability: Invalid attributes can mask bugs in dynamic code that was supposed to provide a real value.

How to fix it

You have two options:

Set a valid positive integer: Replace the empty string with a number like 4, 5, or whatever suits your design.
Remove the attribute: If you don't need to control the number of visible rows (or prefer to handle sizing with CSS), simply omit the rows attribute. The browser will use its default.

If the value is generated dynamically, ensure your code has a fallback so it never outputs an empty string. You can also control the textarea's height using CSS (height or min-height) instead of relying on the rows attribute.

Examples

❌ Invalid: empty string for `rows`

</textarea>

This triggers the error because "" is not a valid positive integer.

✅ Fixed: providing a valid positive integer

</textarea>

Setting rows="5" tells the browser to display five visible lines of text.

✅ Fixed: removing the attribute entirely

</textarea>

When rows is omitted, the browser uses its default (typically 2 rows). This is perfectly valid.

✅ Alternative: using CSS for sizing

</textarea>

If you need precise control over the textarea's dimensions, CSS properties like height, min-height, and width give you more flexibility than the rows and cols attributes. In this case, you can safely leave both attributes off.

Bad value for attribute “sizes” on element “img”: Bad CSS number token: Expected a minus sign or a digit but saw X instead at Y.

sizes
img

Bad value for attribute “sizes” on element “img”: Expected units (one of “em”, “ex”, “ch”, “rem”, “cap”, “ic”, “vw”, “svw”, “lvw”, “dvw”, “vh”, “svh”, “lvh”, “dvh”, “vi”, “svi”, “lvi”, “dvi”, “vb”, “svb”, “lvb”, “dvb”, “vmin”, “svmin”, “lvmin”, “dvmin”, “vmax”, “svmax”, “lvmax”, “dvmax”, “cm”, “mm”, “q”, “in”, “pc”, “pt”, “px”) but found no units at X.

sizes
img

Bad value “” for attribute “sizes” on element “img”: Must not be empty.

sizes
img

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

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:

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

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

Fixed — percent-encoded brackets

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

Fixed — alternative parameter naming

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

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.

Bad value “” for attribute “src” on element “iframe”: Must be non-empty.

The src attribute on an <iframe> tells the browser which document to load and display within the embedded frame. When you leave this attribute empty (src=""), the W3C HTML Validator reports an error because the HTML specification requires the value to be a valid, non-empty URL. An empty string doesn't resolve to a meaningful resource.

This is more than a cosmetic validation issue. When a browser encounters src="", it typically interprets the empty string as a relative URL pointing to the current page, which causes the browser to re-fetch and embed the current document inside itself. This leads to unnecessary network requests, potential performance degradation, and unexpected rendering behavior. In some cases it can even cause infinite nesting loops or break page functionality.

From an accessibility standpoint, an empty <iframe> with no valid source provides no meaningful content to assistive technologies. Screen readers may announce the frame without being able to describe its purpose, creating a confusing experience for users.

How to fix it

Provide a valid URL: Set the src attribute to the actual URL of the content you want to embed.
Use about:blank for intentionally empty frames: If you need an <iframe> in the DOM but don't have content to load yet (e.g., you plan to populate it later via JavaScript), use src="about:blank". This is a valid URL that loads a blank page without triggering extra requests.
Remove the element: If the <iframe> isn't needed, remove it from the markup entirely. You can dynamically create and insert it with JavaScript when you have content to load.
Use srcdoc instead: If you want to embed inline HTML rather than loading an external URL, use the srcdoc attribute, which accepts an HTML string directly.

Examples

❌ Empty `src` attribute

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

❌ `src` attribute with only whitespace

Whitespace-only values are also invalid URLs and will produce the same error.

✅ Valid URL in `src`

A fully qualified URL is the most straightforward fix. Note the title attribute, which is recommended for accessibility so that assistive technologies can describe the frame's purpose.

✅ Using `about:blank` for a placeholder frame

This is a valid approach when you need the <iframe> in the DOM but plan to set its content later with JavaScript using contentDocument.write() or by updating the src attribute dynamically.

✅ Using `srcdoc` for inline content

The srcdoc attribute lets you embed HTML directly without needing an external URL. When srcdoc is present, it takes priority over src.

✅ Dynamically creating the iframe with JavaScript

const iframe = document.createElement("iframe");

iframe.src = "https://example.com/video.html";

iframe.title = "Video player";

document.getElementById("video-container").appendChild(iframe);

</script>

If the source URL isn't available at page load, creating the <iframe> dynamically avoids having an empty src in your HTML altogether.

Bad value for attribute “src” on element “img”: Fragment is not allowed for data: URIs according to RFC 2397.

A data: URI embeds resource content directly in a URL rather than pointing to an external file. It follows the format data:[<mediatype>][;base64],<data>. RFC 2397, which governs this scheme, explicitly states that fragment identifiers (the # character followed by a fragment name) are not valid in data: URIs.

This issue most commonly arises when developers try to reference a specific element inside an embedded SVG — for example, a particular <symbol> or element with an id — by appending a fragment like #icon-name to a data: URI. While fragments work in standard URLs (e.g., icons.svg#home), the data: URI scheme simply doesn't support them.

Why It Matters

Standards compliance: Browsers may handle invalid data: URIs inconsistently. Some may silently ignore the fragment, while others may fail to render the image entirely.
Portability: Code that relies on non-standard behavior in one browser may break in another or in a future update.
Accessibility and tooling: Validators, linters, and assistive technologies expect well-formed URIs. An invalid URI can cause unexpected issues down the chain.

How to Fix It

You have several options depending on your use case:

Remove the fragment from the data: URI. If the embedded content is a complete, self-contained image, it doesn't need a fragment reference.
Inline the SVG directly into the HTML document. This lets you reference internal id values with standard fragment syntax using <use> elements.
Use an external file instead of a data: URI. Standard URLs like icons.svg#home fully support fragment identifiers.
Encode the full, standalone SVG into the data: URI so that it contains only the content you need, eliminating the need for a fragment reference.

Examples

❌ Incorrect: Fragment in a `data:` URI

<img

src="data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg'%3E%3Csymbol id='icon'%3E%3Ccircle cx='10' cy='10' r='10'/%3E%3C/symbol%3E%3C/svg%3E#icon"

alt="Icon">

The #icon fragment at the end of the data: URI violates RFC 2397 and triggers the validation error.

✅ Correct: Self-contained SVG in a `data:` URI (no fragment)

Embed only the content you need directly, without wrapping it in a <symbol> or referencing a fragment:

<img

src="data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 20 20'%3E%3Ccircle cx='10' cy='10' r='10'/%3E%3C/svg%3E"

alt="Icon">

✅ Correct: External SVG file with a fragment

Move the SVG to a separate file and reference the specific symbol using a standard URL fragment:

✅ Correct: Inline SVG with `<use>` referencing an internal `id`

If you need to reference individual symbols from a sprite, inline the SVG and use fragment references within the same document:

</symbol>

</svg>

</svg>

This approach gives you full control over individual icons without needing data: URIs at all, and it's the most flexible option for icon systems.

Invalid Example

Fixed Example

Examples

Invalid: unencoded characters in href

Valid: percent-encoded URL

Invalid: unresolved template syntax

Valid: resolved or corrected URL

Why This Is a Problem

How to Fix It

Examples

❌ Incorrect: Empty href attribute

❌ Incorrect: Empty href from a template

✅ Correct: Valid href pointing to a resource

✅ Correct: Valid href for a favicon

✅ Correct: Remove the element if no resource is needed

✅ Correct: Conditional rendering in a template

Why this matters

How to fix it

Examples

❌ Incorrect: empty id attribute

✅ Correct: meaningful id value

✅ Correct: id attribute removed entirely

Examples

Example that triggers the validator error (empty id)

Correct: remove an unnecessary empty id

Correct: provide a meaningful, unique id

Problematic label association with empty id (invalid)

Correct label–control association

Correct ARIA relationship

Correct fragment navigation target

Minimal full document (validated) demonstrating proper ids

How to fix it

Examples

❌ Bad: empty imagesizes attribute

✅ Fixed: providing a valid sizes value

✅ Fixed: simple full-width image

✅ Fixed: removing the attribute when not needed

How to fix it

Examples

❌ Empty imagesrcset triggers the error

✅ Valid imagesrcset with width descriptors

✅ Valid imagesrcset with pixel density descriptors

✅ Removing the attribute when no responsive sources exist

✅ Conditional rendering in a template

Invalid example

Valid example

HTML Examples

❌ Invalid: empty itemprop

✅ Fix: provide a valid property name or remove the attribute

How to Fix It

Examples

❌ Invalid: Empty max attribute

✅ Fixed: Providing a valid numeric value

✅ Fixed: Removing the attribute entirely

❌ Invalid: Empty max on a date input

✅ Fixed: Valid date value for max

Fixing dynamic templates

Why this matters

How to fix it

Where maxlength applies

Examples

❌ Incorrect: empty string triggers the validation error

❌ Incorrect: other invalid values

✅ Correct: explicit maximum length

✅ Correct: omit the attribute when no limit is needed

✅ Correct: maxlength on a textarea

✅ Correct: dynamic value with a fallback

Why this matters

How to fix it

Examples

❌ Invalid: empty maxlength value

❌ Invalid: non-numeric maxlength value

✅ Fixed: specific integer value

✅ Fixed: attribute omitted entirely

✅ Fixed: conditional rendering in a template

Why this matters

How to fix it

Examples

❌ Invalid: empty string for min

❌ Incorrect: Empty `href` attribute

❌ Incorrect: Empty `href` from a template

✅ Correct: Valid `href` pointing to a resource

✅ Correct: Valid `href` for a favicon

❌ Incorrect: empty `id` attribute

✅ Correct: meaningful `id` value

✅ Correct: `id` attribute removed entirely

❌ Bad: empty `imagesizes` attribute

❌ Empty `imagesrcset` triggers the error

✅ Valid `imagesrcset` with width descriptors

✅ Valid `imagesrcset` with pixel density descriptors

❌ Invalid: empty `itemprop`

❌ Invalid: Empty `max` attribute

❌ Invalid: Empty `max` on a date input

✅ Fixed: Valid date value for `max`

Where `maxlength` applies

✅ Correct: `maxlength` on a `textarea`

❌ Invalid: empty `maxlength` value

❌ Invalid: non-numeric `maxlength` value

❌ Invalid: empty string for `min`

✅ Fixed: remove `min` if no minimum is needed

❌ Invalid: empty `min` on a range input

✅ Fixed: valid `min` on a range input

❌ Invalid: empty `min` on a date input

✅ Fixed: valid `min` on a date input

❌ Empty `name` attribute triggers the error

❌ Empty `name` generated by a template

✅ Use `id` on the target element directly

✅ Use `id` on a standalone anchor if needed

✅ Migrate legacy `name` to `id`

❌ Invalid: empty `name` attribute

✅ Alternative: using `id` instead

❌ Empty `name` attribute triggers the error

✅ Providing a meaningful `name` value

✅ Removing `name` when the input isn't submitted

❌ Invalid: Empty `poster` attribute

❌ Invalid: empty string for `rows`

❌ Empty `sizes` attribute

✅ Valid `sizes` with a single default value

✅ Valid `sizes` with media conditions

✅ Removing `sizes` when using density descriptors

❌ Empty `src` attribute

❌ `src` attribute with only whitespace

✅ Valid URL in `src`