HTML Guides for src

The <script> element serves two distinct purposes in HTML: loading executable scripts and embedding non-executable data blocks. When the src attribute is present, the element is always being used to load an external script, so the type attribute must reflect a valid script type. Setting type to something like "text/html", "text/plain", or an invented value like "wrong" tells the browser this is not JavaScript, which means the external file referenced by src will be fetched but never executed — almost certainly not what the author intended.

The HTML specification restricts the allowed type values for <script src="..."> to three categories:

• An empty string (type=""): Treated the same as the default, which is JavaScript.
• A JavaScript MIME type: This includes text/javascript, application/javascript, and other legacy JavaScript MIME types. Since text/javascript is the default, specifying it is redundant.
• module: Indicates the script should be treated as a JavaScript module, enabling import/export syntax and deferred execution by default.

Any value outside these categories — such as text/html, application/json, or a made-up string — is invalid when src is present.

Why this matters

Broken functionality: A non-JavaScript type on a <script> with src prevents the browser from executing the loaded file. The script is effectively dead code that still costs a network request.

Standards compliance: The HTML living standard explicitly forbids this combination. Validators flag it because it almost always indicates a mistake — either the wrong type was applied, or the src attribute was added by accident.

Maintainability: Future developers reading the code may be confused about whether the script is supposed to execute or serve as an inert data block. Keeping markup valid makes intent clear.

How to fix it

1. Remove the type attribute entirely. This is the best approach for classic JavaScript. The default behavior is text/javascript, so no type is needed.
2. Use type="module" if the script uses ES module syntax (import/export).
3. If you intended a data block (e.g., embedding JSON or a template), remove the src attribute and place the content inline inside the <script> element instead. Data blocks with non-JavaScript types cannot use src.

Examples

Invalid: non-JavaScript types with src

These all trigger the validation error because the type value is not a JavaScript MIME type, an empty string, or "module":

<script type="text/html" src="template.html"></script>

<script type="application/json" src="data.json"></script>

<script type="text/plain" src="app.js"></script>

<script type="wrong" src="app.js"></script>

Valid: omitting the type attribute

The simplest and recommended fix for classic scripts — just drop type:

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

Valid: using a JavaScript MIME type

This is valid but redundant, since text/javascript is already the default. The validator may suggest omitting it:

<script type="text/javascript" src="app.js"></script>

Valid: using type="module"

Use this when the external script uses ES module syntax:

<script type="module" src="app.js"></script>

Valid: using an empty type attribute

An empty string is treated as the default. It’s valid but unnecessary, and the validator may suggest removing it:

<script type="" src="app.js"></script>

Valid: data blocks without src

If you need a non-JavaScript type for an inline data block, remove the src attribute and place the content directly inside the element:

<script type="application/json" id="config">
  {
    "apiUrl": "https://example.com/api",
    "debug": false
  }
</script>

Square brackets ([ and ]) are reserved characters under RFC 3986, the standard that defines URI syntax. They are only permitted in the host component of a URL (specifically for IPv6 addresses) and are illegal elsewhere, including the query string. While most browsers are lenient and will load an <iframe> even when the src contains raw brackets, the W3C HTML Validator correctly flags this as an invalid URL value.

This pattern surfaces frequently when working with frameworks or APIs that use bracket notation to represent arrays or nested objects in query parameters — for example, filters[category]=news or items[0]=apple. These URLs work in a browser’s address bar because browsers silently fix malformed URLs, but the raw HTML itself is technically non-conforming.

Why it matters

• Standards compliance: A valid HTML document requires all attribute values that expect URLs to contain properly encoded URIs. Raw brackets violate this requirement.
• Interoperability: While mainstream browsers handle this gracefully, other HTML consumers — such as screen readers, web scrapers, embedded webview components, or email clients — may not be as forgiving.
• Maintainability: Properly encoded URLs are unambiguous and reduce the risk of subtle parsing bugs, especially when URLs are constructed dynamically or passed through multiple layers of processing.

How to fix it

There are two main approaches:

1. Percent-encode the brackets. Replace every [ with %5B and every ] with %5D in the URL. The server will decode them back to brackets automatically, so functionality is preserved.

2. Use alternative parameter naming. If you control the server, switch to a naming convention that avoids brackets altogether, such as dot notation (filters.category) or underscores (filters_category). This keeps the URL valid without any encoding.

If you’re generating the URL dynamically in JavaScript, you can use encodeURIComponent() on individual parameter keys and values, or use the URL and URLSearchParams APIs, which handle encoding automatically.

Examples

Incorrect — raw brackets in the query string

<iframe src="https://example.com/embed?filters[category]=news&filters[tags]=web"></iframe>

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

Fixed — percent-encoded brackets

<iframe src="https://example.com/embed?filters%5Bcategory%5D=news&filters%5Btags%5D=web"></iframe>

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

Fixed — alternative parameter naming

<iframe src="https://example.com/embed?filters.category=news&filters.tags=web"></iframe>

If the server supports it, using dot notation eliminates the need for brackets entirely, keeping the URL clean and valid.

Generating encoded URLs in JavaScript

<iframe id="content-frame"></iframe>
<script>
  const url = new URL("https://example.com/embed");
  url.searchParams.set("filters[category]", "news");
  url.searchParams.set("filters[tags]", "web");
  document.getElementById("content-frame").src = url.href;
  // Result: https://example.com/embed?filters%5Bcategory%5D=news&filters%5Btags%5D=web
</script>

The URLSearchParams API automatically percent-encodes reserved characters, so you can write the parameter names naturally and let the browser produce a valid URL.

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

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

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

How to fix it

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

Examples

❌ Empty src attribute

<iframe src=""></iframe>

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

❌ src attribute with only whitespace

<iframe src="  "></iframe>

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

✅ Valid URL in src

<iframe src="https://example.com/map.html" title="Location map"></iframe>

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

✅ Using about:blank for a placeholder frame

<iframe src="about:blank" title="Dynamic content area"></iframe>

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

✅ Using srcdoc for inline content

<iframe srcdoc="<p>Hello, embedded world!</p>" title="Inline content"></iframe>

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

✅ Dynamically creating the iframe with JavaScript

<div id="video-container"></div>
<script>
  const iframe = document.createElement("iframe");
  iframe.src = "https://example.com/video.html";
  iframe.title = "Video player";
  document.getElementById("video-container").appendChild(iframe);
</script>

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

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

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

Why It Matters

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

How to Fix It

You have several options depending on your use case:

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

Examples

❌ Incorrect: Fragment in a data: URI

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

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

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

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

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

✅ Correct: External SVG file with a fragment

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

