Meta tags control how search engines index your page, how social platforms preview it when users share a link, and how browsers render the document at a fundamental level.
Loading HTML Validator…
Validates charset, viewport, and canonical meta tags
Catches duplicate meta declarations
Checks attribute values on meta elements
Free with no sign-up required
Drop the HTML Validator into any page — blog post, product docs, intranet, school portal — with a single line of HTML. Your visitors get the full tool, processed entirely in their browser. No backend, no uploads, no signup.
Embed code
<iframe
src="https://www.fixtools.io/html/html-validator?embed=1"
width="100%"
height="780"
frameborder="0"
style="border:0;border-radius:16px;max-width:900px;"
title="HTML Validator by FixTools"
loading="lazy"
allow="clipboard-write"
></iframe>Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.
The HTML specification defines a set of standard meta element names and the required attributes that go with each one. The charset meta element must use the charset attribute and its value must be a valid character encoding label drawn from the WHATWG Encoding Standard, with utf-8 being the universally recommended value for modern web pages. The viewport meta tag is not standardised in the HTML Living Standard but is universally supported across browsers and is essential for correct mobile rendering. The meta name and content pattern covers standardised name values for author, description, keywords, robots, generator, and several others, with each name having its own conventions around the content value format. The HTML validator checks that meta elements have the correct attribute syntax, that required attributes are present where the spec requires them, and that the charset declaration appears as the first element in the head to satisfy the HTML5 requirement that character encoding be declared within the first 1024 bytes of the document for parser correctness.
Open Graph tags (og:title, og:description, og:image, og:url, og:type, and the many other og:* properties defined by Facebook) use the property attribute rather than the name attribute, following the RDFa pattern that Open Graph borrowed from semantic web technologies. Twitter Card tags use the name attribute with values like twitter:card, twitter:title, twitter:description, and twitter:image, following the standard meta name pattern but with platform-specific name prefixes. Neither Open Graph nor Twitter Card is defined in the HTML specification itself, but both are validated against their own schemas by the respective platforms when they crawl your page. The HTML validator will check that meta elements with these attributes have correct basic HTML structure, including proper attribute syntax and required attribute presence, but it will not validate whether the og:image URL is actually reachable or whether the og:type value is in Facebook's permitted list of types.
Canonical link elements use rel="canonical" on a link element specifically, not a meta element, which is a frequent source of confusion for developers writing canonical declarations for the first time. A common error pattern is writing a meta tag with a name="canonical" attribute instead of the correct link element with rel="canonical". The HTML spec does not define a canonical meta name, so meta name="canonical" content="..." is simply ignored by search engines and provides no canonical signal at all despite looking superficially correct. The correct markup is link rel="canonical" href="..." placed in the head section, and ideally the href value should be an absolute URL including scheme and hostname to remove any ambiguity for the crawler. HTML validation catches misuse of the link element and incorrect rel attribute values, and duplicate canonical declarations are flagged as duplicate element errors that confuse search engine crawlers about your intended canonical URL.
There is one additional category of meta tag issues that is worth understanding even though it falls outside what the validator can directly check. Meta tags affect rendering and indexing only if they are actually present in the HTML that reaches the user agent or crawler. Single-page applications that inject meta tags dynamically via JavaScript may have correct meta tags in the rendered DOM but missing or incorrect meta tags in the initial HTML response, which is what crawlers and social platforms see when they fetch the page. Validation of the static HTML response will not flag this because the meta tags really are missing from that response. Server-side rendering or pre-rendering is the typical fix, and validating the rendered output of those techniques confirms that the meta tags are present where they need to be.
Paste your full HTML including the complete head section. Validation will check meta element structure, charset declaration placement, and link element attributes. Fix structural errors before testing social sharing previews.
Step-by-step guide to validate html meta tags online:
Paste the full HTML document
Paste the complete HTML including the entire head section with all meta and link elements. The validator needs the full document to apply head-section rules correctly because some checks depend on element order and overall document structure rather than just isolated meta tag syntax.
Validate
Click the validate button to check the head section structure against the spec. The validator will examine every meta and link element, check attribute presence and values, and report any structural problems including duplicate declarations and misplaced charset tags.
Fix meta tag structural errors
Address errors related to missing attributes on meta elements, incorrect placement of the charset declaration, duplicate meta name declarations such as multiple meta description tags, and any unclosed meta elements that are causing downstream parse errors in the head section.
Check canonical link syntax
Confirm that you are using a link element with rel="canonical" and not a meta element with name="canonical". The latter is a common mistake that produces no canonical signal at all because the HTML spec does not define canonical as a meta name value.
Test social sharing after validation
Use the Facebook Sharing Debugger or Twitter Card Validator to confirm that Open Graph and Twitter Card tags actually produce the expected previews when the page is shared, now that the underlying HTML errors have been fixed. These platform tools test what the validator cannot test.
Common situations where this approach makes a real difference:
Debugging a page that shows wrong social preview
A page consistently shares with no image preview on Facebook even though the og:image tag appears correct on visual inspection. Validating the HTML reveals an unclosed meta tag earlier in the head section that causes the og:image meta element to be malformed in the parser's view of the document, so Facebook's crawler never sees a valid og:image declaration. Fixing the unclosed tag immediately restores the Open Graph image preview without any other changes needed.
Auditing a site migration for head section completeness
After migrating a site to a new content management system, validation of several representative pages reveals missing charset declarations on pages that lost them during the migration, duplicate canonical link elements on pages where both the old and new CMS were generating canonicals, and pages where the viewport meta tag was dropped entirely. Fixing these issues ensures consistent browser rendering across the migrated content and prevents duplicate content indexing issues that would have hurt search rankings.
Validating a new landing page before launch
A new product landing page is validated as part of the pre-launch checklist. Validation catches a meta description that exceeds reasonable length limits and may be truncated in search results, a malformed canonical link with a relative URL where an absolute URL was intended for crawler clarity, and a viewport tag using a deprecated syntax that produces inconsistent mobile rendering in older browsers. All three issues are fixed before the page goes live.
Checking template meta tags after a framework upgrade
After upgrading a frontend framework to a new major version, automated template generation introduces a duplicate title element when the new version's default head template combines with the existing application-level head template, and the new version changes the order of meta tags so the charset declaration no longer appears first in the head section. Validation catches both issues before the upgrade is deployed to production, where they would have caused subtle rendering and indexing problems.
Get better results with these expert suggestions:
Charset declaration must be the first element in head
The HTML5 spec requires the charset meta tag to appear within the first 1024 bytes of the document, which in practice means it should be the first element inside the head section before any other meta tags or link elements. Placing other elements before the charset declaration is a spec violation that strict validators flag explicitly. The reason for the rule is that the parser must know the document encoding before it encounters any text that might be affected by the encoding, including text inside title elements or other meta tag content values.
Canonical should use an absolute URL
The canonical link element is processed by search engine crawlers, which need an absolute URL to unambiguously determine the canonical page address regardless of which URL the crawler initially used to reach the page. Using a relative URL in the canonical href is technically valid HTML and the spec allows it, but it is ambiguous for crawlers and may produce inconsistent canonicalisation behavior across different search engines. Use the full absolute URL including the scheme and hostname in every canonical declaration to remove this ambiguity entirely.
One title element only
The HTML spec permits exactly one title element in the head section of any HTML document. Duplicate title elements are a spec violation that validators flag. CMS themes and plugins sometimes inject a second title element accidentally, particularly when SEO plugins conflict with the theme's default title output and both end up adding their own title to the head. Validation catches this duplication quickly and identifies which two locations in the document each title element is being generated from.
Validate after every CMS or plugin update
CMS plugins frequently modify the head section to add tracking tags, SEO meta tags, analytics scripts, or other integrations. Updates to any of these plugins can introduce structural errors in the head section that were not present before the update, often because the plugin authors did not consider all possible interactions with other plugins. A quick validation pass after any plugin update catches regressions before they affect live site indexing or social sharing, which is much harder to debug after the fact.
More use-case guides for the same tool:
Other tools you might find useful:
Open the full HTML Validator — free, no account needed, works on any device.
Open HTML Validator →Free · No account needed · Works on any device