HTML Guides for href

The <link> element defines a relationship between the current document and an external resource — most commonly stylesheets, icons, preloaded assets, or canonical URLs. According to the HTML specification, the element must include at least one of the href or imagesrcset attributes so the browser knows what resource is being linked. A <link> element without either attribute is essentially an empty declaration: it tells the browser about a relationship type (via rel) but provides no actual resource to fetch or reference.

This validation error commonly occurs in a few scenarios:

• Templating or CMS issues: A dynamic template generates a <link> tag but the URL variable is empty or undefined, resulting in a bare element with no href.
• Incomplete code: A developer adds a <link> with a rel attribute intending to fill in the href later but forgets to do so.
• Copy-paste mistakes: Attributes are accidentally removed during editing or refactoring.

Fixing this is important for several reasons. Browsers may ignore the element entirely or behave unpredictably when encountering a <link> with no resource URL. Unnecessary elements without purpose add bloat to the document and can confuse other developers reading the code. Additionally, tools that parse HTML — such as search engine crawlers and assistive technologies — rely on well-formed markup to correctly understand document relationships.

To resolve the issue, add an href attribute pointing to the target resource, use an imagesrcset attribute when providing responsive image sources, or include both when appropriate.

Examples

Invalid: missing both href and imagesrcset

This <link> declares a stylesheet relationship but doesn’t specify where the stylesheet is located:

<link rel="stylesheet">

This preload link has an as attribute but no resource to fetch:

<link rel="preload" as="image" type="image/png">

Fixed: using href

The most common fix is adding an href attribute with a valid URL:

<link rel="stylesheet" href="styles.css">

<link rel="icon" href="favicon.ico">

<link rel="canonical" href="https://example.com/page">

Fixed: using imagesrcset

For responsive image preloading, the imagesrcset attribute specifies multiple image sources at different resolutions. This is valid without href:

<link rel="preload" as="image" type="image/png" imagesrcset="icon-1x.png 1x, icon-2x.png 2x">

Fixed: using both href and imagesrcset

You can combine both attributes. The href serves as a fallback resource while imagesrcset provides responsive alternatives:

<link rel="preload" as="image" href="icon-1x.png" imagesrcset="icon-1x.png 1x, icon-2x.png 2x">

Handling dynamic templates

If your <link> elements are generated dynamically, make sure the element is only rendered when a valid URL is available. For example, in a template, wrap the output in a conditional check rather than outputting an empty <link>:

<!-- Bad: outputs a link even when the URL is empty -->

<link rel="stylesheet" href="">

<!-- Good: only include the element when there's a real URL -->

<link rel="stylesheet" href="styles.css">

Note that href="" resolves to the current page URL and is technically valid syntax (it won’t trigger this specific error), but it’s almost certainly not what you intend. Always ensure the href value points to the correct resource.

Why This Happens

In HTML, certain attributes are boolean and can appear without a value (e.g., disabled, required). The href attribute is not one of them — it expects a valid URL, path, or fragment identifier as its value. When a validator encounters href with no value or an empty value, it raises a warning because the attribute is being used in a way that doesn’t conform to the specification.

Writing <a href> produces a valueless attribute. Writing <a href=""> produces an attribute whose value is an empty string, which resolves to the current page’s URL per the rules of relative URL resolution. Both forms are problematic:

• href without a value: The HTML spec requires href to contain a valid URL. A valueless attribute is ambiguous and was actively dropped by IE7, meaning the element would lose its link behavior entirely in that browser.
• href="": While technically parsed as a relative URL pointing to the current document, this is almost never the developer’s intention. It causes the page to reload or scroll to the top when clicked, which is confusing for users and harmful for accessibility.

The Impact

• Accessibility: Screen readers rely on the href attribute to identify an <a> element as an interactive link. A missing or empty value creates confusion — the screen reader may announce it as a link but provide no destination, or may not treat it as a link at all.
• Browser compatibility: As the validator message notes, IE7 would strip the attribute entirely, meaning the element lost its link semantics and styling. While IE7 is no longer in common use, valueless attributes can still cause edge-case issues in parsers, crawlers, and automated tools.
• Standards compliance: Valid HTML ensures consistent rendering and behavior across browsers, assistive technologies, and search engine crawlers.

How to Fix It

The fix depends on your intent:

1. If the element should link somewhere, provide a real URL: href="https://example.com" or href="/about".
2. If the element is a placeholder link (e.g., during development or for JavaScript-driven actions), use href="#" and prevent the default navigation with JavaScript.
3. If the element doesn’t need to be a link at all, use a <button> for interactive actions or a <span> for non-interactive text. This is often the most semantically correct choice.