<img src="icons.svg#icon" alt="Icon">

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

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

<svg xmlns="http://www.w3.org/2000/svg" hidden>
  <symbol id="icon-home" viewBox="0 0 20 20">
    <path d="M10 2 L2 10 L4 10 L4 18 L16 18 L16 10 L18 10 Z"/>
  </symbol>
</svg>

<svg width="20" height="20" aria-hidden="true">
  <use href="#icon-home"></use>
</svg>

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

The URL specification (defined by WHATWG and RFC 3986) restricts which characters can appear unencoded in different parts of a URL. Square brackets are reserved characters that have a specific meaning in URLs — they are only permitted in the host portion (to wrap IPv6 addresses like [::1]). In the query string, they must be percent-encoded.

This issue commonly appears when frameworks (especially PHP, Ruby on Rails, or JavaScript libraries) generate URLs with array-style query parameters like ?filter[color]=red. While many browsers and servers are lenient and will interpret these URLs correctly, they are technically invalid according to the URL standard. The W3C validator enforces this rule strictly.

Beyond standards compliance, using unencoded square brackets can cause problems in practice. Some HTTP clients, proxies, or caching layers may reject or mangle URLs containing raw brackets. Percent-encoding these characters ensures your URLs are universally safe and interoperable across all systems.

How to fix it

You have two main approaches:

1. Percent-encode the brackets. Replace every [ with %5B and every ] with %5D in the URL. This preserves the parameter structure that your server or framework expects, while making the URL valid.

2. Restructure the query parameters. If your backend allows it, use flat parameter names with dot notation, underscores, or dashes instead of bracket syntax. For example, change size[width] to size_width or size.width.

If you’re generating URLs in JavaScript, the built-in encodeURI() function does not encode square brackets. Use encodeURIComponent() on individual parameter names or values, or manually replace [ and ] after constructing the URL.

Examples

❌ Invalid: unencoded square brackets in query string

<img src="/images/photo.jpg?size[width]=300&size[height]=200" alt="A sample photo">

The literal [ and ] characters in the query string trigger the validation error.

✅ Fixed: percent-encoded brackets

<img src="/images/photo.jpg?size%5Bwidth%5D=300&size%5Bheight%5D=200" alt="A sample photo">

Replacing [ with %5B and ] with %5D makes the URL valid. Most servers and frameworks will decode these automatically and interpret the parameters the same way.

✅ Fixed: flat parameter names without brackets

<img src="/images/photo.jpg?size_width=300&size_height=200" alt="A sample photo">

If you control the server-side logic, you can avoid brackets altogether by using a flat naming convention for your parameters.

❌ Invalid: brackets in more complex query strings

<img
  src="/api/image?filters[type]=jpeg&filters[quality]=80&crop[x]=10&crop[y]=20"
  alt="Processed image">

✅ Fixed: all brackets encoded

<img
  src="/api/image?filters%5Btype%5D=jpeg&filters%5Bquality%5D=80&crop%5Bx%5D=10&crop%5By%5D=20"
  alt="Processed image">

Encoding in JavaScript

If you build image URLs dynamically, handle the encoding in your code:

// Manual replacement approach
const url = "/images/photo.jpg?size[width]=300&size[height]=200";
const safeUrl = url.replace(/\[/g, "%5B").replace(/\]/g, "%5D");
img.src = safeUrl;

// Using URLSearchParams (automatically encodes brackets)
const params = new URLSearchParams();
params.set("size[width]", "300");
params.set("size[height]", "200");
img.src = `/images/photo.jpg?${params.toString()}`;

Both approaches produce a valid, properly encoded URL that will pass W3C validation.

The W3C HTML validator raises this error when the src attribute of an <img> element contains characters that are not permitted in a valid URI. The most common culprit is the < character, but other characters like >, {, }, |, \, ^, and backticks are also illegal in URIs according to RFC 3986.

This issue typically occurs in a few common scenarios:

• Template syntax left unresolved: Server-side or client-side template tags (e.g., <%= imageUrl %>, {{ image.src }}) appear literally in the HTML output instead of being processed into actual URLs.
• Copy-paste errors: HTML markup or angle brackets accidentally end up inside a src value.
• Malformed dynamic URLs: JavaScript or server-side code incorrectly constructs a URL that includes raw HTML or special characters.

This matters because browsers may fail to load the image or interpret the URL unpredictably. Invalid URIs can also cause issues with screen readers and assistive technologies that try to resolve the src to provide context about the image. Keeping your markup standards-compliant ensures consistent behavior across all browsers and environments.

How to fix it

