HTML Guides for href

The W3C HTML Validator checks that URLs provided in href attributes conform to the URL specification. Square brackets ([ and ]) are reserved characters with very specific, limited uses in URLs — they are only permitted in the host portion of a URL to denote IPv6 addresses (e.g., http://[::1]/). When they appear elsewhere, such as in the scheme data, path, or query string without being percent-encoded, the URL is considered malformed.

This commonly happens in a few scenarios:

• Mailto links where someone wraps an email address in brackets, like mailto:[user@example.com].
• Template variables that haven’t been processed, leaving literal bracket syntax (e.g., {{, [, ]) in the rendered HTML.
• Manually constructed URLs where brackets are mistakenly used as part of the path or query string instead of being percent-encoded as %5B and %5D.

Using invalid URLs can cause browsers to misinterpret the link destination, break navigation, or cause unexpected behavior. Assistive technologies such as screen readers also rely on well-formed URLs to correctly communicate link targets to users. Keeping your URLs standards-compliant ensures consistent, predictable behavior across all browsers and devices.

How to fix it

1. Remove unnecessary brackets. If the brackets are not part of the actual data (e.g., decorative brackets around an email address), simply delete them.
2. Percent-encode brackets when they are part of the data. If you genuinely need square brackets in a URL’s path or query string, encode [ as %5B and ] as %5D.
3. Check your templating engine output. If you use a templating system, inspect the final rendered HTML in a browser to make sure template syntax has been fully replaced with valid values.

Examples

Invalid: square brackets in a mailto URL

The brackets around the email address are not valid URL characters in this context.

<a href="mailto:[user@example.com]">Email Us</a>

Fixed: remove the brackets

<a href="mailto:user@example.com">Email Us</a>

Invalid: square brackets in a query string

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

Fixed: percent-encode the brackets

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

Invalid: unprocessed template syntax in rendered HTML

If your templating engine fails to replace a variable, the final HTML may contain bracket characters:

<a href="mailto:[% user.email %]">Email Us</a>

Fixed: ensure the template renders a valid URL

Make sure the template variable resolves correctly. The rendered output should look like:

<a href="mailto:user@example.com">Email Us</a>

In your template source, this might be written as:

<a href="mailto:{{ user.email }}">Email Us</a>

The key is that the final HTML delivered to the browser must contain a valid, bracket-free URL (unless the brackets are properly percent-encoded). Always validate your rendered output, not just your template source, to catch issues like this.

A URL is made up of several parts: scheme, host (domain), path, query, and fragment. While some of these parts allow certain special characters (often percent-encoded), the host portion has strict rules. Domain names follow the DNS naming conventions, which only permit ASCII letters (a-z, A-Z), digits (0-9), hyphens (-), and dots (.) as label separators. Spaces are categorically forbidden.

This validation error typically occurs in two scenarios:

1. A literal space appears in the domain, e.g., http://my domain.com. This is often a typo or a copy-paste error.
2. A percent-encoded space (%20) appears in the domain, e.g., http://my%20domain.com. While %20 is valid in URL paths and query strings, it is not valid in the host portion. Percent-encoding does not make a space legal in a domain name — it still resolves to a space character, which DNS cannot handle.

Why this is a problem

• Broken links: Browsers cannot resolve a domain with spaces to an actual server. Users clicking the link will get an error or be taken nowhere.
• Accessibility: Screen readers and assistive technologies may announce the link, but users will encounter a dead end, creating a frustrating experience.
• Standards compliance: The WHATWG URL Standard explicitly forbids spaces in the host component. The W3C validator flags this to help you catch what is almost certainly a mistake.
• SEO impact: Search engine crawlers will treat the URL as invalid and will not follow or index it.

How to fix it

• Check for typos: The most common fix is to correct the domain to the actual, valid domain name you intended.
• Replace spaces with hyphens: If the intended domain genuinely has a word separator, the standard convention is to use hyphens (e.g., my-domain.com).
• Remove spaces entirely: Sometimes spaces are accidentally introduced and simply need to be removed (e.g., mydomain.com).
• Check the path vs. host: If the space belongs in a file path or query parameter rather than the domain, make sure it’s in the correct part of the URL and properly percent-encoded there.

Examples

❌ Literal space in the domain

<a href="http://my domain.com/page">Visit site</a>

❌ Percent-encoded space in the domain

<a href="http://my%20domain.com/page">Visit site</a>

✅ Fixed: use a hyphen in the domain

<a href="http://my-domain.com/page">Visit site</a>

✅ Fixed: remove the space entirely

<a href="http://mydomain.com/page">Visit site</a>

✅ Spaces are fine in the path (percent-encoded)

Note that %20 is valid in the path portion of a URL — just not in the domain:

<a href="http://mydomain.com/my%20page">Visit page</a>

Common mistake: space before or after the domain

Sometimes the space is hard to spot because it’s at the beginning or end of the URL, or between the scheme and domain:

<!-- ❌ Trailing space in domain -->

<a href="http://mydomain.com /page">Visit site</a>

<!-- ✅ Fixed -->

<a href="http://mydomain.com/page">Visit site</a>

If your URLs are generated dynamically (e.g., from a CMS or database), make sure to trim whitespace from the domain portion before constructing the full URL. A quick way to catch these issues during development is to validate your HTML regularly with the W3C Markup Validation Service.

In the structure of a URL, the @ symbol has a special meaning: it separates the userinfo component (username and password) from the host. A URL with credentials follows this pattern:

scheme://username:password@hostname/path

When the username or password itself contains an @ character — for example, an email address used as a username — the browser or URL parser may not be able to determine where the credentials end and the hostname begins. For instance, in http://user@name:pass@example.com, it’s unclear whether the host is name or example.com.

The URL Standard (maintained by WHATWG) requires that any @ appearing within the userinfo component be percent-encoded as %40. Percent-encoding replaces the literal character with a % followed by its hexadecimal ASCII code (40 for @). This removes the ambiguity and ensures all parsers interpret the URL identically.

While modern browsers may attempt to handle ambiguous URLs, the behavior is not guaranteed to be consistent across all user agents, link checkers, or HTTP clients. Properly encoding these characters ensures reliable behavior everywhere and keeps your HTML valid.

Note: Including credentials directly in URLs is generally discouraged for security reasons, as they may be exposed in browser history, server logs, and referrer headers. Consider alternative authentication methods when possible.

Examples

❌ Incorrect: unencoded @ in the username

<a href="http://user@name:password@example.com/path">Login</a>

Here, the parser cannot reliably distinguish user@name as the username from the @ that separates credentials from the host.

✅ Correct: percent-encoded @ in the username

<a href="http://user%40name:password@example.com/path">Login</a>

The @ within the username is encoded as %40, leaving only one literal @ to serve as the delimiter before the hostname.

❌ Incorrect: unencoded @ in the password

<a href="http://admin:p@ss@example.com/dashboard">Dashboard</a>

✅ Correct: percent-encoded @ in the password

<a href="http://admin:p%40ss@example.com/dashboard">Dashboard</a>

❌ Incorrect: email address used as username without encoding

<a href="ftp://joe@example.org:secret@ftp.example.com/files">Files</a>

✅ Correct: email address with @ percent-encoded

<a href="ftp://joe%40example.org:secret@ftp.example.com/files">Files</a>

To fix this issue, identify every @ character that appears before the final @ in the authority section of the URL and replace it with %40. The last @ in the authority is the actual delimiter and must remain as a literal character.

The <area> element defines a clickable region within an <map> element, which is used with images to create image maps. When an <area> element includes an href attribute, the browser treats it as a hyperlink. The value of href must be a valid URL, and http:// alone fails validation because the URL specification requires a host after the :// separator. An empty host is not permitted.

This matters for several reasons. Browsers may handle malformed URLs unpredictably — some might ignore the link, others might attempt navigation to a nonsensical destination, and others might throw a network error. Screen readers and other assistive technologies rely on valid href values to announce links correctly and provide meaningful navigation to users. From a standards compliance perspective, the WHATWG URL Standard explicitly rejects URLs with empty hosts, and the W3C validator flags this as an error.

This issue commonly appears when placeholder URLs are left in during development, when CMS tools generate incomplete markup, or when a URL value is dynamically constructed but the host portion ends up empty.

How to fix it

• If the area should link somewhere, replace http:// with the full, intended URL including the host (e.g., https://example.com/page).
• If the area is a temporary placeholder, use href="#" to create a valid no-op link, though be aware this will scroll the page to the top when clicked.
• If the area shouldn’t be interactive, remove the href attribute entirely. Without href, the <area> element is not a hyperlink and won’t be clickable.

Examples

Invalid: empty host in URL

The value http:// has no host, which triggers the validation error.

<img src="diagram.png" alt="Site map" usemap="#siteMap">
<map name="siteMap">
  <area shape="rect" coords="30,23,183,191" href="http://" alt="Home page">
</map>

Fixed: complete URL with a valid host

Providing a full URL with a host resolves the error.

<img src="diagram.png" alt="Site map" usemap="#siteMap">
<map name="siteMap">
  <area shape="rect" coords="30,23,183,191" href="https://example.com/" alt="Home page">
</map>

Fixed: placeholder link with #

If you need the area to remain clickable but don’t have a destination yet, href="#" is a valid placeholder.

<img src="diagram.png" alt="Site map" usemap="#siteMap">
<map name="siteMap">
  <area shape="rect" coords="30,23,183,191" href="#" alt="Home page">
</map>

Fixed: non-interactive area without href

If the area doesn’t need to be a link, simply omit the href attribute.

<img src="diagram.png" alt="Site map" usemap="#siteMap">
<map name="siteMap">
  <area shape="rect" coords="30,23,183,191" alt="Home page">
</map>

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

Common characters that trigger this issue include:

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

Why this matters

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

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

How to fix it

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

Examples

❌ Illegal pipe character in the query string

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

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

✅ Pipe character percent-encoded

<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Open+Sans%7CRoboto">

❌ Square brackets in the query string

Some APIs or frameworks use bracket notation in query parameters:

<link rel="stylesheet" href="https://example.com/styles?themes[]=dark&themes[]=compact">

✅ Square brackets percent-encoded

<link rel="stylesheet" href="https://example.com/styles?themes%5B%5D=dark&themes%5B%5D=compact">

❌ Space character in the query string

<link rel="stylesheet" href="https://example.com/css?file=my styles.css">

✅ Space character percent-encoded

<link rel="stylesheet" href="https://example.com/css?file=my%20styles.css">

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

According to the HTML specification, the <a> element can exist without an href attribute, but in that case it represents a placeholder where a link might otherwise have been placed. However, the validator flags this as an issue because an <a> element without href and without role is ambiguous — browsers won’t treat it as a link (it won’t be focusable or keyboard-accessible), and assistive technologies won’t know how to present it to users.

This matters for several reasons:

• Accessibility: Without href, the <a> element loses its implicit role="link" and is no longer announced as a link by screen readers. It also won’t appear in the tab order, making it invisible to keyboard users.
• Semantics: If the element is styled and scripted to behave like a button or link but lacks the proper attributes, it creates a disconnect between what users see and what the browser understands.
• Standards compliance: The spec expects you to be explicit about the element’s purpose when href is absent.

The most common cause of this issue is using <a> elements as JavaScript-only click targets without providing an href, or using them as styled containers without any interactive purpose.

How to Fix It

There are several approaches depending on your intent:

1. Add an href attribute if the element should be a link. This is the most common and recommended fix.
2. Add a role attribute if you’re deliberately using <a> without href for a specific purpose, such as role="button".
3. Use a different element entirely. If it’s not a link, consider using a <button>, <span>, or another semantically appropriate element.

Examples

❌ Missing both href and role

<a>Click here</a>

This triggers the validator error because the <a> has neither href nor role.

❌ JavaScript-only handler without href

<a onclick="doSomething()">Submit</a>

Even with an event handler, the element lacks href and role, so it fails validation and is inaccessible to keyboard users.

✅ Fix by adding an href

<a href="/about">About us</a>

Adding href makes it a proper hyperlink — focusable, keyboard-accessible, and recognized by screen readers.

✅ Fix by adding role for a non-link purpose

<a role="button" tabindex="0" onclick="doSomething()">Submit</a>

If you must use <a> without href as a button, add role="button" and tabindex="0" to ensure it’s focusable and properly announced. However, consider using a real <button> instead.

✅ Better: use the right element

<button type="button" onclick="doSomething()">Submit</button>

If the element triggers an action rather than navigating somewhere, a <button> is the correct semantic choice. It’s focusable by default, responds to keyboard events, and doesn’t need extra attributes.

✅ Placeholder anchor (intentional non-link)

<a role="link" aria-disabled="true">Coming soon</a>

If you’re intentionally showing a placeholder where a link will eventually appear, you can add a role and indicate its disabled state for assistive technologies. Alternatively, use a <span> with appropriate styling to avoid the issue altogether.

The <a> element with an href attribute is one of HTML’s most fundamental interactive elements. Browsers and assistive technologies inherently recognize it as a link — it’s focusable via the Tab key, activatable with Enter, and announced as “link” by screen readers. This built-in behavior is part of the element’s implicit ARIA role, which is link.

When you explicitly add role="link" to an <a href="..."> element, you’re telling assistive technologies something they already know. The W3C validator flags this as unnecessary because it violates the principle of not redundantly setting ARIA roles that match an element’s native semantics. This principle is codified in the first rule of ARIA use: “If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.”

While a redundant role="link" won’t typically break anything, it creates noise in your markup. It can also signal to other developers that the role is necessary, leading to confusion or cargo-cult patterns. Clean, semantic HTML that relies on native roles is easier to maintain and less error-prone.

The role="link" attribute is legitimately useful when a non-interactive element like a <span> or <div> needs to behave as a link. In that case, you must also manually implement keyboard interaction (focus via tabindex, activation via Enter key handling) and provide an accessible name. But when you already have a proper <a> element with href, all of that comes for free — no ARIA needed.

Examples

❌ Incorrect: redundant role="link" on an anchor

<a href="/about" role="link">About Us</a>

The role="link" is redundant here because the <a> element with href already has an implicit role of link.

✅ Correct: anchor without redundant role

<a href="/about">About Us</a>

Simply remove the role="link" attribute. The browser and assistive technologies already treat this as a link.

✅ Correct: using role="link" on a non-semantic element (when necessary)

<span role="link" tabindex="0" onclick="location.href='/about'" onkeydown="if(event.key==='Enter') location.href='/about'">
  About Us
</span>

This is the legitimate use case for role="link" — when you cannot use a native <a> element and need to make a non-interactive element behave like a link. Note the additional work required: tabindex="0" for keyboard focusability, a click handler, and a keydown handler for Enter key activation. Using a proper <a> element avoids all of this extra effort.

❌ Incorrect: multiple anchors with redundant roles

<nav>
  <a href="/" role="link">Home</a>
  <a href="/products" role="link">Products</a>
  <a href="/contact" role="link">Contact</a>
</nav>

✅ Correct: clean navigation without redundant roles

<nav>
  <a href="/">Home</a>
  <a href="/products">Products</a>
  <a href="/contact">Contact</a>
</nav>