HTML Validation

HTML Guides for http-equiv

Learn how to identify and fix common HTML validation errors flagged by the W3C Validator — so your pages are standards-compliant and render correctly across every browser. Also check our Accessibility Guides.

Scan Your Site Free

A document must not include both a “meta” element with an “http-equiv” attribute whose value is “content-type”, and a “meta” element with a “charset” attribute.

Both <meta charset="UTF-8"> and <meta http-equiv="content-type" content="text/html; charset=UTF-8"> instruct the browser which character encoding to use when interpreting the document’s bytes into text. Having both declarations in the same document creates a redundant and potentially conflicting situation. The HTML specification explicitly forbids including both, because if they ever specified different encodings, the browser would have to decide which one to trust, leading to unpredictable behavior.

Character encoding is critical for correctly displaying text. If the encoding is wrong or ambiguous, characters like accented letters, emoji, or symbols from non-Latin scripts can appear as garbled text (often called “mojibake”). By requiring a single, unambiguous declaration, the spec ensures browsers can reliably determine the encoding.

The <meta charset="UTF-8"> syntax was introduced with HTML5 as a shorter, cleaner alternative to the older <meta http-equiv="content-type"> approach. Both are valid on their own, but modern best practice strongly favors <meta charset="UTF-8"> for its simplicity. Whichever you choose, it should appear as early as possible within the <head> element — ideally as the first child — and must appear within the first 1024 bytes of the document so the browser can detect the encoding before parsing the rest of the content.

To fix this issue, search your document’s <head> for both forms of the declaration and remove one of them. In most cases, you should keep <meta charset="UTF-8"> and remove the <meta http-equiv="content-type"> element.

Examples

Incorrect: both declarations present

This triggers the validation error because both methods of declaring the character encoding are used simultaneously.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <title>My Page</title>
  </head>
  <body>
    <p>Hello, world!</p>
  </body>
</html>

Correct: using <meta charset> (recommended)

This is the modern, preferred approach for HTML5 documents.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <title>My Page</title>
  </head>
  <body>
    <p>Hello, world!</p>
  </body>
</html>

Correct: using <meta http-equiv="content-type">

This older syntax is also valid on its own. You might encounter it in legacy codebases or when serving documents as application/xhtml+xml.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <title>My Page</title>
  </head>
  <body>
    <p>Hello, world!</p>
  </body>
</html>

Common scenario: declarations split across includes

In templating systems or CMS platforms, the two declarations sometimes end up in different partial files — for example, one in a base layout and another injected by a plugin or theme. If you encounter this error unexpectedly, check all files that contribute to your <head> section, not just the main template.

<!-- base-layout.html -->

<head>
  <meta charset="UTF-8">
<!-- ...other tags... -->

</head>

<!-- plugin-head-snippet.html (remove this duplicate) -->

<meta http-equiv="content-type" content="text/html; charset=UTF-8">

Audit your includes and partials to ensure only one character encoding declaration ends up in the final rendered <head>.

A “meta” element with an “http-equiv” attribute whose value is “X-UA-Compatible” must have a “content” attribute with the value “IE=edge”.

The X-UA-Compatible meta tag was originally introduced to control which rendering engine Internet Explorer would use to display a page. Developers could force IE to emulate older versions (e.g., IE=7, IE=9) or use the latest available engine with IE=edge. The value IE=edge,chrome=1 was also commonly used to activate the Google Chrome Frame plugin, which allowed Internet Explorer to use Chrome’s rendering engine instead.

The HTML specification now only permits the value IE=edge for this meta tag. Other values are considered invalid for several reasons:

Google Chrome Frame is discontinued. The chrome=1 directive targeted a plugin that was retired in February 2014 and is no longer supported by any browser.
Legacy IE rendering modes are obsolete. Internet Explorer itself has been retired, making emulation modes like IE=EmulateIE7 or IE=9 pointless.
Standards compliance. The WHATWG HTML living standard explicitly requires the content attribute value to be IE=edge when http-equiv="X-UA-Compatible" is used.

