HTML Guides for bad value

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

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

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

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

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

Correct: Other common valid MIME types

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

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

<ahref="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:

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

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

<ahref="/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

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

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

<ahref="/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

<buttontype="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 <button> only accepts three keywords — submit, reset, and button — so any other value is rejected.

type is an enumerated attribute, not a free-form one. submit posts the form (and is what a button does when the attribute is absent), reset clears the form fields, and button does nothing on its own and is meant to be wired up with JavaScript. Anything outside that set is invalid markup, and the browser falls back to submit, so a button you expected to stay inert may submit the form instead.

If you want the default behavior, leave the attribute off or write type="submit" explicitly; if the button should not submit, use type="button".

Invalid example

<buttontype="default">Save</button>

Valid example

<buttontype="submit">Save</button>

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

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

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

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

✅ Correct: Stylesheet with valid type

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

✅ Correct: Stylesheet without type (also valid)

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

<linkrel="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:

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

<gid="Group 270">

<circlecx="50"cy="50"r="40"/>

</g>

</svg>

Invalid: Name starts with a digit

XML 1.0 names cannot begin with a number:

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

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

</svg>

Invalid: Special characters in the name

Characters like ( and ) are not allowed:

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

<pathid="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:

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

<gid="group-270">

<circlecx="50"cy="50"r="40"/>

</g>

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

<pathid="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.

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

Similarly, a simple typo will trigger this error:

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

Correct — using valid values

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

<pstyle="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:

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

Correct — using text-transform in a stylesheet

<!DOCTYPE html>

<htmllang="en">

<head>

<metacharset="utf-8">

<title>Text Transform Example</title>

<style>

.heading{

text-transform: uppercase;

}

.name{

text-transform: capitalize;

}

.code-snippet{

text-transform: none;

}

</style>

</head>

<body>

<h1class="heading">site navigation</h1>

<pclass="name">john doe</p>

<codeclass="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.