195

What are all the valid self-closing elements (e.g. <br/>) in XHTML (as implemented by the major browsers)?

I know that XHTML technically allows any element to be self-closed, but I'm looking for a list of those elements supported by all major browsers. See http://dusan.fora.si/blog/self-closing-tags for examples of some problems caused by self-closing elements such as <div />.

2
  • 7
    Doesn't this default the one of the purposes of XHTML? I thought one of the advantages of XHTML was that you could use an XML generator to generate HTML. Why would any XML generator be aware of what tags are allowed to be self-closing? Too weird.
    – Elijah
    Commented Nov 11, 2008 at 23:24
  • 6
    The reason that the "lame", "incorrect" answer was accepted is because it answered the question that kamens was obviously asking. He wanted to know which elements could be self-closed when serving XHTML as text/html without causing rendering issues in browsers. A lot of pages are written in XHTML and served as text/html even though it's technically incorrect. The question could be improved with this clarification, but answering a different question (what happens when you serve as application/xml, or whether singular tags in text/html should have a closing /) isn't helpful in this instance. Commented Aug 11, 2011 at 6:40

13 Answers 13

186

Every browser that supports XHTML (Firefox, Opera, Safari, IE9) supports self-closing syntax on every element.

<div/>, <script/>, <br></br> all should work just fine. If they don't, then you have HTML with inappropriately added XHTML DOCTYPE.

DOCTYPE does not change how document is interpreted. Only MIME type does.

W3C decision about ignoring DOCTYPE:

The HTML WG has discussed this issue: the intention was to allow old (HTML-only) browsers to accept XHTML 1.0 documents by following the guidelines, and serving them as text/html. Therefore, documents served as text/html should be treated as HTML and not as XHTML.

It's a very common pitfall, because W3C Validator largely ignores that rule, but browsers follow it religiously. Read Understanding HTML, XML and XHTML from WebKit blog:

In fact, the vast majority of supposedly XHTML documents on the internet are served as text/html. Which means they are not XHTML at all, but actually invalid HTML that’s getting by on the error handling of HTML parsers. All those “Valid XHTML 1.0!” links on the web are really saying “Invalid HTML 4.01!”.


To test whether you have real XHTML or invalid HTML with XHTML's DOCTYPE, put this in your document:

<span style="color:green"><span style="color:red"/> 
 If it's red, it's HTML. Green is XHTML.
</span>

It validates, and in real XHTML it works perfectly (see: 1 vs 2). If you can't believe your eyes (or don't know how to set MIME types), open your page via XHTML proxy.

Another way to check is view source in Firefox. It will highlight slashes in red when they're invalid.

In HTML5/XHTML5 this hasn't changed, and the distinction is even clearer, because you don't even have additional DOCTYPE. Content-Type is the king.


For the record, the XHTML spec allows any element to be self-closing by making XHTML an XML application: [emphasis mine]

Empty-element tags may be used for any element which has no content, whether or not it is declared using the keyword EMPTY.

It's also explicitly shown in the XHTML spec:

Empty elements must either have an end tag or the start tag must end with />. For instance, <br/> or <hr></hr>

20
  • 7
    Not correct afaik, because using self-closing versions of <script> or <div> results in different rendering/interpretation.
    – ZeissS
    Commented Jun 13, 2010 at 12:18
  • 14
    @ZeissS only in text/html. In real XHTML, sent as application/xhtml+xml it's works just fine. Please read article I linked to (or XHTML spec Appendix C) before downvoting.
    – Kornel
    Commented Jun 13, 2010 at 18:37
  • 3
    @pornel can you gaurantee that self closing <script /> tags will work in older browsers? I don't think so. You sound authoritative, and most of your information is accurate, but experience tells me that self closing script tags will be problematic and it's best to just avoid them entirely rather than give yourself a headache. Commented Mar 25, 2011 at 16:44
  • 6
    @Metagrapher if older browsers don't support real XHTML, OR you fail to set the MIME type, then it won't work. However, in XHTML-supporting browsers (all major ones at this point) with application/xhtml+xml MIME type I can guarantee that <script/> will work. With the MIME type. Only.
    – Kornel
    Commented Mar 26, 2011 at 11:18
  • 4
    @capdragon: Older browsers don't support XHTML (served as 'application/xhtml+xml'). If you send them an XHTML document as 'text/html', then the XHTML gets rendered as tag soup (i.e. the browser parses it as HTML and considers self-closing tags errors, which it gracefully recovers from). Your options are 1. write HTML 4 (not exactly an option if using ASP.NET which renders XHTML), 2. serve your XHTML as 'application/xhtml+xml' (requires IE9+, and this MIME type will break scripts in all browsers anyway, so def not an option), 3. write HTML 5, which basically makes tag soup the standard :)
    – Triynko
    Commented Aug 31, 2011 at 21:09
42

One element to be very careful with on this topic is the <script> element. If you have an external source file, it WILL cause problems when you self close it. Try it:

<!-- this will not consistently work in all browsers! -->
<script type="text/javascript" src="external.js" />

This will work in Firefox, but breaks in IE6 at least. I know, because I ran into this when over-zealously self closing every element I saw ;-)