In practice, since all modern browsers use their latest rendering engine by default, this meta tag has little functional impact today. If your site no longer needs to support Internet Explorer at all, you can safely remove the tag entirely. If you choose to keep it — for example, in environments where legacy IE browsers might still access your site — ensure the value is exactly IE=edge.

Examples

Invalid: Using chrome=1 with IE=edge

This was a common pattern when Google Chrome Frame was active, but it now triggers a validation error:

<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">

Invalid: Using a legacy IE rendering mode

Forcing a specific IE version is no longer valid:

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7">

Invalid: Specifying a particular IE version

<meta http-equiv="X-UA-Compatible" content="IE=9">

Valid: Using IE=edge

The only accepted value is IE=edge:

<meta http-equiv="X-UA-Compatible" content="IE=edge">

Valid: Removing the tag entirely

If you don’t need Internet Explorer compatibility, the simplest fix is to remove the meta tag altogether. A minimal valid document without it:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>My Page</title>
  </head>
  <body>
    <p>Hello, world!</p>
  </body>
</html>

Attribute “http-equiv” not allowed on element “meta” at this point.

The http-equiv attribute on a <meta> element simulates an HTTP response header, allowing you to define document-level metadata that would otherwise require server configuration. Because this metadata applies to the entire document and must be processed before the page content is rendered, the HTML specification requires that <meta http-equiv> elements appear within the <head> element. Placing them in the <body> is invalid and may cause browsers to ignore them entirely, leading to unexpected behavior like incorrect character encoding, broken content security policies, or missing refresh directives.

This error commonly occurs when:

A <meta http-equiv> tag is accidentally placed inside <body>.
Content is copy-pasted from one document into the body of another, bringing along <meta> tags.
A templating system or CMS injects <meta> tags in the wrong location.

Common http-equiv values

The http-equiv attribute supports several standard values:

content-type — Declares the document’s MIME type and character encoding. In HTML5, the shorthand <meta charset="UTF-8"> is preferred instead.
refresh — Instructs the browser to reload the page or redirect after a specified number of seconds. Note that automatic refreshing is discouraged for accessibility reasons: it can disorient users, move focus back to the top of the page, and disrupt assistive technology. Avoid it unless absolutely necessary.
content-security-policy — Defines a Content Security Policy for the document, helping prevent cross-site scripting (XSS) and other code injection attacks.
default-style — Specifies the preferred stylesheet from a set of alternative stylesheets.

How to fix it

Find every <meta http-equiv> element in your document and ensure it is placed inside the <head> element, before any content in <body>. If the tag is duplicated or unnecessary, remove it.

Examples

❌ Incorrect: http-equiv inside <body>

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>My Page</title>
  </head>
  <body>
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <p>Hello, world!</p>
  </body>
</html>

The <meta http-equiv> tag is inside <body>, which triggers the validation error.

✅ Correct: http-equiv inside <head>

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <title>My Page</title>
  </head>
  <body>
    <p>Hello, world!</p>
  </body>
</html>

✅ Correct: using the HTML5 charset shorthand

In HTML5, you can replace <meta http-equiv="content-type" content="text/html; charset=UTF-8"> with the simpler charset attribute:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <title>My Page</title>
  </head>
  <body>
    <p>Hello, world!</p>
  </body>
</html>

✅ Correct: Content Security Policy in <head>

<head>
  <meta charset="UTF-8">
  <meta http-equiv="content-security-policy" content="default-src 'self'">
  <title>Secure Page</title>
</head>

The content-security-policy value is particularly placement-sensitive — browsers will ignore it if it appears outside <head>, leaving your page without the intended security protections.

Bad value “Cache-Control” for attribute “http-equiv” on element “meta”.

