For many HTML elements, more convenient wikitext code is available, see Help:Wiki markup, however there are some situations in which the HTML alternative is useful, for example creating a link to a particular element of a table.

The following HTML elements are currently permitted:

pre-formatted text

HTML tags allow an id attribute that can be referenced in one's user style CSS, and allows the element to be used as link target.

However, the anchor element a is not allowed, so the wikitext

<a href="http://meta.wikimedia.org/">Main Page</a>

is treated like the wikitext

<a href="http://meta.wikimedia.org/">Main Page</a>

and is therefore displayed as

<a href="http://meta.wikimedia.org/">Main Page</a>

which is unlikely to be what the editor intended. Instead of using the anchor element (<a>) the wiki markup for external reference is required (enclosed in square brackets with the URL separated from the contents by a single space):

[http://meta.wikimedia.org/ Main Page]

displays as

Main Page

The following excerpt from Sanitizer.php additionally shows which attributes are allowed.

$htmlpairsStatic = array( # Tags that must be closed
    'b', 'del', 'i', 'ins', 'u', 'font', 'big', 'small', 'sub', 'sup', 'h1',
    'h2', 'h3', 'h4', 'h5', 'h6', 'cite', 'code', 'em', 's',
    'strike', 'strong', 'tt', 'var', 'div', 'center',
    'blockquote', 'ol', 'ul', 'dl', 'table', 'caption', 'pre',
    'ruby', 'rt' , 'rb' , 'rp', 'p', 'span', 'u', 'abbr'
);
$htmlsingle = array(
    'br', 'hr', 'li', 'dt', 'dd'
);
$htmlsingleonly = array( # Elements that cannot have close tags
    'br', 'hr'
);
$htmlnest = array( # Tags that can be nested--??
    'table', 'tr', 'td', 'th', 'div', 'blockquote', 'ol', 'ul',
    'dl', 'font', 'big', 'small', 'sub', 'sup', 'span'
);
$tabletags = array( # Can only appear inside table, we will close them
    'td', 'th', 'tr',
);
$htmllist = array( # Tags used by list
    'ul','ol',
);
$listtags = array( # Tags that can appear in a list
    'li',
);

<span> is a generic inline text container.

<font> is a similar tag which is deprecated (should not be used) in favor of <span>.

For example

a <font color="red">red</font> word.

produces the same result as

a <span style="color:red">red</span> word.

See also m:Template:font size demo (backlinks edit) and m:Help:Text color.

It's pointless to combine the legacy tag <font> with inline CSS; legacy browsers would ignore the CSS, while modern browsers support <span> (see above).

Note that in most cases, one can use a more descriptive tag, for instance, <strong> to indicate an important piece of text, or <em> (subject to the same things as strong) to indicate an emphasized piece of text.

This not only draws the user's attention to the text, but can also alert those who are using nonvisual browsers or have sight impairments, etc. to the fact that that is emphasized text.

Using <span> as a link target

The standard way of providing a named anchor as an invisible target (i.e. <a name="Foo">) doesn't work (since all <a> tags are converted), and an alternative suggested by the W3C, <hN id="Foo"></hN>, produces an "[Edit]" link.

However, <span id="Foo"/> does produce a target that can be the destination of a link. (This is silently changed to <span id="Foo"></span>). This is the method used by the {{anchor}} template. Note that it doesn't work everywhere; for instance, in a table, it has to be inside a cell before some browsers will jump to it properly.

This technique can be used to produce immutable links from one article to a section of another, which continue to work even if the section name is changed by someone who does not realize that another article links there. For example, <span id="immutable link from Article"/>.

<div>

<div> is a generic block container. Rules:

• <div> should be followed by a newline
• </div> should be preceded by a newline
• </div> followed by text on the same line, two newlines and text before <div> on the same line should be avoided (because the two newlines only produce a space)

HTML comment

Using m:Template:t (backlinks edit):

• Template:Xpd
• "{{subst:xpd|t}}" gives "<!--t-->start-pqr-end", producing HTML code without the comment.

The "Remove comments" option of ExpandTemplates selects whether comments are removed, not just in the final result but throughout the expansion process. This affects the result of parser functions: a comment in the expression of #expr or in the condition of #ifexpr gives an error message unless "Remove comments" is on, and comments affect #if and #ifeq.

Example:

Wikitext:

{{#expr:<!--p-->3}}

{{#ifeq:<!--p-->3|3|1|0}}

{{#if:<!--p-->|1|0}}

Result of normal expansion, and of ExpandTemplates with "Remove comments" on:

3

1

0

Result of full substitution, and of ExpandTemplates with "Remove comments" off:

0

0

1

Therefore it is typically better to avoid comments in these places, and to put the comment before or after the parser function.

In the case of nested parser functions, to avoid having to put the comments outside the whole, an alternative is {{void|comment}}. In the case of substitution of the parser function, "void" has to be substituted too, e.g. in a template allowing multi-level substitution we can put {{{{{subst1|}}}#expr:3*{{{1}}} {{{{{subst1|}}}void| multiply by 3 }}}}.

Another alternative is making the comment the name of a parameter (in the likely case that it is unused), with the empty string as default, e.g. {{{ multiply by 3 |}}} or, to recognize the intention, use pseudo comment tags: {{{<!- multiply by 3 ->|}}}, or real ones, if the empty string is not used as parameter: {{{<!-- multiply by 3 -->|}}}.

See also m:Template:t comment (backlinks edit).

Most tags can have a style attribute. For example

<div style="font-size:80%">
This is <span style="color:red">red</span> text.
</div>

produces:

This is red text.

Most tags can have classes and IDs. They can be used in conjunction with stylesheets to give a piece of text a descriptive class (or unique identifier) and to refer to that in a stylesheet. For example

<div class="infobox">Example infobox</div>

Produces the box which floats on the right because infobox class is already defined in local Mediawiki:Common.css.

Classes and IDs can also be used by Javascript code, for example see how {Link FA} works in enwiki.

Classes are also widely used to create microformats. See the microformats project for more information. Some class names are reserved for use in microformats.

Another attribute example is title, for example used in {{H:title}} template: note the hover box over "20000 ft"

"a height of 6.1 km above sea level"

Pre

<pre> tags work as the combination of <nowiki> and the standard HTML <pre> tag: the content will preformatted, and it will not be parsed, but shown as in the wikitext source. If you want preformatted but parsed text, use a space in the beginning of the line instead. For example,

<pre>This word is <b>bold</b>.</pre>
  This word is <b>bold</b>.

will render as

This word is <b>bold</b>.

This word is bold.

Comments

HTML comments in the wikitext (<!-- ... -->) will not appear in the HTML code at all.

Headers

Headers (<h1>...<h6>) will be treated in a similar way as wikicode headers:

Sample header

Note that it appears in the table of contents and has an accompanying edit link. There are some minor differences though: editing such a section won't prefill the edit summary, and the browser won't jump to the beginning of the section when saving the page. Thus, you should use the wikitext equivalents instead.

In some pages in the MediaWiki namespace (typically the short messages like button labels) HTML does not work, and e.g. <span id=abc> produces the HTML &lt;span id=abc&gt; rendered by the browser as <span id=abc>. Some others are interpreted as pure HTML (thus any tag can be used, but wikicode won't be transformed to HTML).

User CSS and JS pages (see Help:User style) are interpreted as if inside a <pre> block. From MW 1.11 this also goes for sitewide CSS/JS; in earlier versions, you have to manually add /*<pre>*/ to the beginning and /*</pre>*/ to the end of those pages to avoid strange rendering.

The MediaWiki software attempts to catch HTML errors, but it does not catch all of them. If you use HTML in wikitext, it is helpful to verify it with the W3C Markup Validation Service.

The MediaWiki software adds elements that look and act like HTML tags. Parser tags are included in MediaWiki whereas extension tags are added by optional software extensions.

Parser tags

<gallery>, <nowiki>, <pre>, <source>

Extension tags

<categorytree>, <charinsert>, <hiero>, <imagemap>, <inputbox>, <math>, <poem>, <ref>, <references>, <syntaxhighlight>, <timeline>

• Wikipedia:Span tags

• HTML 4.01 specification: elements | attributes
• For customizing the handling of HTML in MediaWiki, see the HTML and Tidy sections in mw:Manual:Configuration settings
• Some extensions allow adding arbitrary HTML to a page, for example mw:Extension:AddHTML, mw:Extension:SecureHTML and mw:Extension:Secure HTML; see $wgRawHtml for a more complete list
• Within the MediaWiki codebase, these HTML checks happen in includes/Sanitizer.php