HTML Guides for unknown element

The <gcse:search> element is a custom tag from Google's Programmable Search Engine widget and is not part of any HTML specification.

Google's Programmable Search Engine (formerly Custom Search Engine) offers two ways to drop a search box onto a page. The older one uses namespaced tags such as <gcse:search>, <gcse:searchbox>, and <gcse:searchresults>, which the loaded cse.js script finds and replaces with the real widget. Browsers do not recognize the gcse: prefix, so they treat the tag as an unknown element, and the W3C validator rejects it because no such element exists in HTML.

Google supports an equivalent form that is valid HTML: a standard <div> carrying a gcse- class, like <div class="gcse-search">. The script reads the class instead of a custom tag name and renders the same search box. Switching to the class form clears the validation error without changing how the widget works.

HTML examples

Invalid: namespaced <gcse:search> element

<script async src="https://cse.google.com/cse.js?cx=YOUR_SEARCH_ENGINE_ID"></script>

<gcse:search></gcse:search>

Valid: div with the gcse-search class

<script async src="https://cse.google.com/cse.js?cx=YOUR_SEARCH_ENGINE_ID"></script>

<div class="gcse-search"></div>

The same applies to the other Programmable Search tags: replace <gcse:searchbox> with <div class="gcse-searchbox"></div> and <gcse:searchresults> with <div class="gcse-searchresults"></div>. Each gcse: element has a matching gcse- class that produces the same result and passes validation.

The <o:p> element is a Microsoft Office namespace tag that has no meaning in HTML and is not part of any HTML specification.

When content is copied from Microsoft Word, Outlook, or other Office applications and pasted into an HTML document, the source often includes proprietary XML namespace elements like <o:p>, <o:OfficeDocumentSettings>, and similar tags. These belong to the urn:schemas-microsoft-com:office:office namespace and are only understood by Office applications. Browsers ignore them, but the W3C validator flags them as errors because they are not valid HTML elements.

The <o:p> tag specifically is used by Word to wrap paragraph content. It typically appears inside <p> elements and most often contains nothing or just a non-breaking space ( ). Removing it entirely has no effect on the rendered page.

If the <o:p> element wraps actual text content, replace it with a standard HTML element like <span> or simply keep the text without any wrapper. If it is empty or contains only  , delete it.

HTML examples

Invalid: Office namespace element in HTML

<p>This is a paragraph.<o:p></o:p></p>

<p>

<o:p>&nbsp;</o:p>

</p>

Valid: Office elements removed

<p>This is a paragraph.</p>

When cleaning up Office-generated HTML, also look for other common namespace prefixes like <w:, <m:, and <v:, along with mso- prefixed CSS properties in style attributes. These are all Office artifacts and should be removed. Many text editors and CMS platforms have a "Paste as plain text" option that strips this markup automatically.

HTML does not define the element named in this message, and its name does not qualify as a custom element, so the validator rejects it wherever it appears.

Browsers still show the content of an unknown tag. They treat the tag as a generic inline element with no default styling, no meaning and no accessibility role, so its text renders as if the tag weren't there. The validator reports it because nothing in the HTML standard says what the element is.

The same tag also triggers a second error, Element "X" not allowed as child of element "Y" in this context, and the fix below clears both. The validator writes the element name in lowercase, so <st1:City> is reported as st1:city.

Most unknown elements come from one of these sources:

• A typo in a real element name, such as <buton> or <sectoin>.
• Markup left behind by Microsoft Word when a document is saved as HTML or pasted into an editor. Word adds tags with a namespace prefix: <o:p> around paragraph content, <w:...> for document settings, and "smart tags" like <st1:place>, <st1:city> or <st1:metricconverter> around places, dates and measurements.
• Tag names invented for styling or scripting, such as <tabs> or <icon>, or placeholders from a widget or template engine that were never replaced.

Correct the name if it's a typo. For Word markup, delete the tags and keep the text inside them, since the wrapper does nothing in a browser. Most editors and CMSs have a "paste as plain text" option that keeps this markup out in the first place.