The http-equiv attribute on the <meta> element is designed to simulate certain HTTP response headers when a server isn’t configured to send them directly. However, the HTML specification only permits a limited set of values for this attribute. According to the WHATWG HTML living standard, the valid http-equiv values are:

content-type — an alternative way to declare character encoding
default-style — sets the preferred stylesheet
refresh — redirects or reloads the page after a delay
x-ua-compatible — specifies document compatibility mode for Internet Explorer
content-security-policy — declares a content security policy

Using Cache-Control as an http-equiv value is a pattern that originated in early web development, when some browsers attempted to honor cache directives set through <meta> tags. In practice, modern browsers ignore <meta http-equiv="Cache-Control"> entirely. Caching behavior is determined by actual HTTP response headers sent by the server, not by <meta> tags in the document body. This means the tag not only triggers a validation error but also has no practical effect — it gives a false sense of control over caching while doing nothing.

This matters for several reasons. Invalid HTML can cause unexpected behavior in browsers, particularly edge cases with older or less common user agents. It also undermines confidence in your markup — if a validator flags issues, it becomes harder to spot genuinely important errors. Additionally, relying on a non-functional tag for caching can lead to real problems if developers assume caching is being handled when it isn’t.

The correct approach is to configure cache-control headers on your web server or application layer. Every major web server and framework provides a straightforward way to set Cache-Control HTTP headers.

For Apache, you can add this to your .htaccess or server configuration:

Header set Cache-Control "no-cache, no-store, must-revalidate"

For Nginx, use:

add_header Cache-Control "no-cache, no-store, must-revalidate";

In a Node.js/Express application:

res.set('Cache-Control', 'no-cache, no-store, must-revalidate');

Examples

Invalid: Using Cache-Control as an http-equiv value

<!DOCTYPE html>
<html lang="en">
<head>
  <title>My Page</title>
  <meta http-equiv="Cache-Control" content="no-cache">
  <meta http-equiv="Pragma" content="no-cache">
  <meta http-equiv="Expires" content="0">
</head>
<body>
  <p>This page attempts to control caching via meta tags.</p>
</body>
</html>

In this example, all three <meta> tags are problematic. Cache-Control and Pragma are not valid http-equiv values. While Expires was historically used, it is also not in the current list of conforming values in the WHATWG specification.

Fixed: Removing invalid <meta> tags

<!DOCTYPE html>
<html lang="en">
<head>
  <title>My Page</title>
<!-- Cache-Control should be set via server HTTP headers -->

</head>
<body>
  <p>Caching is now properly handled server-side.</p>
</body>
</html>

The invalid <meta> tags are removed entirely. Cache behavior is configured on the server, where it actually takes effect.

Valid: Using a permitted http-equiv value

<!DOCTYPE html>
<html lang="en">
<head>
  <title>Redirecting</title>
  <meta http-equiv="refresh" content="5;url=https://example.com">
</head>
<body>
  <p>You will be redirected in 5 seconds.</p>
</body>
</html>

This example uses refresh, which is a valid http-equiv value. It demonstrates what the attribute is actually designed for — a small set of well-defined, browser-supported directives.

Bad value “cleartype” for attribute “http-equiv” on element “meta”.

The http-equiv attribute on <meta> elements acts as a pragma directive, simulating the effect of an HTTP response header. The HTML specification defines a strict list of allowed values, including content-type, default-style, refresh, x-ua-compatible, and content-security-policy. Any value not on this list — such as cleartype — is considered invalid and will trigger a validation error.

The <meta http-equiv="cleartype" content="on"> tag was a proprietary Microsoft extension designed to activate ClearType text smoothing in Internet Explorer Mobile 6 and 7 on Windows Phone. ClearType is a sub-pixel rendering technology that improves the readability of text on LCD screens. Since these browsers are long obsolete, this meta tag serves no practical purpose today. No modern browser recognizes or acts on it.

Keeping invalid meta tags in your HTML has several downsides:

Standards compliance: It produces W3C validation errors, which can mask other, more important issues in your markup.
Code cleanliness: Dead code clutters your document head and confuses developers who may not know its history.
No functional benefit: Since no current browser or rendering engine uses this directive, it provides zero value.

The fix is straightforward: remove the <meta http-equiv="cleartype"> tag. If your project requires smooth font rendering on modern browsers, CSS properties like font-smooth (non-standard) or -webkit-font-smoothing and -moz-osx-font-smoothing can be used instead, though these are also non-standard and should be used with care.

Examples

❌ Invalid: Using cleartype as an http-equiv value

<head>
  <meta charset="utf-8">
  <meta http-equiv="cleartype" content="on">
  <title>My Page</title>
</head>

This triggers the validation error because cleartype is not a valid value for http-equiv.

✅ Fixed: Remove the invalid meta tag

<head>
  <meta charset="utf-8">
  <title>My Page</title>
</head>

Simply removing the tag resolves the error with no loss of functionality in modern browsers.

✅ Alternative: Use CSS for font smoothing if needed

If you want to influence text rendering, use CSS instead of a non-standard meta tag:

body {
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
}

Note that these CSS properties are themselves non-standard and primarily affect macOS and iOS rendering. On Windows, modern browsers already apply ClearType or DirectWrite smoothing automatically without any developer intervention.

Bad value “Content-Script-Type” for attribute “http-equiv” on element “meta”.

The http-equiv attribute on the <meta> element simulates HTTP response headers. However, the HTML living standard only allows a specific set of values for http-equiv, and Content-Script-Type is not among them. The allowed values include content-type, default-style, refresh, x-ua-compatible, and content-security-policy.

In HTML 4.01, <meta http-equiv="Content-Script-Type" content="text/javascript"> was used to tell the browser which scripting language to assume for inline event handlers (like onclick). Since JavaScript is now the only scripting language supported by browsers, this declaration serves no purpose. Every modern browser already assumes JavaScript by default, making this meta tag completely redundant.

Removing this tag has no effect on your page’s behavior. Your scripts will continue to work exactly as before. If you’re maintaining a legacy codebase, you can safely delete this line during any cleanup or modernization effort.

Examples

❌ Invalid: using Content-Script-Type

<head>
  <meta charset="utf-8">
  <meta http-equiv="Content-Script-Type" content="text/javascript">
  <title>My Page</title>
</head>

This triggers the validation error because Content-Script-Type is not a valid http-equiv value in modern HTML.

✅ Fixed: remove the obsolete meta tag

<head>
  <meta charset="utf-8">
  <title>My Page</title>
</head>

Simply remove the <meta http-equiv="Content-Script-Type"> line. No replacement is needed — browsers already default to JavaScript for all script handling.

✅ Valid http-equiv values for reference

Here are some examples of http-equiv values that are valid in modern HTML:

<head>
  <meta charset="utf-8">
  <meta http-equiv="x-ua-compatible" content="IE=edge">
  <meta http-equiv="refresh" content="30">
  <meta http-equiv="content-security-policy" content="default-src 'self'">
  <title>My Page</title>
</head>

Bad value “”Content-Security-Policy”” for attribute “http-equiv” on element “meta”.

The http-equiv attribute accepts a specific set of predefined values, and the validator checks both the value itself and its formatting. When the validator reports a bad value of ""Content-Security-Policy"" (note the doubled quotes), it means the actual attribute value being parsed includes literal quotation mark characters as part of the string. The browser sees the first " as opening the attribute, then immediately sees the second " as closing it — resulting in a malformed tag that won’t work as intended.

This matters for several reasons. Content-Security-Policy delivered via a <meta> tag is a critical security mechanism that restricts which resources your page can load. If the tag is malformed, the browser will silently ignore the policy, leaving your site without the CSP protections you intended. There’s no visual indication that the policy failed to apply, making this a particularly dangerous bug.

