HTML Guide
The defer and async boolean attributes of the <script> element control how an external script should be executed once it has been downloaded. These attributes only make sense when referring to external scripts, so a src attribute must also be present to specify the location of the script.
Example:
<script defer src="app.js"></script>
If your script is not external, and is inlined within the HTML document, then you should remove the defer attribute, like in this example:
<script>
console.log("hello");
</script>Learn more:
Last reviewed: October 27, 2022
Related W3C validator issues
The combination of type="module" and defer is not allowed. The type="module" attribute itself implies that the script should be executed in a deferred way, hence using the defer attribute is unnecessary and invalid.
Steps to Fix the Issue:
- Remove the defer Attribute: When you use type="module", you should not include the defer attribute since module scripts defer automatically.
Incorrect Code:
<script type="module" defer src="example.js"></script>Corrected Code:
<script type="module" src="example.js"></script>The <script> tag allows authors to include dynamic scripts and data blocks in their documents. When the src is present, this tag accepts a type attribute which must be either:
- an empty string
- text/javascript (that’s the default, so it can be omitted)
- module
Examples:
<!-- This is valid, without a type it defaults to JavaScript -->
<script src="app.js"></script>
<!-- This is valid, but will warn that it can be omitted -->
<script type="text/javascript" src="app.js"></script>
<!-- An empty attribute is valid, but will warn that it can be omitted -->
<script type="" src="app.js"></script>
<!-- The module keyword is also valid as a type -->
<script type="module" src="app.js"></script>
<!-- Any other type is invalid -->
<script type="wrong" src="app.js"></script>
<script type="text/html" src="app.js"></script>
<script type="image/jpeg" src="app.js"></script>Ensure the src attribute on the script element is non-empty and points to a valid resource.
The src attribute in a script element specifies the URL of an external script file. An empty src attribute is invalid because it tells the browser to fetch a resource from a URL that is not provided, leading to loading errors. Instead, ensure that the src attribute contains a valid file path or URL to an existing script file. If the script content is meant to be inline, you should omit the src attribute altogether and include the script content directly within the script element.
Example of a Valid External Script
Here is a valid example of a script element with a non-empty src attribute:
<!DOCTYPE html>
<html lang="en">
<head>
<title>Valid Script Example</title>
</head>
<body>
<script src="path/to/script.js"></script>
</body>
</html>Example of a Valid Inline Script
If the script is to be written inline, exclude the src attribute and write the JavaScript code directly within the script tags:
<!DOCTYPE html>
<html lang="en">
<head>
<title>Inline Script Example</title>
</head>
<body>
<script>
console.log('This is an inline script.');
</script>
</body>
</html>Troubleshooting
Double-check the script’s file path:
- Ensure the file path you provide in the src is correct relative to the HTML file.
- Make sure the script file exists in the location specified.
- If using a network URL, verify that the URL is correct and accessible.
The issue arises from the space character in the src attribute value of the script element. In URLs, spaces are not allowed and should be properly encoded to avoid validation errors.
Fix
Replace spaces with %20, which is the URL-encoded representation of a space.
Example
Before:
<script src="https://example.com/media assets/app.js"></script>After:
<script src="https://example.com/media%20assets/app.js"></script>Explanation
In this example, the space between “media” and “assets” in the URL is replaced with %20. This change ensures that the URL conforms to standards and is correctly processed by browsers and servers. Spaces and other special characters in URLs must be encoded to ensure proper formatting and accessibility.
There is an illegal double quote character (") at the end of the src attribute value in your <script> tag, which causes the attribute to be invalid.
Attribute values must not include unescaped or stray quote characters (" or ') inside them, as this breaks attribute parsing and results in invalid HTML. The src attribute for a <script> tag should contain a properly encoded URL without any stray quotes or illegal characters. In your case, a double quote has accidentally been included before the closing quote of the attribute.
Correct usage for a <script> tag with the async attribute is:
<script src="https://example.com/js/jquery-3.6.0.min.js?ver=6.8.2" async></script>Incorrect example with the error (shows the issue):
<script src="https://example.com/js/jquery-3.6.0.min.js?ver=6.8.2" async""></script>Make sure there are no stray characters in your attribute values and that boolean attributes like async do not have values—it should simply be present, as in async, not async"" or async="async".
If you need a full, minimal HTML document to validate, use:
<!DOCTYPE html>
<html lang="en">
<head>
<title>Valid Script Tag Example</title>
</head>
<body>
<script src="https://example.com/js/jquery-3.6.0.min.js?ver=6.8.2" async></script>
</body>
</html>Double-check your HTML source code to ensure there are no accidental typos or misplaced quote marks in your tag attributes.
The async and defer boolean attributes of the <script> element control how an external script should be executed once it has been downloaded. The async attribute makes sense when an external script (defined with the src attribute) is loaded, or when defining a script of type module:
<script async src="app.js"></script>
<script async type="module">
/* JavaScript module code here */
</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>Illegal character “[” in the iframe src URL requires percent-encoding or removal.
The iframe element’s src must be a valid URL. According to URL syntax, characters like [ and ] are not allowed in the query unless percent-encoded. If your src contains array-like parameters (e.g., filters[category]=news), encode reserved characters: [ becomes %5B and ] becomes %5D. Avoid spaces and encode other reserved characters as needed. Alternatively, adjust the server to accept dot or bracketless notation (e.g., filters.category=news or filters_category=news) so the URL stays valid without encoding.
HTML Examples
Example causing the validator error
<!DOCTYPE html>
<html lang="en">
<head>
<title>Iframe URL Error</title>
</head>
<body>
<!-- [ and ] are illegal in URLs unless encoded -->
<iframe src="https://example.com/embed?filters[category]=news&filters[tags]=web"></iframe>
</body>
</html>Fixed example with percent-encoding
<!DOCTYPE html>
<html lang="en">
<head>
<title>Iframe URL Fixed</title>
</head>
<body>
<!-- Encode [ as %5B and ] as %5D -->
<iframe src="https://example.com/embed?filters%5Bcategory%5D=news&filters%5Btags%5D=web"></iframe>
</body>
</html>An <iframe> element allows to embed an HTML document inside another HTML document, and its src attribute is indicated the source URL of the embedded web page. The src attribute is a required attribute, so it cannot be blank.
Example:
<iframe src="https://example.com/map.html"></iframe>A fragment identifier (the part after #) is not allowed in a data: URL used in an img src.
The img element accepts any valid URL in the src attribute, including data URLs per RFC 2397. However, RFC 2397 forbids fragment identifiers in data: URIs.
If you need to reference an internal fragment (e.g., an SVG symbol or id), use one of these approaches:
- Inline the SVG in the DOM and reference its ids normally.
- Put the SVG in a separate file and use a standard URL with a fragment (example.svg#icon).
- Remove the fragment from the data: URL and ensure the content renders without fragment navigation.