If you need an element of your own, give it a custom element name: lowercase, starting with a letter, and containing a hyphen, such as <unit-converter>. The validator accepts that name, and you can define its behavior with customElements.define().

Invalid example

<p>The table is <st1:metricconverter productid="120 cm">120 cm</st1:metricconverter> wide.</p>

<buton type="button">Add to cart</buton>

Valid example

<p>The table is 120 cm wide.</p>

<button type="button">Add to cart</button>

Valid example with a custom element

<p>The table is <unit-converter value="120" unit="cm">120 cm</unit-converter> wide.</p>

<script>

customElements.define("unit-converter", class extends HTMLElement {});

</script>

Inline SVG in an HTML document can only contain elements that SVG defines, and the element named in this message isn't one of them.

This message usually comes from editor metadata. Inkscape (and Sodipodi, the editor it grew out of) writes two extra things into its SVG files: a <metadata> block that describes the file in RDF, using Dublin Core (dc:) and Creative Commons (cc:) terms, and a <sodipodi:namedview> element that stores editor settings such as the page color and zoom level. Paste the file into a page, or let a build tool inline it, and all of that comes along.

In a standalone SVG file, those prefixes point to other XML namespaces. The HTML parser doesn't treat a prefix as a namespace, so <rdf:RDF> becomes an SVG element whose name happens to contain a colon. SVG has no element by that name, and the validator reports each one it finds: rdf:rdf, cc:work, dc:format, dc:type, dc:title and sodipodi:namedview. Names are reported in lowercase, so <cc:Work> shows up as cc:work.

The outermost element of each block also gets a second error, such as Element "rdf:rdf" not allowed as child of element "metadata" in this context, and the same fix clears both. A misspelled SVG element like <circel> triggers this message too, and there the fix is to correct the spelling.

The <metadata> element itself is valid. The validator accepts it empty or with plain text inside; only the RDF markup nested in it fails. None of this markup is drawn, so removing it doesn't change how the image looks.

The same export usually puts xmlns:dc, xmlns:cc, xmlns:rdf, xmlns:sodipodi and xmlns:inkscape declarations on the <svg> element, plus prefixed attributes such as inkscape:version and sodipodi:docname. The validator reports those separately (Attribute "xmlns:rdf" not allowed here.), and they go in the same cleanup:

• Delete the <metadata> block and the <sodipodi:namedview> element.
• Delete the xmlns: declarations and every inkscape: or sodipodi: attribute.

If the image needs a title, use SVG's own <title> element, which also gives the image an accessible name.

To clean files before they reach the page, run them through SVGO. Its default preset includes removeMetadata and removeEditorsNSData, which strip both kinds of markup. In Inkscape, Save As "Optimized SVG" can remove metadata as well. "Plain SVG" drops the Inkscape and Sodipodi markup but can leave the <metadata> block in place.

Invalid example

<svg xmlns="http://www.w3.org/2000/svg"

xmlns:dc="http://purl.org/dc/elements/1.1/"

xmlns:cc="http://creativecommons.org/ns#"

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"

xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"

width="24" height="24" viewBox="0 0 24 24">

<metadata>

<rdf:RDF>

<cc:Work rdf:about="">

<dc:format>image/svg+xml</dc:format>

<dc:type rdf:resource="http://purl.org/dc/dcmitype/StillImage" />

<dc:title>Search</dc:title>

</cc:Work>

</rdf:RDF>

</metadata>

<sodipodi:namedview pagecolor="#ffffff" inkscape:zoom="8" />

<circle cx="10" cy="10" r="7" fill="none" stroke="currentColor" stroke-width="2" />

<path d="M15 15l6 6" stroke="currentColor" stroke-width="2" />

</svg>

Valid example

<svg width="24" height="24" viewBox="0 0 24 24" role="img">

<title>Search</title>

<circle cx="10" cy="10" r="7" fill="none" stroke="currentColor" stroke-width="2" />

<path d="M15 15l6 6" stroke="currentColor" stroke-width="2" />

</svg>