Guias HTML para valor inválido

The sizes attribute works together with srcset to help the browser choose the most appropriate image source for the current layout. It accepts a comma-separated list of entries, where each entry is an optional media condition followed by a CSS length value (called a “source size value”). The browser evaluates these entries to determine the intended display width of the image before it downloads it. Valid length values include viewport-relative units like 100vw, absolute units like 472px, or calc() expressions like calc(100vw - 2rem).

The value auto was not part of the original HTML specification for the sizes attribute. However, the sizes="auto" value has been added to the HTML living standard specifically for use with lazy-loaded images (loading="lazy"). When both loading="lazy" and sizes="auto" are present, the browser can defer size calculation until layout time, since the image won’t be fetched immediately anyway. Some validators may not yet recognize this newer addition, or the error may appear because auto is being used without loading="lazy", or combined incorrectly with other size entries like sizes="auto, 100vw".

This validation error matters for several reasons. First, if the browser doesn’t understand the sizes value, it may fall back to a default of 100vw, which could cause it to download a larger image than necessary, hurting performance. Second, malformed attribute values can lead to unpredictable behavior across different browsers. Third, standards compliance ensures your markup works reliably now and in the future.

How to Fix

You have a few options depending on your situation:

1. Replace auto with a valid CSS length. If you know the intended display size of the image, specify it directly. This is the most broadly compatible approach.

2. Use sizes="auto" only with loading="lazy". If you want the browser to automatically determine the size, ensure you also include loading="lazy" and a width attribute on the image. Note that some validators may still flag this until they update their rules.

3. Remove auto from a comma-separated list. If you have something like sizes="auto, (max-width: 600px) 100vw, 50vw", remove the auto entry entirely.

Examples

Incorrect: Using auto without lazy loading

This triggers the validation error because auto is not a valid CSS length in the traditional sizes syntax.

<img
  src="image.jpg"
  srcset="image-small.jpg 300w, image-medium.jpg 600w, image-large.jpg 1000w"
  sizes="auto, 100vw"
  alt="A scenic mountain landscape"
>

Fixed: Using a valid CSS length value

Replace auto with a concrete size or a set of media-conditioned sizes.

<img
  src="image.jpg"
  srcset="image-small.jpg 300w, image-medium.jpg 600w, image-large.jpg 1000w"
  sizes="(max-width: 472px) 100vw, 472px"
  alt="A scenic mountain landscape"
>

In this example, when the viewport is 472 pixels wide or smaller, the image takes up the full viewport width (100vw). For wider viewports, the browser knows the image will display at 472px wide and selects the best source from srcset accordingly.

Fixed: Using auto with lazy loading

If you want the browser to determine the display size automatically, pair sizes="auto" with loading="lazy" and explicit dimensions.

<img
  src="image.jpg"
  srcset="image-small.jpg 300w, image-medium.jpg 600w, image-large.jpg 1000w"
  sizes="auto"
  width="600"
  height="400"
  loading="lazy"
  alt="A scenic mountain landscape"
>

The width and height attributes help the browser reserve the correct space in the layout, and loading="lazy" allows the browser to defer both loading and size calculation until the image is near the viewport.

Fixed: Using calc() for dynamic sizing

If your image sits inside a container with padding, you can use calc() for a precise size hint.

<img
  src="image.jpg"
  srcset="image-small.jpg 300w, image-medium.jpg 600w, image-large.jpg 1000w"
  sizes="calc(100vw - 2rem)"
  alt="A scenic mountain landscape"
>

The sizes and srcset attributes work together to enable responsive images, but they serve distinct roles and use different syntax. The srcset attribute lists available image files along with their intrinsic widths using the w descriptor (e.g., 800w means the image file is 800 pixels wide). The sizes attribute, on the other hand, tells the browser how wide the image will actually be rendered in the layout, using standard CSS length units. The browser combines this information — knowing which files are available and how large the image will appear — to choose the most efficient file to download.

A common mistake is mixing up these two syntaxes, typically by copying a width descriptor like 860w from srcset and placing it into sizes. Since w is not a CSS unit, the validator rejects it. This matters because an invalid sizes value prevents the browser from correctly calculating which image source to use, potentially causing it to download an unnecessarily large image (wasting bandwidth) or a too-small image (resulting in poor quality).