1. Check for unprocessed template tags. If you see template syntax like <%, {{, or similar in the rendered HTML, ensure your templating engine is running correctly and outputting the resolved URL.
2. Use valid, well-formed URLs. The src value should be a properly formatted absolute or relative URL.
3. Percent-encode special characters. If a special character is genuinely part of the URL (which is rare for <), encode it: < becomes %3C, > becomes %3E, and so on.
4. Inspect your generated HTML. View the page source in your browser to confirm the actual output, rather than relying on what your code looks like before processing.

Examples

Incorrect — template syntax in src

The template tag was not processed, leaving a < character in the src attribute:

<img src="<%= user.avatar %>" alt="User avatar">

Incorrect — HTML accidentally inside src

Angle brackets from stray markup ended up in the URL:

<img src="images/<thumbnail>/photo.jpg" alt="Photo">

Correct — a valid relative URL

<img src="images/photo.jpg" alt="Photo">

Correct — a valid absolute URL

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

Correct — special characters percent-encoded

If the URL genuinely requires characters that are not allowed in a URI, percent-encode them:

<img src="https://example.com/search?q=a%3Cb" alt="Search result">

In this case, %3C represents the < character in the query string, making the URI valid.

The HTML specification requires the src attribute of an <img> element to be a valid, non-empty URL. When you set src="", the browser has no resource to fetch, but many browsers will still attempt to make a request — often resolving the empty string relative to the current page URL. This means the browser may re-request the current HTML document as if it were an image, wasting bandwidth and potentially causing unexpected server-side behavior.

Beyond the technical waste, an empty src is problematic for accessibility. Screen readers rely on the <img> element to convey meaningful content. An image with no source provides no value and can confuse assistive technology users. Search engine crawlers may also flag this as a broken resource, negatively affecting SEO.

This issue commonly arises in a few scenarios:

• Placeholder images — developers leave src empty intending to set it later via JavaScript.
• Template rendering — a server-side template or frontend framework outputs an <img> tag before the image URL is available.
• Lazy loading implementations — the real source is stored in a data-src attribute while src is left empty.

How to fix it

The simplest fix is to provide a valid image URL in the src attribute. If the image source isn’t available yet, consider these alternatives:

1. Don’t render the <img> element at all until a valid source is available.
2. Use a small placeholder image (such as a transparent 1×1 pixel GIF or a lightweight SVG) as a temporary src.
3. Use native lazy loading with loading="lazy" and a real src, letting the browser handle deferred loading instead of relying on an empty src.

Examples

❌ Bad: empty src attribute

<img src="" alt="Profile photo">

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

❌ Bad: src with only whitespace

<img src="  " alt="Profile photo">

Whitespace-only values are also considered invalid and will produce a similar error.

✅ Good: valid image path

<img src="photo.jpg" alt="Profile photo">

✅ Good: placeholder image for lazy loading

If you’re implementing lazy loading and need a lightweight placeholder, use a small inline data URI or a real placeholder file:

<img
  src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7"
  data-src="photo.jpg"
  alt="Profile photo">

✅ Good: native lazy loading with a real src

Modern browsers support the loading attribute, eliminating the need for an empty src workaround:

<img src="photo.jpg" alt="Profile photo" loading="lazy">

✅ Good: conditionally render the element

If the image URL might not be available, avoid rendering the <img> tag entirely. For example, in a template:

<!-- Only include the img element when a source exists -->

<img src="photo.jpg" alt="Profile photo">

In frameworks like React, Vue, or server-side templating engines, use conditional logic to skip the <img> element when the URL is empty rather than outputting a tag with an empty src.

The src attribute on a <script> element tells the browser where to fetch an external JavaScript file. According to the HTML specification, when the src attribute is present, its value must be a valid non-empty URL. An empty string does not qualify as a valid URL, so the validator flags it as an error.

This issue typically arises in a few common scenarios:

• Templating or CMS placeholders — A template engine or content management system outputs an empty src when no script URL is configured.
• Dynamic JavaScript — Client-side code is intended to set the src later, but the initial HTML ships with an empty value.
• Copy-paste mistakes — The attribute was added in anticipation of a script file that was never specified.

Beyond failing validation, an empty src causes real problems. Most browsers interpret an empty src as a relative URL that resolves to the current page’s URL. This means the browser will make an additional HTTP request to re-fetch the current HTML document and attempt to parse it as JavaScript, wasting bandwidth, slowing down page load, and potentially generating console errors. It can also cause unexpected side effects in server logs and analytics.

How to Fix It

Choose the approach that matches your intent:

1. Provide a valid URL — If you need an external script, set src to the correct file path or full URL.
2. Use an inline script — If your JavaScript is written directly in the HTML, remove the src attribute entirely. Note that when src is present, browsers ignore any content between the opening and closing <script> tags.
3. Remove the element — If the script isn’t needed, remove the <script> element altogether.

Also keep in mind:

• Ensure the file path is correct relative to the HTML file’s location.
• If using an absolute URL, verify it is accessible and returns JavaScript content.
• If a script should only be loaded conditionally, handle the condition in your server-side or build logic rather than outputting an empty src.

Examples

❌ Invalid: Empty src attribute

<script src=""></script>

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

❌ Invalid: Whitespace-only src attribute

<script src="  "></script>

A value containing only whitespace is also not a valid URL and will produce the same error.

✅ Fixed: Valid external script

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

The src attribute contains a valid relative URL pointing to an actual JavaScript file.

✅ Fixed: Valid external script with a full URL

<script src="https://example.com/js/library.min.js"></script>

✅ Fixed: Inline script without src

If you want to write JavaScript directly in your HTML, omit the src attribute:

<script>
  console.log("This is an inline script.");
</script>

✅ Fixed: Conditionally omitting the element

If the script URL comes from a template variable that might be empty, handle it at the template level so the <script> element is only rendered when a URL is available. For example, in a templating language:

<!-- Pseudocode — only output the tag when the URL exists -->

<!-- {% if script_url %} -->

<script src="analytics.js"></script>
<!-- {% endif %} -->

This prevents the empty src from ever reaching the browser.

The <source> element is used inside <video>, <audio>, and <picture> elements to specify one or more media resources for the browser to choose from. Its src attribute is defined as a valid non-empty URL, meaning it must resolve to an actual file path or web address. An empty string does not satisfy this requirement and violates the HTML specification.

Why this is a problem

Standards compliance: The WHATWG HTML living standard explicitly requires the src attribute on <source> to be a non-empty, valid URL. An empty value makes the document invalid HTML.

Unexpected browser behavior: When a browser encounters an empty src, it may attempt to resolve it relative to the current page URL. This can trigger an unnecessary HTTP request back to the current page, resulting in wasted bandwidth, unexpected server load, or confusing errors in your network logs.

Broken media playback: An empty src means the browser has no media file to load. If the <source> element is the only one provided, the media element will fail to play entirely — often without a clear indication to the user of what went wrong.

Accessibility concerns: Screen readers and assistive technologies rely on well-formed HTML. Invalid markup can lead to unpredictable behavior or missed content announcements for users who depend on these tools.

How to fix it

1. Provide a valid URL — Set the src attribute to the correct path or URL of your media file.
2. Remove the element — If the media source is not yet available or is being set dynamically via JavaScript, remove the <source> element from the HTML entirely and add it later through script when the URL is known.
3. Check for template or CMS issues — This error often appears when a CMS or templating engine outputs a <source> tag with an empty variable. Ensure your template conditionally renders the element only when a valid URL exists.

Examples

Incorrect: empty src on <source> in a video

<video controls>
  <source src="" type="video/mp4">
  Your browser does not support the video tag.
</video>

Correct: valid URL in src

<video controls>
  <source src="movie.mp4" type="video/mp4">
  Your browser does not support the video tag.
</video>

Incorrect: empty src on <source> in a picture element

<picture>
  <source src="" type="image/webp">
  <img src="photo.jpg" alt="A sunset over the ocean">
</picture>

Note that <source> inside <picture> uses srcset, not src. This example is doubly wrong — the attribute is both empty and incorrect. Here is the fix:

Correct: using srcset with a valid URL in a picture element

<picture>
  <source srcset="photo.webp" type="image/webp">
  <img src="photo.jpg" alt="A sunset over the ocean">
</picture>

Incorrect: multiple sources with one empty src

<audio controls>
  <source src="song.ogg" type="audio/ogg">
  <source src="" type="audio/mpeg">
</audio>

Correct: remove the source if no file is available

<audio controls>
  <source src="song.ogg" type="audio/ogg">
  <source src="song.mp3" type="audio/mpeg">
</audio>

Correct: conditionally add sources with JavaScript

If the URL is determined at runtime, avoid placing an empty <source> in your markup. Instead, add it dynamically:

<video id="player" controls>
  Your browser does not support the video tag.
</video>
<script>
  const videoUrl = getVideoUrl(); // your logic here
  if (videoUrl) {
    const source = document.createElement("source");
    source.src = videoUrl;
    source.type = "video/mp4";
    document.getElementById("player").appendChild(source);
  }
</script>

This approach keeps your HTML valid at all times and only inserts a <source> element when a real URL is available.

A URL follows a specific structure defined by RFC 3986. The general format is:

scheme://host/path?query#fragment

The # character serves as the delimiter that introduces the fragment portion of the URL. It may only appear once in this role. Once the parser encounters the first #, everything after it is treated as the fragment identifier. A second # within that fragment is an illegal character because the fragment production in the URL specification does not permit unescaped # characters.

This validation error commonly arises from:

• Duplicate # characters — e.g., accidentally including two hash marks like /#?param=value#section.
• Misplaced query strings — putting ?key=value after the # instead of before it. While this may work in some single-page application routers, it results in the query being part of the fragment, and adding another # after that creates an invalid URL.
• Copy-paste errors — assembling URLs from multiple parts and inadvertently introducing an extra #.

This matters for several reasons. Browsers may handle malformed URLs inconsistently — some may silently truncate or ignore part of the URL, while others may fail to load the resource entirely. The W3C validator flags this because it violates the HTML specification’s requirement that the src attribute contain a valid URL. Invalid URLs can also cause issues with assistive technologies, link sharing, and automated tools that parse your HTML.

How to fix it

1. Locate all # characters in the URL and determine which one is the intended fragment delimiter.
2. Remove any duplicate # characters that were added by mistake.
3. Move query parameters before the fragment — the ?query portion must come before the #fragment in a well-formed URL.
4. Percent-encode if needed — if a literal # must appear as data within the fragment or query value (not as a delimiter), encode it as %23.

Examples

Incorrect: multiple # characters

The second # inside the fragment is illegal:

<iframe src="https://example.com/#?secret=123#abc"></iframe>

Correct: query before fragment

Move the query string before the # so the URL has a proper structure:

<iframe src="https://example.com/?secret=123#abc"></iframe>

Correct: single fragment, no query

If you only need a fragment identifier, use a single #:

<iframe src="https://example.com/#abc"></iframe>

Correct: percent-encoding a literal # in a value

If the fragment itself must contain a # as data (not as a delimiter), percent-encode it:

<iframe src="https://example.com/?secret=123#color=%23ff0000"></iframe>

Here, %23ff0000 represents the literal string #ff0000 within the fragment value, which is valid because the # is encoded.

Incorrect: hash-based routing with duplicate #

Some single-page app embed URLs use hash-based routing, which can lead to accidental double hashes:

<iframe src="https://app.example.com/#/dashboard#settings"></iframe>

Correct: use a single fragment for the route

Restructure the URL to use a single # with a combined path:

<iframe src="https://app.example.com/#/dashboard/settings"></iframe>

Or, if the application supports it, use standard path-based routing instead:

<iframe src="https://app.example.com/dashboard/settings"></iframe>

The <iframe> element embeds another HTML document within the current page, and its src attribute specifies the URL of the content to load. According to the URL Living Standard and RFC 3986, URLs have a strict set of allowed characters. The space character (U+0020) is not one of them — it must always be percent-encoded when it appears in any part of a URL.

When the W3C HTML Validator encounters a literal space in the query portion of an <iframe>‘s src attribute, it raises this error because the browser has to guess what you meant. While most modern browsers will silently encode the space for you, 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 literal spaces is not valid.
• Interoperability: Different browsers, HTTP clients, and intermediary servers may handle unencoded spaces differently. Some might truncate the URL at the first space, while others might encode it. This inconsistency can lead to broken embeds.
• Copy-paste and sharing: If a user or script extracts the URL from the HTML source, the unencoded space may cause errors in contexts that don’t perform automatic encoding.

To fix this, replace every literal space in the URL with %20. This is the standard percent-encoding for the space character. In query strings, you can also use + as an alternative encoding for spaces (this is common in application/x-www-form-urlencoded format), though %20 is universally accepted in all parts of a URL.

If you’re generating <iframe> URLs dynamically with JavaScript, use the built-in encodeURIComponent() function to encode individual query parameter values, or use the URL and URLSearchParams APIs, which handle encoding automatically.

Examples

❌ Invalid: literal spaces in the query string

<iframe src="https://maps.google.com/maps?q=2700 6th Avenue"></iframe>

The space between 2700 and 6th and between 6th and Avenue triggers the validation error.

✅ Fixed: spaces encoded as %20

<iframe src="https://maps.google.com/maps?q=2700%206th%20Avenue"></iframe>

✅ Fixed: spaces encoded as + in the query string

<iframe src="https://maps.google.com/maps?q=2700+6th+Avenue"></iframe>

Both %20 and + are valid encodings for spaces in query strings.

❌ Invalid: spaces in multiple query parameters

<iframe
  src="https://example.com/embed?title=My Page&city=New York">
</iframe>

✅ Fixed: all spaces properly encoded

<iframe
  src="https://example.com/embed?title=My%20Page&city=New%20York">
</iframe>

Using JavaScript to build encoded URLs

If you construct iframe URLs dynamically, let the browser handle encoding for you:

const url = new URL("https://maps.google.com/maps");
url.searchParams.set("q", "2700 6th Avenue");

const iframe = document.createElement("iframe");
iframe.src = url.toString();
// Result: "https://maps.google.com/maps?q=2700+6th+Avenue"

The URLSearchParams API automatically encodes spaces (as +), along with any other special characters, ensuring the resulting URL is always valid.

When the W3C HTML Validator reports “Bad value X for attribute src on element iframe: Illegal character in query: [ is not allowed”, it means your URL contains unencoded square brackets in the query portion (everything after the ?). While most modern browsers will silently handle these characters and load the resource anyway, the URL does not conform to the URI syntax defined in RFC 3986, which the HTML specification requires.

According to RFC 3986, square brackets are reserved characters that have a specific purpose: they are only permitted in the host component of a URI to denote IPv6 addresses (e.g., http://[::1]/). Anywhere else in the URI — including the query string — they must be percent-encoded. The HTML living standard (WHATWG) requires that URLs in attributes like src, href, and action be valid URLs, which means they must follow these encoding rules.

Why this matters

• Standards compliance: Invalid URLs cause W3C validation failures, which can indicate deeper issues in your markup.
• Interoperability: While mainstream browsers are forgiving, some HTTP clients, proxies, CDNs, or web application firewalls may reject or mangle URLs with unencoded square brackets.
• Consistent behavior: Percent-encoding reserved characters guarantees that the URL is interpreted the same way everywhere — in browsers, server logs, link checkers, and automated tools.
• Copy-paste reliability: When users or tools copy a URL from your HTML source, an already-encoded URL is less likely to break during transmission through email clients, messaging apps, or other systems.

How to fix it

Replace every occurrence of [ with %5B and ] with %5D within the query string of the URL. If you’re generating URLs server-side or in JavaScript, use the language’s built-in URL encoding functions rather than doing manual find-and-replace:

• JavaScript: encodeURIComponent() or the URL / URLSearchParams APIs
• PHP: urlencode() or http_build_query()
• Python: urllib.parse.urlencode() or urllib.parse.quote()

These functions will automatically encode square brackets and any other reserved characters.

Examples

❌ Invalid — unencoded square brackets in query string

<iframe src="https://example.com/embed?filter[status]=active&filter[type]=video"></iframe>

The validator flags [ and ] as illegal characters in the query component.

✅ Valid — square brackets percent-encoded

<iframe src="https://example.com/embed?filter%5Bstatus%5D=active&filter%5Btype%5D=video"></iframe>

Replacing [ with %5B and ] with %5D resolves the error. The server receives the exact same parameter values — most server-side frameworks (PHP, Rails, etc.) automatically decode percent-encoded characters before processing them.

❌ Invalid — square brackets in a timestamp parameter

<iframe src="https://example.com/report?time=[2024-01-01]"></iframe>

✅ Valid — timestamp parameter properly encoded

<iframe src="https://example.com/report?time=%5B2024-01-01%5D"></iframe>

Generating encoded URLs in JavaScript

If you’re setting the src dynamically, let the browser handle encoding for you:

<iframe id="report-frame"></iframe>
<script>
  const url = new URL("https://example.com/embed");
  url.searchParams.set("filter[status]", "active");
  url.searchParams.set("filter[type]", "video");
  document.getElementById("report-frame").src = url.toString();
</script>

The URLSearchParams API automatically percent-encodes the brackets, producing a valid URL in the src attribute.

A note on other elements

This same rule applies to any HTML attribute that accepts a URL — including href on <a> elements, action on <form> elements, and src on <script> or <img> elements. Whenever you place a URL in HTML, ensure all reserved characters in the query string are properly percent-encoded.

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. Within a URL’s path segment, only a specific set of characters is allowed to appear literally. When a character falls outside this allowed set, it must be percent-encoded — represented as a % sign followed by two hexadecimal digits corresponding to the character’s ASCII code. The W3C validator checks that every URL in your HTML conforms to these rules, and it flags any src value that contains raw illegal characters.

Characters that commonly trigger this error include:

Other reserved characters like ?, #, @, !, $, &, ', (, ), *, +, ,, ;, and = also need encoding when used as literal data in a path segment rather than as URL delimiters. The % character itself must be encoded as %25 if it appears literally.

Why This Is a Problem

• Browser inconsistency: While many modern browsers silently fix malformed URLs, not all do. Some browsers, older user agents, or HTTP clients may fail to load the resource or interpret the URL differently, leading to broken images.
• Standards compliance: Invalid URLs violate the HTML specification, which requires that attribute values containing URLs conform to valid URL syntax.
• Interoperability: Servers, CDNs, proxies, and caching layers may handle illegal characters unpredictably, causing intermittent failures that are difficult to debug.
• Accessibility: If a URL is malformed and the image fails to load, users relying on assistive technologies may not receive the intended content, even when appropriate alt text is provided.

How to Fix It

You have two main approaches:

1. Percent-encode the illegal characters in the src value. Replace each offending character with its %XX equivalent.
2. Rename the file to use only URL-safe characters. Stick to lowercase letters, digits, hyphens (-), underscores (_), and dots (.). This is the cleanest long-term solution.

If you’re generating URLs programmatically, use your language’s built-in URL encoding functions (e.g., encodeURIComponent() in JavaScript, urlencode() in PHP, or urllib.parse.quote() in Python).

Examples

Illegal characters in the filename

The square brackets in the src value are not allowed in a URL path segment:

<!-- ❌ Invalid: raw [ and ] in URL path -->

<img src="image[00].svg" alt="Company logo">

Fix by percent-encoding:

<!-- ✅ Valid: [ and ] are percent-encoded -->

<img src="image%5B00%5D.svg" alt="Company logo">

Fix by renaming the file:

<!-- ✅ Valid: filename uses only safe characters -->

<img src="image-00.svg" alt="Company logo">

Spaces in the filename

Spaces are one of the most common causes of this error:

<!-- ❌ Invalid: space in URL path -->

<img src="my photo.jpg" alt="Vacation photo">

<!-- ✅ Valid: space encoded as %20 -->

<img src="my%20photo.jpg" alt="Vacation photo">

<!-- ✅ Valid: filename uses a hyphen instead of a space -->

<img src="my-photo.jpg" alt="Vacation photo">

Curly braces in a template-like path

Sometimes filenames or paths contain curly braces from templating artifacts or naming conventions:

<!-- ❌ Invalid: raw { and } in URL path -->

<img src="icons/{home}.png" alt="Home icon">

<!-- ✅ Valid: curly braces percent-encoded -->

<img src="icons/%7Bhome%7D.png" alt="Home icon">

Best practice for file naming

The simplest way to avoid this error entirely is to adopt a consistent file naming convention that only uses URL-safe characters:

<!-- ✅ Valid: clean, URL-safe filenames -->

<img src="images/hero-banner-2024.webp" alt="Welcome banner">
<img src="photos/team_photo_01.jpg" alt="Our team">

URLs follow strict syntax rules defined by RFC 3986, which does not allow literal space characters in any part of a URL — whether in the path, query string, or fragment. While many browsers will silently handle spaces by encoding them before making a request, the raw HTML is still invalid. The W3C HTML validator flags this because the src attribute expects a valid URL, and a URL containing a raw space does not conform to the standard.

This issue commonly appears in two scenarios: spaces in file paths (e.g., my image.jpg) and spaces in query string values (e.g., ?search=my term). Both must be percent-encoded. The percent-encoded form of a space is %20. In query strings specifically, you may also see + used to represent spaces (as defined by application/x-www-form-urlencoded), which is also valid in that context.

Beyond standards compliance, raw spaces in URLs can cause real problems. Some older browsers or HTTP clients may truncate the URL at the first space, leading to broken images or failed resource loads. Spaces can also cause issues with link sharing, copy-pasting, and server-side URL parsing. Proper encoding ensures your URLs work reliably across all environments.

How to fix it

1. Replace spaces with %20 in all parts of the URL. This is the universally safe approach.
2. Rename files to avoid spaces altogether. Use hyphens (-) or underscores (_) instead of spaces in file and directory names.
3. Use + in query strings if you prefer, though %20 works everywhere in a URL.

If you’re generating URLs programmatically, use built-in encoding functions like JavaScript’s encodeURI() or encodeURIComponent() to handle this automatically.

Examples

Spaces in the file path

This triggers the validation error because the file name contains a space:

<!-- ❌ Invalid: space in path segment -->

<img src="/images/my photo.jpg" alt="A vacation photo">

Fix it by encoding the space:

<!-- ✅ Valid: space encoded as %20 -->

<img src="/images/my%20photo.jpg" alt="A vacation photo">

Or better yet, rename the file to avoid spaces:

<!-- ✅ Valid: no spaces in file name -->

<img src="/images/my-photo.jpg" alt="A vacation photo">

Spaces in the query string

This triggers the error because the query parameter value contains a space:

<!-- ❌ Invalid: space in query string -->

<img src="https://example.com/image?title=sunset beach" alt="Sunset at the beach">

Fix by percent-encoding the space:

<!-- ✅ Valid: space encoded as %20 -->

<img src="https://example.com/image?title=sunset%20beach" alt="Sunset at the beach">

Using + is also acceptable in query strings:

<!-- ✅ Valid: space encoded as + in query string -->

<img src="https://example.com/image?title=sunset+beach" alt="Sunset at the beach">

Multiple spaces in a URL

When a URL has multiple spaces, each one must be encoded:

<!-- ❌ Invalid: multiple spaces -->

<img src="/uploads/user photos/trip to paris.jpg" alt="Trip to Paris">

<!-- ✅ Valid: all spaces encoded -->

<img src="/uploads/user%20photos/trip%20to%20paris.jpg" alt="Trip to Paris">

URLs follow a strict syntax defined by the URL Living Standard and RFC 3986. Only a specific set of characters are allowed to appear literally in a URL’s query string. Characters outside this set — such as pipes, square brackets, curly braces, and certain other symbols — must be percent-encoded. Percent-encoding replaces the character with a % sign followed by its two-digit hexadecimal ASCII code.

When the W3C HTML Validator encounters an <img> tag whose src attribute contains an illegal character in the query portion of the URL, it raises this error. The query string is the part of the URL that comes after the ? character.

Why this matters

• Browser inconsistency: While many modern browsers will silently fix malformed URLs, not all browsers or HTTP clients handle illegal characters the same way. Some may misinterpret the URL or fail to load the resource entirely.
• Standards compliance: Valid URLs are a foundational requirement for interoperable web content. Using illegal characters violates both the HTML and URL specifications.
• Interoperability: Automated tools, web crawlers, proxies, and content delivery networks may reject or mangle URLs containing unencoded special characters, leading to broken images.
• Accessibility: Screen readers and assistive technologies rely on valid markup. Malformed URLs can cause unexpected behavior in these tools.

Common illegal characters and their encodings

Here are characters frequently flagged by the validator:

How to fix it

Identify the illegal characters in the src URL and replace each one with its corresponding percent-encoded value. If you’re generating URLs dynamically with a programming language, use the language’s built-in URL-encoding function (e.g., encodeURI() or encodeURIComponent() in JavaScript, urlencode() in PHP, urllib.parse.quote() in Python).

Examples

❌ Incorrect: unencoded pipe character in query string

<img src="https://example.com/image?filter=red|blue" alt="Filtered image">

The | character is not allowed literally in the query string.

✅ Correct: pipe character percent-encoded

<img src="https://example.com/image?filter=red%7Cblue" alt="Filtered image">

❌ Incorrect: unencoded square brackets in query string

<img src="https://example.com/image?size[width]=300&size[height]=200" alt="Resized image">

The [ and ] characters must be encoded.

✅ Correct: square brackets percent-encoded

<img src="https://example.com/image?size%5Bwidth%5D=300&size%5Bheight%5D=200" alt="Resized image">

❌ Incorrect: space in query string

<img src="https://example.com/image?caption=hello world" alt="Captioned image">

✅ Correct: space percent-encoded

<img src="https://example.com/image?caption=hello%20world" alt="Captioned image">

Encoding URLs dynamically

If your URLs are built in JavaScript, use encodeURIComponent() for individual query parameter values:

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

This ensures that any special characters in user-provided or dynamic values are properly encoded before being placed into the HTML.

URLs follow strict syntax rules defined by RFC 3986, which does not allow literal space characters. When the W3C validator encounters a space in the src attribute of an <img> element, it reports it as an illegal character in the scheme data. While most modern browsers will attempt to handle spaces in URLs by automatically encoding them, relying on this behavior is not standards-compliant and can lead to broken images in certain contexts, such as when URLs are processed by other tools, APIs, or older browsers.

This issue commonly arises when file names contain spaces (e.g., my photo.jpg) and the path is copied directly into the HTML. It can also happen when a URL is incorrectly constructed by concatenating strings with unencoded values.

Beyond validation, unencoded spaces can cause real problems. A URL with a space may break when shared, copied, or passed through redirects. Email clients and messaging apps may truncate the URL at the space. Search engine crawlers might fail to index the resource correctly.

How to fix it

There are several ways to resolve this issue:

1. Percent-encode spaces as %20 — Replace every literal space in the URL with %20.
2. Rename the file — Remove spaces from file names entirely, using hyphens (-), underscores (_), or camelCase instead.
3. Use proper URL encoding functions — If generating URLs dynamically (e.g., in JavaScript or a server-side language), use built-in encoding functions like encodeURI() or encodeURIComponent().

Renaming files to avoid spaces is generally the best long-term practice, as it prevents encoding issues across your entire workflow.

Examples

❌ Invalid: spaces in the src attribute

<img src="images/my photo.jpg" alt="A vacation photo">

<img src="/assets/blog posts/header image.png" alt="Blog header">

Both of these will trigger the validation error because the src value contains literal space characters.

✅ Fixed: spaces encoded as %20

<img src="images/my%20photo.jpg" alt="A vacation photo">

<img src="/assets/blog%20posts/header%20image.png" alt="Blog header">

✅ Fixed: file renamed to remove spaces

<img src="images/my-photo.jpg" alt="A vacation photo">

<img src="/assets/blog-posts/header-image.png" alt="Blog header">

A note on + vs %20

You may see spaces encoded as + in some contexts (e.g., query strings in form submissions using application/x-www-form-urlencoded). However, + is not a valid substitute for a space in a URL path. Always use %20 for spaces in the src attribute.

<!-- ❌ Incorrect: + does not represent a space in a URL path -->

<img src="images/my+photo.jpg" alt="A vacation photo">

<!-- ✅ Correct -->

<img src="images/my%20photo.jpg" alt="A vacation photo">

The HTML specification requires that URL attributes like src contain valid URLs. While browsers are generally forgiving and may strip or ignore whitespace characters in URLs, including tabs (\t), newlines (\n), or carriage returns (\r) inside a src value is technically invalid. These characters are not legal within a URL according to both the HTML and URL standards.

Beyond standards compliance, there are practical reasons to fix this:

• Unpredictable behavior: Different browsers may handle embedded whitespace differently. Some might silently strip it, while others could encode it as %0A or %0D, leading to broken image requests.
• Debugging difficulty: Invisible characters make URLs fail silently. The path looks correct in your editor, but the actual HTTP request goes to a different (malformed) URL.
• Accessibility and tooling: Screen readers, crawlers, and other tools that parse your HTML may not handle malformed URLs gracefully, potentially causing images to be skipped or reported as broken.

Common Causes

This issue typically appears in a few scenarios:

1. Multi-line attributes in templates: When a URL is built dynamically in a template engine (e.g., PHP, Jinja, Handlebars), line breaks in the template code can leak into the rendered attribute value.
2. Copy-paste errors: Copying a URL from a document, email, or another source may include hidden line breaks or tab characters.
3. Code formatting: Some developers or auto-formatters may break long attribute values across multiple lines, inadvertently injecting newlines into the value.
4. String concatenation: Building URLs through string concatenation in server-side code can introduce whitespace if variables contain trailing newlines.

Examples

Incorrect: Newline inside src value

The newline before the closing quote makes this an invalid URL:

<img src="images/photo.jpg
" alt="A scenic photo">

Incorrect: Tab character in src value

A tab character embedded in the middle of the URL path:

<img src="images/   photo.jpg" alt="A scenic photo">

Incorrect: Multi-line URL from template output

This can happen when a template engine outputs a URL with leading or trailing whitespace:

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

Correct: Clean, single-line src value

The URL is a single continuous string with no tabs, newlines, or carriage returns:

<img src="images/photo.jpg" alt="A scenic photo">

Correct: Long URL kept on one line

Even if the URL is long, it must remain on a single line without breaks:

<img src="https://cdn.example.com/assets/images/2024/photos/scenic-landscape-full-resolution.jpg" alt="A scenic photo">

How to Fix It

1. Inspect the attribute value: Open the raw HTML source (not the rendered page) and look at the src value character by character. Use your editor’s “show whitespace” or “show invisible characters” feature to reveal hidden tabs and line breaks.
2. Remove all whitespace inside the URL: Ensure the entire URL is on a single line with no tabs, newlines, or carriage returns anywhere between the opening and closing quotes.
3. Check your templates: If the URL is generated dynamically, trim the output. Most languages offer a trim() or strip() function that removes leading and trailing whitespace including newlines.
4. Lint your HTML: Use the W3C validator or an HTML linter in your build pipeline to catch these issues automatically 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 browser’s HTML parser encounters a src attribute, it expects the value between the opening and closing quotes to be a valid URL. URLs have strict rules about which characters are permitted — a literal double quote (") is not one of them. If a " character appears inside the URL, the validator flags it as an illegal character in the query string (or other parts of the URL).

This error often doesn’t stem from an intentionally embedded quote in the URL itself. Instead, it’s usually a symptom of malformed HTML around the attribute. Common causes include:

• Stray quotes after the attribute value, such as writing src="https://example.com/script.js"async"" instead of properly separating attributes.
• Accidentally doubled closing quotes, like src="https://example.com/script.js"".
• Boolean attributes given empty-string values incorrectly, such as async"" instead of just async, which causes the parser to interpret the extra quotes as part of the preceding src value.
• Copy-paste errors that introduce smart quotes (" ") or extra quotation marks into the URL.

This matters for several reasons. Malformed src attributes can cause the script to fail to load entirely, breaking functionality on your page. It also violates the HTML specification, which can lead to unpredictable behavior across different browsers as each parser tries to recover from the error differently.

To fix the issue, carefully inspect the <script> tag and ensure that:

1. The src attribute value contains only a valid URL with no unescaped " characters.
2. The opening and closing quotes around the attribute value are properly balanced.
3. Attributes are separated by whitespace — not jammed together.
4. Boolean attributes like async and defer are written as bare keywords without values.

If you genuinely need a double quote character in a query string (which is rare), encode it as %22.

Examples

Incorrect — stray quotes between attributes

In this example, the async attribute is malformed as async"", which causes the parser to interpret the extra quotes as part of the src URL:

<script src="https://example.com/js/app.js?ver=3.1" async""></script>

Incorrect — doubled closing quote

Here, an extra " at the end of the src value creates an illegal character in the URL:

<script src="https://example.com/js/app.js?ver=3.1""></script>

Incorrect — smart quotes from copy-paste

Curly/smart quotes copied from a word processor are not valid HTML attribute delimiters and get treated as part of the URL:

<script src="https://example.com/js/app.js?ver=3.1"></script>

Correct — clean attributes with proper quoting

<script src="https://example.com/js/app.js?ver=3.1" async></script>

Correct — boolean attribute written as a bare keyword

Boolean attributes like async and defer don’t need a value. Simply include the attribute name:

<script src="https://example.com/js/app.js?ver=3.1" defer></script>

While async="async" is technically valid per the spec, the cleanest and most common form is the bare attribute. Avoid empty-string patterns like async="" placed without proper spacing, as they can lead to the exact quoting errors described here.

Correct — full valid document

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Valid Script Example</title>
    <script src="https://example.com/js/app.js?ver=3.1" async></script>
  </head>
  <body>
    <p>Page content here.</p>
  </body>
</html>

If you’re generating <script> tags dynamically (through a CMS, template engine, or build tool), check the template source rather than just the rendered output. The stray quotes are often introduced by incorrect string concatenation or escaping logic in the server-side code.

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.

Every <img> element must include at least a src or a srcset attribute to be valid HTML.

The <img> element exists to embed an image into the document, and it needs to know where that image is. The src attribute provides a single URL for the image, while srcset lets you offer multiple image sources for different screen sizes or resolutions.

You might run into this error when using JavaScript to set the image source dynamically, or when using lazy-loading libraries that store the URL in a data- attribute like data-src. While those techniques work at runtime, they produce invalid HTML because the validator still expects src or srcset to be present in the markup.

If you genuinely don’t have a source yet, you can use a placeholder or a transparent pixel as the src value.

Invalid Example

<img alt="A cute cat" loading="lazy" data-src="cat.jpg">

Valid Examples

Using src:

<img src="cat.jpg" alt="A cute cat">

Using srcset:

<img srcset="cat-400.jpg 400w, cat-800.jpg 800w"
  sizes="(max-width: 600px) 400px, 800px"
  alt="A cute cat">

Using both src and a lazy-loading data-src (keeps the markup valid while still supporting lazy loading):

<img src="placeholder.jpg" data-src="cat.jpg" alt="A cute cat">

The src attribute is one of two required attributes on every <img> element (the other being alt). The HTML specification mandates src because an image element without a source has no meaningful content to render. Omitting it produces invalid markup and leads to unpredictable browser behavior — some browsers may display a broken image icon, while others may render nothing at all.

This issue commonly occurs in a few scenarios:

• Templating placeholders — A developer adds an <img> tag intending to populate the src dynamically but forgets to set a default value.
• Lazy loading implementations — Some lazy-loading scripts store the real URL in a data-src attribute and omit src entirely, which results in invalid HTML.
• Incomplete markup — The attribute is simply forgotten during development.

Beyond validation, a missing src attribute causes accessibility problems. Screen readers rely on well-formed <img> elements to convey image information to users. A malformed image element can confuse assistive technologies and degrade the user experience.

How to fix it

1. Add a src attribute with a valid URL pointing to your image.
2. Always include an alt attribute as well — it’s also required and provides a text alternative for the image.
3. If you’re using lazy loading and want to defer the actual image source, set src to a lightweight placeholder (such as a tiny transparent image or a low-quality preview) and use the native loading="lazy" attribute instead of removing src.

Examples

❌ Missing src attribute

<img alt="A sunset over the ocean">

This triggers the validation error because src is absent.

❌ Source stored only in a data- attribute

<img data-src="/images/photo.jpg" alt="A sunset over the ocean">

While data-src is a valid custom data attribute, it does not satisfy the requirement for src. The validator will still report the error.

✅ Correct usage with src and alt

<img src="/images/photo.jpg" alt="A sunset over the ocean">

✅ Lazy loading with a placeholder src

<img
  src="/images/photo-placeholder.jpg"
  data-src="/images/photo-full.jpg"
  alt="A sunset over the ocean"
  loading="lazy">

Here, src points to a small placeholder image so the markup stays valid, while data-src holds the full-resolution URL for your lazy-loading script to swap in.

✅ Native lazy loading (no JavaScript needed)

<img src="/images/photo.jpg" alt="A sunset over the ocean" loading="lazy">

Modern browsers support the loading="lazy" attribute natively, so you can keep a valid src and still defer off-screen images without any custom scripting.

The async attribute tells the browser to download and execute a script without blocking HTML parsing. For external scripts (those with a src attribute), this means the browser can continue parsing the page while fetching the file, then execute the script as soon as it’s available. For inline module scripts (type="module"), async changes how the module’s dependency graph is handled — the module and its imports execute as soon as they’re all ready, rather than waiting for HTML parsing to complete.

For a classic inline script (no src, no type="module"), there is nothing to download asynchronously. The browser encounters the code directly in the HTML and executes it immediately. Applying async in this context is meaningless and contradicts the HTML specification, which is why the W3C validator flags it as an error.

Beyond standards compliance, using async incorrectly can signal a misunderstanding of script loading behavior, which may lead to bugs. For example, a developer might mistakenly believe that async on an inline script will defer its execution, when in reality it has no effect and the script still runs synchronously during parsing.

How to Fix

You have several options depending on your intent:

1. If the script should be external, move the code to a separate file and reference it with the src attribute alongside async.
2. If the script should be an inline module, add type="module" to the <script> tag. Note that module scripts are deferred by default, and async makes them execute as soon as their dependencies are resolved rather than waiting for parsing to finish.
3. If the script is a plain inline script, simply remove the async attribute — it has no practical effect anyway.

Examples

❌ Invalid: async on a classic inline script

<script async>
  console.log("Hello, world!");
</script>

This triggers the validator error because there is no src attribute and the type is not "module".

✅ Fixed: Remove async from the inline script

<script>
  console.log("Hello, world!");
</script>

✅ Fixed: Use async with an external script

<script async src="app.js"></script>

The async attribute is valid here because the browser needs to fetch app.js from the server, and async controls when that downloaded script executes relative to parsing.

✅ Fixed: Use async with an inline module

<script async type="module">
  import { greet } from "./utils.js";
  greet();
</script>

This is valid because module scripts have a dependency resolution phase that can happen asynchronously. The async attribute tells the browser to execute the module as soon as all its imports are resolved, without waiting for the document to finish parsing.

❌ Invalid: async with type="text/javascript" (not a module)

<script async type="text/javascript">
  console.log("This is still invalid.");
</script>

Even though type is specified, only type="module" satisfies the requirement. The value "text/javascript" is the default classic script type and does not make async valid on an inline script.

The charset attribute on the <script> element tells the browser what character encoding to use when interpreting the referenced external script file. When a script is written directly inside the HTML document (an inline script), the script’s character encoding is inherently the same as the document’s encoding — there is no separate file to decode. Because of this, the HTML specification requires that charset only appear on <script> elements that also have a src attribute pointing to an external file.

Including charset without src violates the HTML specification and signals a misunderstanding of how character encoding works for inline scripts. Validators flag this because browsers ignore the charset attribute on inline scripts, which means it has no effect and could mislead developers into thinking they’ve set the encoding when they haven’t.

It’s also worth noting that the charset attribute on <script> is deprecated in the HTML living standard, even for external scripts. The modern best practice is to serve external script files with the correct Content-Type HTTP header (e.g., Content-Type: application/javascript; charset=utf-8) or to simply ensure all your files use UTF-8 encoding, which is the default. If you’re working with an older codebase that still uses charset, consider removing it entirely and relying on UTF-8 throughout.

Examples

Incorrect: charset on an inline script

This triggers the validation error because charset is specified without a corresponding src attribute.

<script charset="utf-8">
  console.log("Hello, world!");
</script>

Correct: Remove charset from inline scripts

Since inline scripts use the document’s encoding, simply remove the charset attribute.

<script>
  console.log("Hello, world!");
</script>

Correct: Use charset with an external script (deprecated but valid)

If you need to specify the encoding of an external script, both charset and src must be present. Note that this usage, while valid, is deprecated.

<script src="app.js" charset="utf-8"></script>

Recommended: External script without charset

The preferred modern approach is to omit charset entirely and ensure the server delivers the file with the correct encoding header, or simply use UTF-8 for everything.

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