5
  • Affects all versions of MSIE: webbugtrack.blogspot.com/2007/08/…
    – scunliffe
    Commented Oct 1, 2008 at 20:59
  • 4
    <script> doesn’t self-close in Firefox 3.
    – hsivonen
    Commented Nov 12, 2008 at 8:11
  • Well, it used to work in Firefox when I encountered it. Seems like it doesn't work in any browser anymore. Could also only work in quirks mode perhaps? Commented Nov 15, 2009 at 18:59
  • 1
    @erickson it works fine in Firefox if you will get your MIME type right.
    – Kornel
    Commented Jun 13, 2010 at 19:00
  • WebKit continue to do it for compatiblity reasons.
    – Yuhong Bao
    Commented May 31, 2011 at 8:10
37

The self-closing syntax works on all elements in application/xhtml+xml. It isn’t supported on any element in text/html, but the elements that are “empty” in HTML4 or “void” in HTML5 don’t take an end tag anyway, so if you put a slash on those it appears as though the self-closing syntax were supported.

0
35

From the W3 Schools reference site:

<area />
<base />
<basefont />
<br />
<hr />
<input />
<img />
<link />
<meta />
4
  • 7
    w3schools.com/tags/default.asp I see 12 tags ending with /> : "area", "base", "basefont", "br", "col", "frame", "hr", "img", "input", "link", "meta", "param"
    – mpen
    Commented Oct 23, 2010 at 6:37
  • 96
    Please note that W3schools is not affiliated with W3C, and even fails to respond to corrections sent by W3C members.
    – Kornel
    Commented Nov 5, 2010 at 10:02
  • 2
    As so often, w3schools is almost right. An accurate way to find the empty elements is to run grep EMPTY xhtml1-strict.dtd | sort or grep EMPTY xhtml1-transitional.dtd | sort Commented Jan 20, 2013 at 2:00
  • 2
    IMHO, people bash W3Schools way too hard. It's proved itself to be a great resource for when you're GETTING STARTED(!) on a topic you know nothing about. Commented Oct 2, 2015 at 8:00
33

Better question would be: what tags can be self-closed even in HTML mode without affecting code? Answer: only those that have empty content (are void). According to HTML specs the following elements are void:

area, base, br, col, embed, hr, img, input, keygen, link, menuitem, meta, param, source, track, wbr

Older version of specification also listed command. Besides, according to various sources the following obsolete or non-standard tags are void:

basefont, bgsound, frame, isindex

0
12

Hope this helps someone:

<base />
<basefont />
<frame />
<link />
<meta />

<area />
<br />
<col />
<hr />
<img />
<input />
<param />
7

What about <meta> and <link>? Why aren't they on that list?

Quick rule of thumb, do not self-close any element which is intended to have content, because it will definitely cause browser problems sooner or later.

The ones which are naturally self-closing, like <br> and <img>, should be obvious. The ones which aren't ... just don't self-close them!

7

They're called "void" elements in HTML 5. They're listed in the official W3 spec.

A void element is an element whose content model never allows it to have contents under any circumstances.

As of April 2013, they are:

area, base, br, col, command, embed, hr, img, input, keygen, link, meta, param, source, track, wbr

As of December 2018 (HTML 5.2), they are:

area, base, br, col, embed, hr, img, input, link, meta, param, source, track, wbr

6

The last time I checked, the following were the empty/void elements listed in HTML5.

Valid for authors: area, base, br, col, command, embed, eventsource, hr, img, input, link, meta, param, source

Invalid for authors: basefont, bgsound, frame, spacer, wbr

Besides the few that are new in HTML5, that should give you an idea of ones that might be supported when serving XHTML as text/html. (Just test them by examining the DOM produced.)

As for XHTML served as application/xhtml+xml (which makes it XML), XML rules apply and any element can be empty (even though the XHTML DTD can't express this).

6

You should have a look the xHTML DTDs, they're all listed. Here is a quick review all the main ones:

<br />
<hr />
<img />
<input />
1
  • 1
    Fixed and cleaned up markup. Carefull with links in this pages, they are slow to load.
    – Bite code
    Commented Sep 22, 2011 at 13:36
3

Another self closing tag problem for IE is the title element. When IE (just tried it in IE7) sees this, it presents the user a blank page. However you "view source" and everything is there.

<title/>

I originally saw this when my XSLT generated the self closing tag.

1
  • Chromium doesn't like <title/> tags either.
    – uınbɐɥs
    Commented Sep 24, 2012 at 1:23
3

I'm not going to try to overelaborate on this, especially since the majority of pages that I write are either generated or the tag does have content. The only two that have ever given me trouble when making them self-closing are:

<title/>

For this, I have simply resorted to always giving it a separate closing tag, since once it's up there in the <head></head> it doesn't really make your code any messier to work with anyway.

<script/>

This is the big one that I very recently ran into problems with. For years I had always used self-closing <script/> tags when the script is coming from an external source. But I very recently started recieving JavaScript error messages about a null form. After several days of research, I found that the problem was (supposedly) that the browser was never getting to the <form> tag because it didn't realize this was the end of the <script/> tag. So when I made it into separate <script></script> tags, everything worked. Why different in different pages I made on the same browser, I don't know, but it was a big relief to find the solution!

0
-3

<hr /> is another

Not the answer you're looking for? Browse other questions tagged or ask your own question.