How the sizes attribute works

The sizes attribute accepts a comma-separated list of media conditions paired with CSS lengths, plus an optional default length at the end. Each entry follows the pattern (media-condition) length. The browser evaluates the conditions in order and uses the length from the first matching condition. If none match, it uses the final default value.

Valid CSS length units include px, em, rem, vw, vh, ch, cm, mm, in, pt, pc, and CSS calc() expressions. You can combine units with calc() for more precise sizing — for example, calc(100vw - 2rem).

Examples

❌ Incorrect: using w in sizes

This triggers the validation error because 860w is a srcset width descriptor, not a CSS length:

<img
  alt="A landscape photo"
  sizes="860w"
  srcset="photo-small.jpg 430w, photo-large.jpg 860w"
  src="photo-large.jpg">

✅ Correct: using px in sizes

Replace the w value with a CSS length that reflects the image’s actual display size:

<img
  alt="A landscape photo"
  sizes="860px"
  srcset="photo-small.jpg 430w, photo-large.jpg 860w"
  src="photo-large.jpg">

✅ Correct: responsive sizes with media conditions

Use media conditions to specify different display sizes at different viewport widths:

<img
  alt="A landscape photo"
  sizes="(min-width: 1024px) 860px, (min-width: 568px) 430px, 100vw"
  srcset="photo-small.jpg 430w, photo-large.jpg 860w"
  src="photo-large.jpg">

This tells the browser:

• On viewports 1024px and wider, the image displays at 860px wide.
• On viewports 568px and wider, the image displays at 430px wide.
• On smaller viewports, the image fills the full viewport width (100vw).

✅ Correct: using calc() in sizes

When the image width depends on padding or margins, calc() provides precise sizing:

<img
  alt="A landscape photo"
  sizes="(min-width: 768px) calc(50vw - 2rem), calc(100vw - 1rem)"
  srcset="photo-small.jpg 400w, photo-medium.jpg 800w, photo-large.jpg 1200w"
  src="photo-medium.jpg">

Key takeaways

• The w descriptor belongs only in srcset, where it describes the intrinsic width of each image file.
• The sizes attribute uses CSS length units (px, vw, em, calc(), etc.) to describe how wide the image will appear on screen.
• If your image always displays at a fixed width, a simple value like sizes="300px" is sufficient.
• If your image width varies by viewport, use media conditions with appropriate CSS lengths to give the browser the information it needs to select the best source.

Backslashes are not valid delimiters in URLs according to the URL Living Standard. While some browsers may silently normalize backslashes to forward slashes, this behavior is non-standard and should not be relied upon. Using backslashes in URLs can lead to broken images, unexpected behavior across different browsers, and failures in environments that strictly follow URL specifications (such as HTTP servers, CDNs, or validation tools).

This issue commonly arises when developers copy file paths directly from a Windows file system — where \ is the directory separator — and paste them into HTML src attributes. It can also happen when server-side code generates URLs using OS-level path functions instead of URL-building utilities.

Beyond standards compliance, this matters for several practical reasons:

• Cross-browser reliability: Not all browsers or HTTP clients normalize backslashes the same way.
• Server compatibility: Many web servers interpret backslashes literally, resulting in 404 errors.
• Portability: Code with backslash paths may work in local development on Windows but break when deployed to a Linux-based server.

To fix the issue, locate every backslash in the src attribute value and replace it with a forward slash. This applies to all URL contexts, not just img elements — though the validator specifically flags it here.

Examples

❌ Incorrect: backslashes in the src path

<img src="images\photos\landscape.jpg" alt="Mountain landscape">

<img src="https://example.com\img\small\photo.png" alt="Example image">

Both of these use backslashes as path delimiters, which triggers the validation error.

✅ Correct: forward slashes in the src path

<img src="images/photos/landscape.jpg" alt="Mountain landscape">

<img src="https://example.com/img/small/photo.png" alt="Example image">

Simply replacing \ with / resolves the issue and produces a valid, portable URL.

❌ Incorrect: mixed delimiters

<img src="assets/images\banner\hero.webp" alt="Hero banner">

Even a single backslash in an otherwise valid path will trigger this error.

✅ Correct: consistent forward slashes

<img src="assets/images/banner/hero.webp" alt="Hero banner">