Common causes of this issue include:

Copying code from a word processor or CMS that converts straight quotes (") into curly/smart quotes (" and ").
Double-escaping in templates where a templating engine adds quotes around a value that already has quotes in the markup.
Manual typos where quotes are accidentally duplicated.

To fix this, open your HTML source in a plain-text editor (not a word processor) and ensure the http-equiv value is wrapped in exactly one pair of standard straight double quotes with no extra quote characters inside.

Examples

Incorrect — doubled quotes around the value

<meta http-equiv=""Content-Security-Policy"" content="default-src 'self';">

The validator interprets this as an http-equiv attribute with an empty value (""), followed by unrecognized content (Content-Security-Policy""), producing the error.

Incorrect — curly/smart quotes

<meta http-equiv="Content-Security-Policy" content="default-src 'self';">

Smart quotes (" and ") are not valid attribute delimiters in HTML. They become part of the attribute value itself, causing the validator to reject it.

Incorrect — HTML entity quotes inside the attribute

<meta http-equiv="&quot;Content-Security-Policy&quot;" content="default-src 'self';">

Using " inside the attribute value embeds literal quote characters into the value string, which makes it invalid.

Correct — single pair of straight double quotes

<meta http-equiv="Content-Security-Policy" content="default-src 'self';">

Correct — full document example

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https:; script-src 'self';">
  <title>CSP Example</title>
</head>
<body>
  <h1>Hello, World!</h1>
</body>
</html>

The http-equiv value Content-Security-Policy must be spelled exactly as shown — it is case-insensitive per the HTML spec, but using the canonical casing is recommended for clarity. The actual policy directives go in the content attribute, not in http-equiv. If you’re using a templating engine or CMS, check the generated HTML source (via “View Page Source” in your browser) to confirm the output contains clean, straight quotes with no doubling.

Bad value “Content-Style-Type” for attribute “http-equiv” on element “meta”.

Why This Is an Issue

In HTML 4 and XHTML, the Content-Style-Type HTTP header (and its <meta http-equiv> equivalent) told the browser which stylesheet language to use when interpreting inline style attributes and <style> elements. This was theoretically necessary because the specification allowed for alternative stylesheet languages beyond CSS.

In practice, CSS became the only stylesheet language browsers support. The HTML living standard (maintained by WHATWG) recognizes this reality and defines a strict list of valid http-equiv values. Content-Style-Type is not among them. The only valid values include content-type, default-style, refresh, x-ua-compatible, content-security-policy, and a few others defined in the spec.

Because every browser defaults to CSS for all styling, this meta tag serves no functional purpose. Keeping it in your markup only produces a validation error and adds unnecessary bytes to your document.

Similarly, the related Content-Script-Type meta tag (which declared the default scripting language) is also obsolete for the same reasons — JavaScript is the universal default.

How to Fix It

The fix is straightforward: remove the <meta http-equiv="Content-Style-Type" ...> tag from your document’s <head>. No replacement is needed. Browsers will interpret all stylesheets as CSS and all scripts as JavaScript without any explicit declaration.

If you inherited this tag from a legacy template or an older CMS, you can safely delete it with no impact on your site’s appearance or behavior.

Examples

❌ Invalid: Using the obsolete Content-Style-Type pragma

<head>
  <meta charset="utf-8">
  <meta http-equiv="Content-Style-Type" content="text/css">
  <title>My Page</title>
</head>

This triggers the validator error: Bad value “Content-Style-Type” for attribute “http-equiv” on element “meta”.

✅ Valid: Simply remove the obsolete meta tag

<head>
  <meta charset="utf-8">
  <title>My Page</title>
</head>

No replacement is needed. CSS is already the default stylesheet language in all browsers.

❌ Invalid: Both Content-Style-Type and Content-Script-Type (common in legacy templates)

<head>
  <meta charset="utf-8">
  <meta http-equiv="Content-Style-Type" content="text/css">
  <meta http-equiv="Content-Script-Type" content="text/javascript">
  <title>Legacy Page</title>
</head>

✅ Valid: Remove both obsolete declarations

<head>
  <meta charset="utf-8">
  <title>Legacy Page</title>
</head>

Both Content-Style-Type and Content-Script-Type are obsolete. Removing them has zero effect on how browsers render your page, and your HTML will pass validation cleanly.

Bad value “Expires” for attribute “http-equiv” on element “meta”.

The http-equiv attribute on the <meta> element is designed to simulate certain HTTP response headers directly in HTML. However, the HTML specification only permits a specific set of values: content-type, default-style, refresh, x-ua-compatible, and content-security-policy. Using Expires as a value for http-equiv will trigger a validation error because it falls outside this permitted set.

Historically, some older browsers and HTML versions were more lenient about which values could appear in http-equiv, and developers commonly used <meta http-equiv="Expires" content="0"> or similar patterns to try to prevent page caching. However, this approach was never reliable — browsers and caching proxies handle actual HTTP headers far more consistently than <meta> tag equivalents. Modern HTML formally disallows this value.

Beyond standards compliance, there are practical reasons to avoid this pattern. Many browsers simply ignore unrecognized http-equiv values, meaning the tag does nothing useful. Cache behavior is best controlled at the HTTP level, where servers, CDNs, and proxies all read and respect the headers. Relying on a <meta> tag for caching gives a false sense of control while cluttering your markup with invalid code.

To fix this issue, remove the <meta http-equiv="Expires" ...> tag from your HTML and configure the Expires or Cache-Control HTTP header on your web server.

Examples

Incorrect: Using Expires in http-equiv

This triggers the validation error:

<head>
  <meta charset="UTF-8">
  <meta http-equiv="Expires" content="0">
  <meta http-equiv="Expires" content="Tue, 01 Jan 2025 00:00:00 GMT">
  <title>My Page</title>
</head>

Correct: Remove the invalid <meta> tag

Simply remove the offending tag. Only use valid http-equiv values:

<head>
  <meta charset="UTF-8">
  <title>My Page</title>
</head>

Correct: Valid uses of http-equiv

For reference, here are examples of valid http-equiv values:

<head>
  <meta charset="UTF-8">
  <meta http-equiv="refresh" content="30">
  <meta http-equiv="content-security-policy" content="default-src 'self'">
  <meta http-equiv="default-style" content="main-stylesheet">
  <title>My Page</title>
</head>

Correct: Set cache expiration via server configuration

The proper way to control caching is through HTTP response headers configured on your server.

Apache (.htaccess or server config):

<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType text/html "access plus 1 day"
</IfModule>

Or using Cache-Control with mod_headers:

<IfModule mod_headers.c>
  Header set Cache-Control "no-cache, no-store, must-revalidate"
  Header set Expires "0"
</IfModule>

Nginx:

location ~* \.html$ {
  expires 1d;
  add_header Cache-Control "public, no-transform";
}

To prevent caching entirely in Nginx:

location ~* \.html$ {
  expires -1;
  add_header Cache-Control "no-store, no-cache, must-revalidate";
}

If you don’t have access to server configuration, many server-side languages let you set headers programmatically. For example, in PHP:

<?php
header("Expires: Tue, 01 Jan 2030 00:00:00 GMT");
header("Cache-Control: public, max-age=86400");
?>

By handling cache expiration at the server level, you get reliable behavior across all browsers, proxies, and CDNs — while keeping your HTML clean and standards-compliant.

Bad value “Pragma” for attribute “http-equiv” on element “meta”.

Pragma is not a valid value for the http-equiv attribute in HTML5.

In HTML5 (as defined by the WHATWG living standard and W3C), the http-equiv attribute on the meta element only allows certain tokens, such as content-type, default-style, and refresh. The use of Pragma is obsolete and was mainly supported in older HTML specifications for compatibility with HTTP/1.0 proxies. The recommended way to control caching in modern web development is through appropriate HTTP headers sent from the server.

Example of the incorrect usage:

<meta http-equiv="Pragma" content="no-cache">

Correct usage for controlling cache with HTML meta tags (but note, affects only some browsers and is not reliable):

<meta http-equiv="Cache-Control" content="no-cache">

However, even Cache-Control in a meta tag has limited effectiveness. The best practice is to set Cache-Control and Pragma headers server-side, not in HTML.

Correct server-side (not HTML) example:

Cache-Control: no-cache
Pragma: no-cache

Summary:
Remove the <meta http-equiv="Pragma" content="no-cache"> tag from your HTML and rely on server-side HTTP headers to manage caching. If you still need a meta-based (less effective) solution for rare cases, use http-equiv="Cache-Control".

Minimal valid HTML example (without the invalid meta tag):

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>No Invalid http-equiv Value</title>
  </head>
  <body>
<!-- Content goes here -->

  </body>
</html>

Element “meta” is missing one or more of the following attributes: “charset”, “content”, “http-equiv”, “itemprop”, “name”, “property”.

The <meta> element provides metadata about the HTML document — information that isn’t displayed on the page but is used by browsers, search engines, and other web services. According to the HTML specification, a <meta> tag without any of the recognized attributes is meaningless. The validator flags this because a bare <meta> element (or one with only unrecognized attributes) provides no useful metadata and likely indicates an error or incomplete tag.

This issue commonly occurs when a <meta> tag is left empty by accident, when an attribute name is misspelled (e.g., naem instead of name), or when a required attribute is accidentally deleted during editing.

Most <meta> use cases fall into a few patterns, each requiring specific attribute combinations:

charset — Used alone to declare the document’s character encoding.
name + content — Used together to define named metadata like descriptions, viewport settings, or author information.
http-equiv + content — Used together to simulate an HTTP response header.
property + content — Used together for Open Graph and similar RDFa-based metadata.
itemprop + content — Used together for microdata annotations.

Note that content alone is not sufficient — it must be paired with name, http-equiv, property, or itemprop to have meaning.

Examples

Incorrect: bare <meta> tag with no attributes

This triggers the validation error because the <meta> element has no recognized attributes:

<meta>

Incorrect: misspelled attribute

A typo in the attribute name means the validator doesn’t recognize it:

<meta nane="description" content="An example page.">

Incorrect: content without a pairing attribute

The content attribute alone is not enough — it needs name, http-equiv, property, or itemprop:

<meta content="some value">

Correct: character encoding with charset

<meta charset="UTF-8">

Correct: named metadata with name and content

<meta name="description" content="A brief description of the webpage.">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="author" content="Jane Doe">

Correct: HTTP-equivalent with http-equiv and content

<meta http-equiv="X-UA-Compatible" content="IE=edge">

Correct: Open Graph metadata with property and content

<meta property="og:title" content="My Page Title">
<meta property="og:description" content="A summary of the page content.">

Correct: microdata with itemprop and content

<meta itemprop="name" content="Product Name">

Full document example

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <meta name="description" content="A brief description of the webpage.">
  <meta property="og:title" content="My Page Title">
  <title>Example Page</title>
</head>
<body>
  <p>Hello, world!</p>
</body>
</html>

How to fix

Find the flagged <meta> tag in your HTML source at the line number the validator reports.
Check for typos in attribute names — make sure name, charset, http-equiv, property, or itemprop is spelled correctly.
Add the missing attribute. Determine what the <meta> tag is supposed to do and add the appropriate attribute(s). If you can’t determine its purpose, it may be safe to remove it entirely.
Ensure proper pairing. If you’re using content, make sure it’s paired with name, http-equiv, property, or itemprop. The charset attribute is the only one that works on its own without content.

Ready to validate your sites?
Start your free trial today.

Pro Trial Free Trial