Examples

❌ Incorrect: href without a value

<a href>Click here</a>

This triggers the validation warning. The attribute has no value, which is invalid for href.

❌ Incorrect: href with an empty string

<a href="">Click here</a>

This resolves to the current page URL, likely causing an unintended page reload.

✅ Correct: Provide a real URL

<a href="https://example.com">Visit Example</a>

✅ Correct: Use a fragment as a placeholder

<a href="#" onclick="doSomething(); return false;">Perform action</a>

The return false prevents the page from scrolling to the top. A better modern approach uses event.preventDefault():

<a href="#" id="action-link">Perform action</a>
<script>
  document.getElementById("action-link").addEventListener("click", function (e) {
    e.preventDefault();
    doSomething();
  });
</script>

✅ Correct: Use a <button> for actions

If the element triggers a JavaScript action rather than navigating somewhere, a <button> is the most semantically appropriate choice:

<button type="button" onclick="doSomething();">Perform action</button>

Buttons are natively focusable, keyboard-accessible, and clearly communicate interactive intent to assistive technologies — no href needed.

✅ Correct: Use a <span> for non-interactive text

If the element is purely visual and shouldn’t be interactive at all:

<span class="label">Not a link</span>

This removes any expectation of interactivity for both the browser and the user.

Spaces are not permitted in the href value for phone links; the phone number must be a continuous string without spaces or slashes.

The href attribute of an anchor (<a>) element defines the link’s destination. For phone numbers, the proper URI scheme is tel:, not callto:. According to the HTML standard and the WHATWG Living Standard, the phone number should contain only digits and may use plus (+) or hyphen (-) characters for formatting, but it should not include spaces or slashes.

Incorrect HTML:

<a href="callto:07142/ 12 34 5">Call us</a>

Correct HTML:

<a href="tel:0714212345">Call us</a>

With country code and optional formatting:

<a href="tel:+49714212345">Call us</a>

For best compatibility and validation, always use the tel: scheme and ensure the phone number string contains only allowed characters.

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

This issue usually arises from one of these common scenarios:

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

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

Examples

Incorrect: duplicate # in the URL

The double ## makes the fragment identifier invalid:

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

Correct: single # delimiter

Remove the extra # so that pricing is the fragment:

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

Incorrect: extra # inside the fragment

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

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

Correct: percent-encode the literal #

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

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

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

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

Incorrect: programmatic concatenation error

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

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

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

Correct: ensure only one # is present

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

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

Fragment-only links

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

<!-- Incorrect -->

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

<!-- Correct -->

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

Spaces in the URL fragment are invalid; encode them or remove them (e.g., use %20 or hyphens/underscores).