Tips to avoid this issue

• Don’t copy-paste Windows file paths directly into HTML. Always convert backslashes to forward slashes.
• Use your editor’s find-and-replace to search for \ within src attributes across your project.
• If generating URLs in server-side code, use URL-building functions rather than file-system path functions. For example, in Node.js, use the url module or template literals with / instead of path.join(), which uses \ on Windows.
• Run the W3C validator regularly during development to catch issues like this before deployment.

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

While most modern browsers will silently fix this by encoding the space before making the request, relying on this behavior is problematic for several reasons:

• Standards compliance: The HTML specification requires that the src attribute contain a valid URL. A URL with a literal space is technically malformed.
• Cross-browser reliability: Not all user agents, proxies, or CDNs handle malformed URLs the same way. What works in one browser may fail in another context.
• Interoperability: Other tools that consume your HTML — such as linters, crawlers, screen readers, and build pipelines — may not be as forgiving as browsers.
• Copy-paste and linking issues: Literal spaces in URLs cause problems when users copy links or when URLs appear in plain-text contexts like emails, where the space may break the URL in two.

How to fix it

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

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

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

Examples

❌ Invalid: space in the path segment

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

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

✅ Fixed: percent-encode the space

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

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

✅ Better: rename to avoid spaces entirely

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

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

❌ Invalid: space in a local relative path

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

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

✅ Fixed: encode or rename the local file

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

Or, better yet:

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

Multiple spaces and other special characters

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

<!-- Invalid -->

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

<!-- Valid -->

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

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

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

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

When the W3C HTML Validator reports “Expected a slash,” it means the URL parser encountered an unexpected character where a / should appear. URLs follow a strict syntax defined by the URL Living Standard. For scheme-based URLs, the format requires the scheme (like https:) to be immediately followed by // and then the authority (hostname). Any deviation — such as a space, a missing slash, or an encoded character in the wrong place — will make the URL invalid.

This matters for several reasons. Browsers may attempt to correct malformed URLs, but their behavior is inconsistent and unpredictable. A broken src attribute can cause images not to load, scripts to fail silently, or media elements to show fallback content. Screen readers and assistive technologies rely on valid URLs to provide meaningful information to users. Search engine crawlers may also fail to follow or index resources with malformed URLs.

Common causes of this error include:

• Accidental spaces inserted within the URL, especially between the scheme and the double slashes (e.g., https: // instead of https://).
• Missing slashes in the scheme (e.g., https:/example.com with only one slash).
• Copy-paste artifacts where invisible characters or line breaks get embedded in the URL string.
• Template or CMS issues where dynamic URL generation introduces unexpected characters.

To fix the issue, carefully inspect the src attribute value and ensure it forms a valid, complete URL with no stray characters. If the URL is generated dynamically, check the code that constructs it.

Examples

Incorrect: space between scheme and slashes

<img src="https: //example.com/photo.jpg" alt="A photo">

The space after https: breaks the URL. The validator expects a / immediately after the colon but finds a space instead.

Fixed: remove the space

<img src="https://example.com/photo.jpg" alt="A photo">

Incorrect: single slash instead of double slash

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

The URL scheme requires // after https:, but only one / is present.

Fixed: use the correct double slash

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

Incorrect: line break embedded in the URL

Sometimes copy-pasting or template rendering introduces hidden line breaks:

<video src="https://
example.com/video.mp4">
</video>

Fixed: ensure the URL is on a single line with no breaks

<video src="https://example.com/video.mp4"></video>

Incorrect: protocol-relative URL with a missing slash

<img src="/example.com/logo.png" alt="Logo">

If the intent is a protocol-relative URL, it needs two slashes. With a single slash, this becomes an absolute path on the current domain rather than a reference to example.com.

Fixed: use two slashes for protocol-relative URLs

<img src="//example.com/logo.png" alt="Logo">

Tip: If you’re having trouble spotting the problem, paste the URL into your browser’s address bar to see if it resolves correctly, or use a text editor that reveals invisible characters (like zero-width spaces or non-breaking spaces) that may be hiding in the string.

The srcset attribute allows you to provide multiple image sources so the browser can choose the most appropriate one based on the user’s viewport size or screen density. There are two distinct modes for srcset:

1. Width descriptor mode — each candidate specifies its intrinsic width using a w descriptor (e.g., 400w). This mode requires the sizes attribute so the browser knows how much space the image will occupy in the layout and can calculate which source to download.
2. Pixel density descriptor mode — each candidate specifies a pixel density using an x descriptor (e.g., 2x). This mode must not include a sizes attribute.

When you include a sizes attribute but forget to add width descriptors to one or more srcset entries, the browser has incomplete information. The HTML specification explicitly states that if sizes is present, all image candidate strings must use width descriptors. An entry without a descriptor defaults to 1x (a pixel density descriptor), which conflicts with the width descriptor mode triggered by sizes. This mismatch causes the W3C validator to report the error.

Beyond validation, this matters for real-world performance. Responsive images are one of the most effective tools for reducing page weight on smaller screens. If the descriptors are missing or mismatched, browsers may download an image that is too large or too small, hurting both performance and visual quality.

How to fix it

You have two options depending on your use case:

Option 1: Add width descriptors to all srcset candidates

If you need the browser to select images based on viewport size (the most common responsive images pattern), keep the sizes attribute and ensure every srcset entry has a w descriptor that matches the image’s intrinsic pixel width.

Option 2: Remove sizes and use pixel density descriptors

If you only need to serve higher-resolution images for high-DPI screens (e.g., Retina displays) and the image always renders at the same CSS size, remove the sizes attribute and use x descriptors instead.

Examples

❌ Incorrect: sizes present but srcset entry has no width descriptor

<img
  src="photo-800.jpg"
  srcset="photo-400.jpg, photo-800.jpg"
  sizes="(min-width: 600px) 800px, 100vw"
  alt="A mountain landscape">

Both srcset entries lack a width descriptor. Because sizes is present, the validator reports an error for each candidate.

✅ Correct: sizes present with width descriptors on every candidate

<img
  src="photo-800.jpg"
  srcset="photo-400.jpg 400w, photo-800.jpg 800w"
  sizes="(min-width: 600px) 800px, 100vw"
  alt="A mountain landscape">

Each candidate now specifies its intrinsic width (400w and 800w), which tells the browser the actual pixel width of each source file. The browser combines this with the sizes value to pick the best match.

❌ Incorrect: mixing width descriptors and bare entries

<img
  src="photo-800.jpg"
  srcset="photo-400.jpg 400w, photo-800.jpg"
  sizes="(min-width: 600px) 800px, 100vw"
  alt="A mountain landscape">

The second candidate (photo-800.jpg) is missing its width descriptor. All candidates must have one when sizes is present — not just some of them.

✅ Correct: pixel density descriptors without sizes

<img
  src="photo-800.jpg"
  srcset="photo-800.jpg 1x, photo-1600.jpg 2x"
  alt="A mountain landscape">

Here the sizes attribute is removed, and each srcset entry uses a pixel density descriptor (1x, 2x). This is valid and appropriate when the image always occupies the same CSS dimensions regardless of viewport width.

❌ Incorrect: using sizes with pixel density descriptors

<img
  src="photo-800.jpg"
  srcset="photo-800.jpg 1x, photo-1600.jpg 2x"
  sizes="(min-width: 600px) 800px, 100vw"
  alt="A mountain landscape">

The sizes attribute and x descriptors cannot be combined. Either switch to w descriptors or remove sizes.

Quick reference

Remember that the w value in srcset refers to the image file’s intrinsic pixel width (e.g., an 800-pixel-wide image gets 800w), while values in sizes use CSS length units like px, vw, or em to describe how wide the image will render in the layout.

The srcset attribute lets browsers intelligently choose which image to load based on the viewport size and device pixel ratio. Each entry in a srcset consists of a URL followed by either a width descriptor (like 300w) or a pixel density descriptor (like 2x). When using width descriptors, the value represents the intrinsic pixel width of the image file — that is, the actual width of the image as stored on disk.

A width descriptor of 0w violates the HTML specification, which requires width descriptors to be integers greater than zero. A zero-width image cannot meaningfully participate in the browser’s source selection process. The browser uses these width values in combination with the sizes attribute to calculate which image best fits the current layout — a value of zero would break this calculation entirely.

This issue commonly occurs when:

• Image dimensions are dynamically generated and a fallback of 0 is used for missing data.
• A placeholder or empty state is accidentally included in the srcset.
• A CMS or build tool outputs a 0w descriptor for images whose dimensions weren’t computed.

Why it matters

• Standards compliance: The HTML specification explicitly requires width descriptors to be positive integers. Validators will flag 0w as an error.
• Browser behavior: While browsers may silently ignore the invalid entry, you can’t rely on consistent handling across all browsers and versions. The image selection algorithm may behave unpredictably.
• Performance: A well-formed srcset is key to responsive image loading. Invalid descriptors can prevent browsers from selecting the optimal image, leading to unnecessarily large downloads or poor image quality.

How to fix it

1. Open the image file associated with the 0w descriptor and check its actual pixel width using an image editor or the command line.
2. Replace 0w with the correct width (e.g., 150w for a 150-pixel-wide image).
3. If the image is truly zero-width or a placeholder, remove that entry from the srcset entirely.
4. Ensure every remaining entry has a unique, positive width descriptor.

Examples

❌ Invalid: width descriptor of 0w

<picture>
  <source
    srcset="/images/icon_placeholder.png 0w,
            /images/icon_large.png 600w"
    media="(max-width: 600px)">
  <img src="/images/icon_fallback.png" alt="App logo">
</picture>

The 0w descriptor triggers the validation error because zero is not a valid width.

✅ Fixed: all width descriptors are positive

<picture>
  <source
    srcset="/images/icon_small.png 300w,
            /images/icon_large.png 600w"
    media="(max-width: 600px)">
  <img src="/images/icon_fallback.png" alt="App logo">
</picture>

Each entry now has a meaningful width descriptor (300w and 600w) that reflects the actual pixel width of the corresponding image.

❌ Invalid: 0w on an <img> element

<img
  srcset="/images/hero_tiny.jpg 0w,
          /images/hero_medium.jpg 800w,
          /images/hero_large.jpg 1200w"
  sizes="100vw"
  src="/images/hero_medium.jpg"
  alt="Mountain landscape">

✅ Fixed: placeholder entry removed or corrected

If the tiny image is 400 pixels wide, use 400w:

<img
  srcset="/images/hero_tiny.jpg 400w,
          /images/hero_medium.jpg 800w,
          /images/hero_large.jpg 1200w"
  sizes="100vw"
  src="/images/hero_medium.jpg"
  alt="Mountain landscape">

Alternatively, if the image doesn’t belong in the set at all, simply remove it:

<img
  srcset="/images/hero_medium.jpg 800w,
          /images/hero_large.jpg 1200w"
  sizes="100vw"
  src="/images/hero_medium.jpg"
  alt="Mountain landscape">

When using a build tool or CMS that generates srcset values dynamically, add a check to filter out any entries where the computed width is zero or missing before rendering the attribute. This prevents the invalid markup from reaching production.

The type attribute on an <a> element is an advisory hint that tells the browser what media type (MIME type) to expect at the linked resource. A valid MIME type follows a strict format: a type, a / separator, and a subtype (e.g., text/html, application/pdf, image/png). Each part must consist of token characters — letters, digits, and certain symbols — but not spaces.

This validation error occurs when the MIME type value contains a space or other unexpected character in a position where only token characters or a / are allowed. Common causes include:

• Accidental spaces within the MIME type (e.g., application/ pdf or application /pdf).
• Multiple MIME types separated by spaces (e.g., text/html text/plain), which is not valid since the attribute accepts only a single MIME type.
• Typos or copy-paste errors that introduce whitespace or non-token characters.

While the type attribute is purely advisory and browsers won’t refuse to follow a link based on it, an invalid value defeats its purpose and signals sloppy markup. Standards-compliant HTML ensures your pages are interpreted consistently and avoids confusing tools, screen readers, or other user agents that may parse this attribute.

Examples

Incorrect: Space within the MIME type

<a href="report.pdf" type="application/ pdf">Download Report</a>

The space after the / makes this an invalid MIME type.

Incorrect: Multiple MIME types separated by a space

<a href="data.csv" type="text/csv text/plain">Download Data</a>

The type attribute only accepts a single MIME type. The space between text/csv and text/plain triggers the error.

Incorrect: Leading or trailing spaces

<a href="photo.jpg" type=" image/jpeg ">View Photo</a>

Spaces before or after the MIME type are not permitted.

Correct: Valid MIME type with no spaces

<a href="report.pdf" type="application/pdf">Download Report</a>

Correct: Other common valid MIME types

<a href="data.csv" type="text/csv">Download Data</a>
<a href="photo.jpg" type="image/jpeg">View Photo</a>
<a href="archive.zip" type="application/zip">Download Archive</a>

Correct: MIME type with a parameter

MIME types can include parameters separated by a semicolon — no spaces are required, though a single space after the semicolon is permitted per the MIME specification:

<a href="page.html" type="text/html; charset=utf-8">View Page</a>

How to Fix

1. Inspect the type value — look for any spaces within the type or subtype portions (before or after the /).
2. Remove extra spaces — ensure the value is a single, properly formatted MIME type like type/subtype.
3. Use only one MIME type — if you’ve listed multiple types, pick the one that accurately describes the linked resource.
4. Verify the MIME type is valid — consult the IANA Media Types registry to confirm you’re using a recognized type.
5. Consider removing the attribute — since type is purely advisory on <a> elements, if you’re unsure of the correct MIME type, omitting the attribute entirely is perfectly valid.

A MIME type (also called a media type) always follows the format type/subtype, such as text/html, application/pdf, or image/jpeg. The “type” part indicates the general category (e.g., text, image, application, audio, video), and the “subtype” specifies the exact format within that category. When the validator reports “Subtype missing,” it means the value you provided either lacks the /subtype portion or isn’t a valid MIME type structure at all.

A common cause of this error is misunderstanding the purpose of the type attribute on <a> elements. The type attribute is not used to change the behavior or appearance of the link (the way type works on <input> or <button> elements). Instead, it serves as an advisory hint to the browser about what kind of resource the link points to. The browser may use this information to adjust its UI — for example, showing a download prompt for application/pdf — but it is not required to act on it.

Because of this misunderstanding, developers sometimes write type="button" on an <a> element, thinking it will make the link behave like a button. The value button is not a valid MIME type (it has no subtype), so the validator flags it. If you need a button, use a <button> element instead. If you need a styled link that looks like a button, keep the <a> element and use CSS for styling.

Why this matters

• Standards compliance: The HTML specification requires the type attribute on <a> to be a valid MIME type string. An invalid value violates the spec and may be ignored by browsers or cause unexpected behavior.
• Accessibility and semantics: Using type="button" on a link can create confusion about the element’s role. Screen readers and assistive technologies rely on correct semantics to convey meaning to users.
• Browser behavior: While browsers are generally forgiving, an invalid type value provides no useful information and could interfere with how the browser handles the linked resource.

How to fix it

1. If you intended to hint at the linked resource’s MIME type, make sure you provide a complete type/subtype value — for example, application/pdf rather than just application.
2. If you used type to try to style or change the link’s behavior, remove the type attribute entirely. Use CSS for visual styling or switch to a more appropriate element like <button>.
3. If you don’t need the type attribute, simply remove it. It’s entirely optional on <a> elements.

Examples

Incorrect: missing subtype

<a href="report.pdf" type="application">Download report</a>

The value application is incomplete — it’s missing the subtype portion after the slash.

Incorrect: not a MIME type at all

<a href="/order.php" type="button">Submit</a>

The value button is not a MIME type. This often stems from confusing the type attribute on <a> with the type attribute on <input> or <button>.

Correct: valid MIME type

<a href="report.pdf" type="application/pdf">Download report</a>

<a href="photo.jpeg" type="image/jpeg">See a photo</a>

The type attribute uses a properly formatted MIME type with both a type and subtype.

Correct: removing the attribute entirely

<a href="/order.php">Submit</a>

If the type attribute isn’t serving a real purpose, the simplest fix is to remove it.

Correct: using a button element instead

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

If you need actual button behavior (such as submitting a form), use a <button> element rather than an <a> element with an invalid type.

The type attribute on a <link> element specifies the MIME type of the linked resource. MIME types follow a specific format: a type and subtype separated by a single forward slash, like text/css, image/png, or application/json. They never contain the :// sequence found in URLs.

This error most commonly occurs when a URL is accidentally placed in the type attribute instead of in the href attribute, or when the attributes are confused with one another. For example, writing type="https://example.com/style.css" triggers this error because the validator encounters the colon in https: where it expects a valid MIME type token.

Another common cause is copying type values from other contexts (such as XML namespaces or schema references) that use URL-like strings, and mistakenly applying them to the type attribute.

Why this matters

• Standards compliance: The HTML specification requires the type attribute to contain a valid MIME type. Invalid values violate the spec and may cause browsers to misinterpret or ignore the linked resource.
• Browser behavior: Browsers use the type attribute as a hint for how to handle the resource. An invalid MIME type could lead the browser to skip loading the resource entirely, causing missing styles, icons, or other assets.
• Maintainability: Incorrect attribute values signal to other developers (and automated tools) that something is misconfigured, making the code harder to maintain.

How to fix it

1. Check that type contains a valid MIME type, not a URL or other string. Common valid values include text/css, image/png, image/x-icon, image/svg+xml, and application/rss+xml.
2. Ensure URLs are in the href attribute, not type.
3. Consider removing type entirely. For stylesheets, modern browsers default to text/css, so type="text/css" is optional. For many use cases, the type attribute can be safely omitted.

Examples

❌ Incorrect: URL used as the type value

<link rel="stylesheet" type="https://example.com/style.css">

The validator sees the colon in https: and reports the error because this is a URL, not a MIME type.

❌ Incorrect: Attributes swapped

<link rel="icon" type="https://example.com/favicon.png" href="image/png">

Here the type and href values have been accidentally swapped.

✅ Correct: Valid MIME type with proper href

<link rel="icon" type="image/png" href="https://example.com/favicon.png">

✅ Correct: Stylesheet with valid type

<link rel="stylesheet" type="text/css" href="/css/style.css">

✅ Correct: Stylesheet without type (also valid)

<link rel="stylesheet" href="/css/style.css">

Since browsers default to text/css for stylesheets, omitting type is perfectly valid and keeps your markup cleaner.

✅ Correct: RSS feed link

<link rel="alternate" type="application/rss+xml" title="RSS Feed" href="/feed.xml">

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 text-transform CSS property controls the capitalization of text within an element. It’s commonly used to enforce consistent text casing — for example, making headings appear in all uppercase or ensuring navigation links are lowercase — without changing the actual content in the HTML. When the validator encounters a value it doesn’t recognize for this property, it flags it as invalid.

This error can occur for several reasons:

• Typos — writing upppercase instead of uppercase, or Capitalize instead of capitalize (CSS values are case-sensitive in validation contexts).
• Incorrect values — using values from other properties, like bold, italic, or center, which don’t apply to text-transform.
• Non-standard values — using browser-specific or experimental values that aren’t part of the CSS specification.
• Wrong property — confusing text-transform with text-decoration, text-align, or font-variant, and using their values here instead.

Fixing this matters because invalid CSS can lead to unpredictable rendering across browsers. While most browsers will simply ignore an invalid declaration, your intended styling won’t be applied, potentially breaking your design. Keeping your CSS valid also improves maintainability and ensures forward compatibility.

Valid values for text-transform

Examples

Incorrect — invalid value

In this example, bold is not a valid text-transform value. It likely belongs on the font-weight property instead.

<p style="text-transform: bold;">Welcome to our site</p>

Similarly, a simple typo will trigger this error:

<p style="text-transform: uppercse;">Welcome to our site</p>

Correct — using valid values

<p style="text-transform: uppercase;">Welcome to our site</p>

<p style="text-transform: capitalize;">Welcome to our site</p>

Correct — separating concerns with the right properties

If you intended to make text bold and uppercase, use the appropriate property for each effect:

<p style="font-weight: bold; text-transform: uppercase;">Welcome to our site</p>

Correct — using text-transform in a stylesheet

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>Text Transform Example</title>
  <style>
    .heading {
      text-transform: uppercase;
    }
    .name {
      text-transform: capitalize;
    }
    .code-snippet {
      text-transform: none;
    }
  </style>
</head>
<body>
  <h1 class="heading">site navigation</h1>
  <p class="name">john doe</p>
  <code class="code-snippet">myVariable</code>
</body>
</html>

If you’re unsure which value you need, uppercase and capitalize are the most commonly used. Use none when you need to override a text-transform rule inherited from a parent element.