The href attribute must contain a valid URL. When using a fragment identifier (the part after #), it must follow URL syntax rules: no unescaped spaces. Fragments usually reference an element’s id. An element’s id must be unique and is case-sensitive; while spaces aren’t allowed in id values, many authors accidentally mirror text with spaces in the fragment. Use hyphens or underscores in ids and match the fragment, or percent-encode reserved characters. Prefer readable, dash-separated ids for accessibility and shareable links.

For example, instead of href=”#My Section”, use href=”#my-section” and set id=”my-section” on the target. If you must preserve spaces in a generated URL, encode them as %20, but it’s better to avoid spaces entirely in ids.

HTML Examples

Invalid: reproduces the validator error

<!doctype html>
<html lang="en">
  <head>
    <title>Fragment with space</title>
  </head>
  <body>
    <a href="#My Section">Go to section</a>

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

Fixed: use a valid fragment and id

<!doctype html>
<html lang="en">
  <head>
    <title>Valid fragment</title>
  </head>
  <body>
    <a href="#my-section">Go to section</a>

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

Alternatively, encoding the space also passes validation, though less ideal as the id would be invalid because it contains spaces:

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

The href attribute of an <a> element contains an invalid character, that should be properly encoded as a URI percent-encoded character.

The pipe character | is not permitted in the query component of a URL in the href attribute of an a element.

According to the WHATWG and W3C HTML specifications, URLs in attributes such as href must be valid and properly encoded. The pipe character | is not a valid character in the query string of a URL unless it is percent-encoded as %7C. Failing to encode it will cause validation errors. This is especially important for interoperability and security across browsers and user agents.

Incorrect example (invalid href with pipe):

<a href="https://example.com/search?q=test|demo">Invalid link</a>

Correct example (pipe character encoded):

<a href="https://example.com/search?q=test%7Cdemo">Valid link</a>

Always encode special characters such as | in URLs used within HTML attributes to ensure your documents validate and behave consistently.

Space characters are not permitted in the value of the href attribute; they must be properly percent-encoded.

The href attribute specifies a URL, and URLs must follow specific syntax rules defined by RFC 3986. Spaces and some other characters are considered illegal in URLs. To include a space in the URL, use the percent escape sequence %20 in place of the space character.

Incorrect example with an illegal space in the query string:

<a href="search.html?q=my search">Search for 'my search'</a>

Correct example using percent-encoding for the space:

<a href="search.html?q=my%20search">Search for 'my search'</a>

Replace all spaces in URLs within href attributes with %20 to ensure W3C validation and proper browser behavior.

Square brackets ([, ]) are not allowed unescaped in the query part of an href URL value.

The href attribute in the <a> element must contain a valid URL. According to the URL standard, certain characters, including square brackets, are not permitted directly in the query component unless percent-encoded. Using unescaped square brackets in the URL can cause validation errors and unexpected behavior in browsers.

To include a square bracket in the query string, use percent encoding:

• [ encodes to %5B
• ] encodes to %5D

Incorrect usage:

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

Correct usage:

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

This ensures the URL is valid and compliant with HTML standards.

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

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

Why this matters

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

How to fix it

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

Examples

Incorrect: backslashes in a relative path

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

Correct: forward slashes in a relative path

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

Incorrect: backslashes in an absolute URL

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

Correct: forward slashes in an absolute URL

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

Incorrect: Windows file path pasted directly

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

Correct: converted to a proper relative URL

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

Incorrect: mixed slashes

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

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

Correct: all forward slashes

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

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

URLs follow strict syntax rules defined by RFC 3986. Within the path segment of a URL, only a specific set of characters is allowed: unreserved characters (letters, digits, -, ., _, ~), percent-encoded characters (like %20), and certain reserved sub-delimiters. When the W3C validator encounters a character outside this allowed set in a <link> element’s href attribute, it flags the error.

Common causes of this issue include:

• Template placeholders left in the URL, such as {{variable}} or ${path}, where curly braces and dollar signs haven’t been resolved or encoded.
• Spaces in file paths, such as href="styles/my file.css" instead of using %20 or renaming the file.
• Copy-paste errors that introduce invisible or special Unicode characters.
• Backslashes (\) used instead of forward slashes (/), which is a common mistake on Windows systems.
• Unencoded query-like characters placed in the path portion of the URL.

This matters because browsers may interpret malformed URLs inconsistently. A URL that works in one browser might fail in another. Additionally, invalid URLs can break resource loading, cause accessibility issues when assistive technologies try to process the document, and lead to unexpected behavior with proxies, CDNs, or other intermediaries that strictly parse URLs.

To fix the issue, inspect the href value reported in the error and either:

1. Remove the illegal character if it was included by mistake.
2. Percent-encode the character if it must be part of the URL (e.g., a space becomes %20, a pipe | becomes %7C).
3. Rename the referenced file or directory to avoid special characters altogether (the simplest and most reliable approach).

Examples

Incorrect: Space in the path

<link rel="stylesheet" href="styles/my styles.css">

The space character is not allowed in a URL path segment. The validator will flag this as an illegal character.

Fixed: Percent-encode the space

<link rel="stylesheet" href="styles/my%20styles.css">

Better fix: Rename the file to avoid spaces

<link rel="stylesheet" href="styles/my-styles.css">

Incorrect: Template placeholder left unresolved

<link rel="stylesheet" href="styles/{{theme}}/main.css">

Curly braces { and } are not valid in URL path segments. This commonly happens with server-side or client-side templating syntax that wasn’t processed before the HTML was served.

Fixed: Use a valid resolved path

<link rel="stylesheet" href="styles/dark/main.css">

Incorrect: Backslash used as path separator

<link rel="stylesheet" href="styles\main.css">

Backslashes are not valid URL characters. URLs always use forward slashes.

Fixed: Use forward slashes

<link rel="stylesheet" href="styles/main.css">

Incorrect: Pipe character in the URL

<link rel="stylesheet" href="styles/font|icon.css">

Fixed: Percent-encode the pipe character

<link rel="stylesheet" href="styles/font%7Cicon.css">

Full valid document example

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>My Webpage</title>
    <link rel="stylesheet" href="styles/main.css">
    <link rel="icon" href="images/favicon.ico">
  </head>
  <body>
    <h1>Welcome to my webpage!</h1>
    <p>Here is some content.</p>
  </body>
</html>

When in doubt, run your URL through a URL encoder or validator separately to confirm all characters are legal. As a general best practice, stick to lowercase letters, digits, hyphens, and forward slashes in your file and directory names—this avoids encoding issues entirely and makes your URLs clean and predictable.

The <link> element is used to define relationships between the current document and external resources — most commonly stylesheets, icons, and preloaded assets. The href attribute specifies the URL of that external resource, and it is the core purpose of the element. An empty href attribute makes the <link> element meaningless because there is no resource to fetch or reference.

Why This Is a Problem

Standards compliance: The HTML specification requires the href attribute on <link> to be a valid, non-empty URL. An empty string does not qualify as a valid URL, so the validator flags it as an error.

Unexpected browser behavior: When a browser encounters an empty href, it may resolve it relative to the current document’s URL. This means the browser could end up making an unnecessary HTTP request for the current page itself, interpreting the HTML response as a stylesheet or other resource. This wastes bandwidth, can slow down page loading, and may trigger unexpected rendering issues.

Accessibility and semantics: An empty href provides no useful information to browsers, screen readers, or other user agents about the relationship between the document and an external resource. It adds noise to the DOM without contributing anything functional.

How to Fix It

1. Provide a valid URL: If the <link> element is meant to reference a resource, set href to the correct URL of that resource.
2. Remove the element: If no resource is needed, remove the entire <link> element rather than leaving it with an empty href.
3. Check dynamic rendering: This issue often occurs when a templating engine or CMS outputs a <link> element with a variable that resolves to an empty string. Add a conditional check so the element is only rendered when a valid URL is available.

Examples

❌ Incorrect: Empty href attribute

<link rel="stylesheet" href="">

This triggers the validation error because href is empty.

❌ Incorrect: Empty href from a template

<!-- A template variable resolved to an empty string -->

<link rel="icon" type="image/png" href="">

✅ Correct: Valid href pointing to a resource

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

✅ Correct: Valid href for a favicon

<link rel="icon" type="image/png" href="/images/favicon.png">

✅ Correct: Remove the element if no resource is needed

<!-- Simply omit the <link> element entirely -->

✅ Correct: Conditional rendering in a template

If you’re using a templating language, wrap the <link> in a conditional so it only renders when a URL is available. For example, in a Jinja2-style template:

{% if stylesheet_url %}
  <link rel="stylesheet" href="{{ stylesheet_url }}">
{% endif %}

This ensures the <link> element is never output with an empty href.

When you set href="http://", the browser and the W3C validator attempt to parse this as an absolute URL. According to the URL Standard, a URL with the http or https scheme must include a non-empty host component. The string http:// has the scheme but nothing after the ://, which makes the host empty and the URL invalid.

This issue typically arises when a URL is dynamically generated but the variable or value for the domain is missing, or when a developer uses http:// as a temporary placeholder during development and forgets to replace it.

Why this matters

• Broken navigation: Clicking a link with href="http://" leads to unpredictable behavior. Some browsers may navigate to an error page, while others may interpret it differently.
• Accessibility: Screen readers announce links to users, including their destinations. An invalid URL creates a confusing experience for assistive technology users who expect the link to go somewhere meaningful.
• Standards compliance: The HTML specification requires that href values be valid URLs. An empty host violates the URL parsing rules, causing the W3C validator to flag it as an error.
• SEO: Search engine crawlers may treat invalid URLs as errors, potentially affecting how your site is indexed.

Examples

❌ Invalid: empty host in URL

<a href="http://">Visit our website</a>

This triggers the error because http:// has no host component.

❌ Invalid: same issue with HTTPS

<a href="https://">Secure link</a>

The https scheme also requires a valid host, so this produces the same error.

✅ Fixed: provide a complete URL

<a href="https://example.com">Visit our website</a>

✅ Fixed: use a fragment placeholder if the URL is unknown

If you need a placeholder link during development, use # instead of an incomplete URL:

<a href="#">Visit our website</a>

✅ Fixed: use a relative URL when linking within the same site

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

Handling dynamic URLs

If the href value comes from a template or CMS, make sure the variable outputs a complete URL. For example, if a template produces an empty string, you might end up with:

<!-- If {{ site_url }} is empty, this becomes href="http://" -->

<a href="http://{{ site_url }}">Home</a>

Ensure that the variable always resolves to a valid host, or add a fallback so the link is omitted or replaced with a safe default when the value is missing.

A space character in the email address within the mailto: link is invalid syntax.

The href attribute on an <a> tag must contain a valid email address after mailto: in order to conform to HTML standards. Email addresses cannot contain spaces. Including a space (as in user@example com) results in invalid markup.

Correct usage:
Remove any spaces from the email address and use a correctly formatted address such as user@example.com.

Invalid example

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

Valid example

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

A URI (Uniform Resource Identifier) follows a strict syntax defined by RFC 3986. The general structure is scheme:scheme-data, where no spaces or other illegal characters are allowed between the colon and the scheme-specific data. When the W3C validator reports “Illegal character in scheme data,” it means the parser found a character that isn’t permitted in that position of the URI.

The most common cause of this error is adding a space after the colon in tel: links (e.g., tel: +123456789). While browsers may be forgiving and still handle the link, the markup is technically invalid. This matters for several reasons:

• Accessibility: Screen readers and assistive technologies rely on well-formed URIs to correctly identify link types. A malformed tel: link might not be announced as a phone number.
• Standards compliance: Invalid URIs violate the HTML specification, which requires the href attribute to contain a valid URL.
• Cross-device behavior: Mobile devices use the URI scheme to determine which app should handle a link. A malformed tel: URI may fail to trigger the phone dialer on some devices or operating systems.
• Interoperability: While some browsers silently trim spaces, others may encode them as %20, potentially breaking the phone number or other scheme data.

To fix this issue, ensure there are no spaces or other illegal characters between the scheme’s colon and the data that follows it. For telephone links specifically, the number should follow the colon directly, using only digits, hyphens, dots, parentheses, and the + prefix as defined by RFC 3966.

Examples

Incorrect: space after the colon in a tel: link

<a href="tel: +1-234-567-8900">Call us</a>

The space between tel: and +1 is an illegal character in the URI scheme data.

Correct: no space after the colon

<a href="tel:+1-234-567-8900">Call us</a>

Incorrect: space after the colon in a mailto: link

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

Correct: mailto: with no space

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

Incorrect: other illegal characters in scheme data

<a href="tel:+1 234 567 8900">Call us</a>

Spaces within the phone number itself are also illegal characters in the URI. Use hyphens, dots, or no separators instead.

Correct: valid separators in a phone number

<a href="tel:+1-234-567-8900">Call us</a>
<a href="tel:+1.234.567.8900">Call us</a>
<a href="tel:+12345678900">Call us</a>

Visual formatting vs. the href value

If you want the displayed phone number to include spaces for readability, format the visible text separately from the href value:

<a href="tel:+12345678900">+1 234 567 8900</a>

The href contains a valid URI with no spaces, while the link text is formatted for easy reading. This gives you the best of both worlds — valid markup and a user-friendly display.

Backslashes (\) are not allowed in href values; use forward slashes (/) to separate path segments in URLs.

The href attribute in the a (anchor) element defines the hyperlink target and must contain a valid URL. According to the WHATWG HTML Standard, URL paths must use forward slashes (/) as delimiters, not backslashes (\). Backslashes are not recognized by web browsers as valid path separators and will cause validation errors or unexpected behavior. This issue often occurs when copying Windows file paths, which use backslashes, into HTML.

Incorrect HTML:

<a href="folder\page.html">Link</a>

Correct HTML:

<a href="folder/page.html">Link</a>

If you need to link to a file or resource, always replace any backslashes with forward slashes for proper HTML and browser compatibility.

A valid URL consists of several parts: a scheme (like https), followed by ://, then the host, and optionally a path, query string, and fragment. The :// separator — a colon followed by two forward slashes — is a required part of the URL syntax for schemes like http and https. When one of these slashes is missing, the browser may fail to navigate to the intended destination, interpret the value as a relative path, or behave unpredictably across different environments.

This error commonly occurs due to simple typos, copy-paste mistakes, or programmatic URL construction where string concatenation goes wrong. While some browsers may attempt to correct malformed URLs, you should never rely on this behavior. A malformed href can break navigation entirely, cause security warnings, produce unexpected redirects, or confuse assistive technologies like screen readers that announce link destinations to users.

Beyond the missing-slash case, this error can also appear when other parts of the URL contain characters that aren’t valid without proper encoding — for instance, spaces or special characters that should be percent-encoded. Always ensure your URLs conform to the URL Standard.

How to Fix

1. Check the scheme separator: Verify that the protocol is followed by :// (colon and two slashes). For example, https:// not https:/ or https:.
2. Validate the full URL: Paste the URL into a browser’s address bar to confirm it resolves correctly.
3. Encode special characters: If the URL contains spaces or special characters, use proper percent-encoding (e.g., spaces become %20).
4. Review dynamically generated URLs: If URLs are built through string concatenation or template logic, double-check that all parts are joined correctly.

Examples

Incorrect: Missing a slash after the scheme

<a href="https:/example.com">Visit Example</a>

The validator reports this because https:/example.com has only one slash after the colon instead of the required two.

Incorrect: Missing both slashes

<a href="https:example.com">Visit Example</a>

This is also invalid — the colon must be followed by // for https URLs.

Correct: Properly formatted URL

<a href="https://example.com">Visit Example</a>

Correct: URL with a path

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

Correct: URL with encoded spaces

<a href="https://example.com/search?q=hello%20world">Search</a>

Incorrect: Unencoded space in URL

<a href="https://example.com/my page">My Page</a>

Spaces are not valid in URLs. Use %20 or + (in query strings) instead:

<a href="https://example.com/my%20page">My Page</a>

Curly braces {} are not allowed in the href attribute value of an <a> element because they are not permitted in valid URLs.

According to the HTML standard and URL specification, certain characters—including { and }—must be percent-encoded in URLs to avoid validation errors and ensure proper browser handling. If you need to include a curly brace in a URL, use percent-encoding: { is %7B and } is %7D.

Incorrect HTML:

<a href="http://example.com/?i=470722{0}">Link</a>

Correct HTML with percent-encoding:

<a href="http://example.com/?i=470722%7B0%7D">Link</a>

Resulting link:

http://example.com/?i=470722%7B0%7D

Only use plain { or } if you are generating URLs client-side (for example, as template placeholders in JavaScript). To validate properly, always encode or remove illegal characters in attribute values.

The href attribute in the a tag uses an invalid character, as > is not allowed in URL fragments.

According to the HTML standard and URL syntax, fragment identifiers (the part after #) can only contain certain characters. The > character is not permitted and must be removed or percent-encoded. If the > is unintentional, simply omit it; if it must be included as part of the fragment, encode it as %3E.

Original HTML (invalid):

<a href="/page.php>">Read more</a>

Corrected HTML (if > should not be present):

<a href="/page.php">Read more</a>

Corrected HTML (if > is required in fragment, encode it):

<a href="/page.php%3E">Read more</a>

A URL can have only one fragment identifier — the portion that comes after the single # symbol. When the browser encounters a # in a URL, it treats everything after it as the fragment. If a second # appears, it becomes an illegal character within that fragment because the fragment portion of a URL does not allow unencoded # characters. This violates the URL specification (WHATWG) and the HTML standard’s requirements for valid URLs in the href attribute.

This matters for several reasons:

• Standards compliance: Browsers may handle malformed URLs inconsistently, leading to unpredictable navigation behavior across different environments.
• Accessibility: Screen readers and assistive technologies rely on well-formed URLs to correctly announce link destinations and allow users to navigate.
• SEO and crawling: Search engine crawlers may fail to follow or index pages with invalid URLs.

The # character is perfectly valid when used exactly once to introduce a fragment. For example, #pricing or /faqs#pricing are fine. The issue arises when a second # appears, such as /faqs#guarantee#pricing, or when # is used in a part of the URL where it isn’t expected.

If you genuinely need a literal # character as part of a path or query string (not as a fragment delimiter), you must percent-encode it as %23.

Examples

❌ Invalid: Multiple # characters in the URL

This triggers the validator error because the fragment (guarantee#pricing) contains an illegal #:

<a href="/faqs#guarantee#pricing">Guarantee and Pricing</a>

✅ Fixed: Use a single fragment identifier

Link to one section at a time with a single #:

<a href="/faqs#guarantee">Guarantee</a>
<a href="/faqs#pricing">Pricing</a>

✅ Fixed: Encode the # if it’s meant as a literal character

If the # is part of the actual path or data (not a fragment delimiter), encode it as %23:

<a href="/faqs%23guarantee#pricing">Pricing</a>

In this case, /faqs%23guarantee is the path (containing a literal #), and pricing is the fragment.

Using fragments correctly in a table of contents

Fragments work well for in-page navigation. Each target element needs a matching id:

<nav>
  <ul>
    <li><a href="#pricing">Pricing</a></li>
    <li><a href="#terms">Terms</a></li>
    <li><a href="#guarantee">Guarantee</a></li>
  </ul>
</nav>

<h2 id="pricing">Pricing</h2>
<p>All about pricing...</p>

<h2 id="terms">Terms</h2>
<p>You can find our terms at...</p>

<h2 id="guarantee">Guarantee</h2>
<p>We offer a guarantee...</p>

❌ Invalid: # in a query string or path without encoding

Sometimes this error appears when a URL accidentally includes an unencoded # in the wrong place:

<a href="/search?color=#ff0000">Red items</a>

✅ Fixed: Encode the # in the query value

<a href="/search?color=%23ff0000">Red items</a>

Here, %23ff0000 correctly represents the literal string #ff0000 as a query parameter value, rather than being misinterpreted as the start of a fragment.

Common causes

• Copy-pasting URLs from other sources that contain multiple # characters.
• Dynamically generated links where fragment values aren’t properly sanitized.
• Color codes in URLs like #ff0000 that need to be percent-encoded as %23ff0000.
• Concatenation errors in templates where a # is added both in the base URL and the appended fragment.

The fix is always the same: make sure your href contains at most one # used as the fragment delimiter, and percent-encode (%23) any # that is meant as a literal character.

The fragment portion of a URL (everything after the # symbol) follows the same encoding rules as the rest of the URL — literal space characters are not permitted. When a browser encounters a space in a URL fragment, it may try to correct it automatically, but this behavior is not guaranteed across all browsers and contexts. Relying on browser error-correction leads to fragile links that may break unpredictably.

This issue matters for several reasons. First, it produces invalid HTML that fails W3C validation. Second, fragment navigation (jumping to a specific section of a page) may not work correctly if the browser doesn’t auto-correct the space. Third, assistive technologies like screen readers rely on well-formed URLs to announce link destinations accurately. Finally, tools that parse or process HTML programmatically — such as crawlers, link checkers, and content management systems — may misinterpret or reject malformed URLs.

The most common scenario for this error is linking to an id attribute on the same page or another page where the id contains spaces. However, it’s worth noting that id values themselves cannot contain spaces in valid HTML (a space in an id would make it multiple invalid tokens). So if you’re writing both the link and the target, the best fix is often to correct the id itself by using hyphens or underscores instead of spaces.

How to Fix It

There are two main approaches:

1. Percent-encode the spaces — Replace each space with %20 in the href value.
2. Use space-free identifiers — Change the target id to use hyphens or camelCase, then update the fragment to match.

The second approach is strongly preferred because it fixes the root problem and produces cleaner, more readable markup.

Examples

❌ Invalid: Space in the fragment

<a href="https://example.com/page#some term">Go to section</a>

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

✅ Fixed: Percent-encode the space

If you cannot control the target id (e.g., linking to an external page), percent-encode the space:

<a href="https://example.com/page#some%20term">Go to section</a>

✅ Better fix: Use a hyphenated id and matching fragment

When you control both the link and the target, use a space-free id:

<h2 id="my-section">My Section</h2>
<p>Some content here.</p>

<a href="#my-section">Jump to My Section</a>

❌ Invalid: Space in fragment linking to another page

<a href="/docs/getting-started#quick start guide">Quick Start Guide</a>

✅ Fixed: Matching hyphenated id

<!-- On the target page (/docs/getting-started): -->

<h2 id="quick-start-guide">Quick Start Guide</h2>

<!-- On the linking page: -->

<a href="/docs/getting-started#quick-start-guide">Quick Start Guide</a>

A note on id naming conventions

Since fragment identifiers reference id attributes, adopting a consistent id naming convention avoids this issue entirely. Common patterns include:

<!-- Hyphens (most common, used by many static site generators) -->

<section id="getting-started">

<!-- camelCase -->

<section id="gettingStarted">

<!-- Underscores -->

<section id="getting_started">

All three are valid and will never trigger a space-related validation error in your fragment links.

URLs follow strict syntax rules defined by RFC 3986, which does not permit literal space characters anywhere in a URI. When the W3C validator encounters a space in the href attribute of an <a> element — particularly within the query string (the part after the ?) — it flags it as an illegal character.

While most modern browsers will silently fix malformed URLs by encoding spaces for you, relying on this behavior is problematic for several reasons:

• Standards compliance: The HTML specification requires that href values contain valid URLs. A space makes the URL syntactically invalid.
• Interoperability: Not all user agents, crawlers, or HTTP clients handle malformed URLs the same way. Some may truncate the URL at the first space or reject it entirely.
• Accessibility: Screen readers and assistive technologies may struggle to interpret or announce links with invalid URLs.
• Link sharing and copy-pasting: If a user copies the link from the source or if the URL is used in an API or redirect, the unencoded space can cause breakage.

To fix this issue, replace every literal space character in the URL with %20. Within query string values, you can also use + as a space encoding (this is the application/x-www-form-urlencoded format commonly used in form submissions). If you’re generating URLs dynamically, use your programming language’s URL encoding function (e.g., encodeURIComponent() in JavaScript, urlencode() in PHP, or urllib.parse.quote() in Python).

Examples

Incorrect — spaces in the query string

<a href="https://example.com/search?query=hello world&lang=en">Search</a>

The space between hello and world is an illegal character in the URL.

Correct — space encoded as %20

<a href="https://example.com/search?query=hello%20world&lang=en">Search</a>

Correct — space encoded as + in query string

<a href="https://example.com/search?query=hello+world&amp;lang=en">Search</a>

Using + to represent a space is valid within query strings and is commonly seen in URLs generated by HTML forms.

Incorrect — spaces in the path and query

<a href="https://example.com/my folder/page?name=John Doe">Profile</a>

Correct — all spaces properly encoded

<a href="https://example.com/my%20folder/page?name=John%20Doe">Profile</a>

Generating safe URLs in JavaScript

If you’re building URLs dynamically, use encodeURIComponent() for individual parameter values:

<script>
  const query = "hello world";
  const url = "https://example.com/search?query=" + encodeURIComponent(query);
  // Result: "https://example.com/search?query=hello%20world"
</script>

Note that encodeURIComponent() encodes spaces as %20, which is safe for use in any part of a URL. Avoid using encodeURI() for query values, as it does not encode certain characters like & and = that may conflict with query string syntax.

The URL standard defines a specific set of characters that are allowed to appear literally in a URL’s query string. Characters outside this allowed set — such as |, [, ], {, }, ^, and unencoded spaces — must be percent-encoded. Percent-encoding replaces the character with a % sign followed by its two-digit hexadecimal ASCII code.

This matters for several reasons. Browsers may handle illegal characters inconsistently — some might silently fix them while others may not, leading to broken links. Screen readers and assistive technologies rely on well-formed URLs to properly announce link destinations. Search engine crawlers may also fail to follow URLs with illegal characters, which can hurt discoverability. Using properly encoded URLs ensures your links work reliably across all user agents and conform to both the HTML and URL specifications.

Common Characters That Need Encoding

Here are frequently encountered characters that trigger this validation error:

Note that characters like ?, =, &, and # have special meaning in URLs and are allowed in their respective positions. For example, ? starts the query string, & separates parameters, and = separates keys from values. However, if these characters appear as part of a parameter’s value (rather than as delimiters), they must also be percent-encoded.

How to Fix It

1. Identify the illegal character mentioned in the validator’s error message.
2. Replace it with its percent-encoded equivalent.
3. If you’re generating URLs dynamically with a server-side language, use built-in encoding functions like encodeURIComponent() in JavaScript, urlencode() in PHP, or urllib.parse.quote() in Python.

Examples

❌ Incorrect: Unencoded pipe character in query string

<a href="https://example.com/search?filter=red|blue">Search</a>

✅ Correct: Pipe character percent-encoded as %7C

<a href="https://example.com/search?filter=red%7Cblue">Search</a>

❌ Incorrect: Unencoded square brackets in query string

<a href="https://example.com/api?items[0]=apple&items[1]=banana">View items</a>

✅ Correct: Square brackets percent-encoded

<a href="https://example.com/api?items%5B0%5D=apple&items%5B1%5D=banana">View items</a>

❌ Incorrect: Unencoded space in query string

<a href="https://example.com/search?q=hello world">Search</a>

✅ Correct: Space encoded as %20

<a href="https://example.com/search?q=hello%20world">Search</a>

If you’re building URLs in JavaScript, use encodeURIComponent() on individual parameter values rather than encoding the entire URL. This function handles all characters that need encoding while leaving the URL structure intact:

const query = "red|blue";
const url = `https://example.com/search?filter=${encodeURIComponent(query)}`;
// Result: "https://example.com/search?filter=red%7Cblue"

Avoid using encodeURI() for this purpose, as it does not encode characters like [, ], or | that are illegal in query strings. Always use encodeURIComponent() for encoding individual query parameter names and values.

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 space in the href URL wasn’t percent-encoded, making the link invalid.

The href attribute must contain a valid URL. Spaces and certain characters are not allowed in URLs and must be percent-encoded. In paths and query strings, replace spaces with %20 (or use + only in application/x-www-form-urlencoded query values, not paths).

Prefer generating properly encoded URLs server-side or via encodeURI/encodeURIComponent in JS. For fragment-only links, use href="#id". Avoid unencoded spaces anywhere after the scheme (e.g., https: or mailto:).

HTML Examples

Invalid (reproduces the validator error)

<a href="https://example.com/files/My File.pdf">Download</a>

Fixed (spaces percent-encoded)

<a href="https://example.com/files/My%20File.pdf">Download</a>