192

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 />.

Nathan Koop
  • 23,022
  • 23
  • 86
  • 121
kamens
  • 11,108
  • 5
  • 42
  • 46
  • 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 Nov 11 '08 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. – Nick Lockwood Aug 11 '11 at 06:40

13 Answers13

183

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>

Glorfindel
  • 19,729
  • 13
  • 67
  • 91
Kornel
  • 91,239
  • 30
  • 200
  • 278
  • 7
    Not correct afaik, because using self-closing versions of ` – ZeissS Jun 13 '10 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 Jun 13 '10 at 18:37
  • @porneL can you elaborate in terms of (X)HTML5? What differences should we be aware of with modern browsers that support such markup? – arxpoetica Nov 02 '10 at 13:59
  • 3
    @pornel can you gaurantee that self closing 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. – Metagrapher Mar 25 '11 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 `` will work. With the MIME type. Only. – Kornel Mar 26 '11 at 11:18
  • IE9 might 'support' it but try doing on top of a group of radio buttons and see how it FAILS!!! – capdragon Jun 10 '11 at 19:03
  • 1
    @capdragon: `` works great in IE9 — with the right MIME type. The article you quoted doesn't mention MIME type used, so I assume they (and you) need to read my answer very carefully. – Kornel Jun 11 '11 at 15:13
  • @porneL: This is not a solution because i need to support older browsers. – capdragon Jun 13 '11 at 13:30
  • 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 Aug 31 '11 at 21:09
  • 2
    To restate this... XHTML should be served as 'application/xhtml+xml', but it's completely broken in all modern browsers including IE9, because members like 'document.write' and 'document.cookie' don't exist and many scripts will break, even though the page otherwise renders fine. THEREFORE, you're better off sticking to serving content with the 'text/html' MIME type, and best sticking to HTML 5 guidelines, because the HTML 5 standard has been designed to encompass tag soup (some blend of HTML and XHTML) in a well-defined manor (as evidenced by the XHTML2 WG being merged in with HTML5). – Triynko Aug 31 '11 at 21:16
  • 2
    @SlippDouglas this is correct, please read carefully why *`DOCTYPE` is irrelevant*. It does self-close in all those browsers when you use XHTML/HTML5+XML **correctly**. – Kornel Apr 22 '12 at 23:47
  • 1
    Ahh… I see now. Thanks, @porneL. I wasn't even aware of the existence of HTML5+XML, just plain-ol HTML5. I guess this question is really outdated. – Slipp D. Thompson Apr 23 '12 at 18:41
  • 2
    This is absolutely fascinating - what's really amazing is that the w3c home page declares an xhtml doctype but text/html mime type in the header. From what you're saying I guess that's very incorrect. – Jonathan Mar 07 '13 at 21:32
  • This highly upvoted question appears to be wrong? According to the W3C spec, no elements which can contain content can be self closing in XHTML. Additionally if you self close a div it doesn't even render properly in most modern browsers (eg
    does not work). Am I missing something?
    – NickG Jan 23 '14 at 12:03
  • 1
    @NickG yes, you're missing setting right `Content-Type` HTTP header and your XHTML ends up parsed as invalid HTML. *Please* carefully read all pages I've linked to which explain exactly why it doesn't *seem* to work for you. The XHTML spec forbids/requires some elements to have content, but that is orthogonal to XML syntax it uses, and the syntactic difference completely disappears at the DOM level (if parsed in appropriate mode only configurable via XML Content-Type). – Kornel Jan 23 '14 at 13:31
  • @porneL But irrespective of what physically *works* the browser, self closing divs are not valid according to the W3C spec as they can contain content. See: http://stackoverflow.com/questions/7971716/is-it-ok-to-use-a-self-closing-div-tag So as far as I can tell, your answer is wrong as the Asker is asking what is valid - not what can be made to work. – NickG Jan 23 '14 at 13:32
  • 1
    @porneL The linked answer is still valid. XHTML does NOT permit self closing divs under any circumstances. See: http://www.w3.org/TR/xhtml-media-types/#C_2 It says "If an element permits content (e.g., the div element) but an instance of that element has no content (e.g., an empty section), DO NOT use the "minimized" tag syntax (e.g.,
    )."
    – NickG Jan 23 '14 at 13:37
  • 1
    @NickG 1. Document you've linked to is a [W3C Note](http://www.w3.org/Consortium/Process/NOTE.html), which means it **failed** to become a Recommendation. 2. It's not a spec describing what's permissible, it's merely a suggestion what do to to work around *lack of XHTML support* in old browsers. – Kornel Jan 23 '14 at 13:41
  • "All those “Valid XHTML 1.0!” links on the web are really saying “Invalid HTML 4.01!” --- That is wrong, or at least very inaccurate. See http://www.w3.org/TR/xhtml1/ XHTML 1.0 explicitly allowed serving documents as media type text/html while XHTML 1.1 enforced application/xhtml+xml so it was impossible to serve the latter to IE6 for example. – C.O. Dec 03 '15 at 16:52
41

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 ;-)

maček
  • 69,649
  • 33
  • 159
  • 193
Erik van Brakel
  • 21,732
  • 2
  • 48
  • 66
35

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.

hsivonen
  • 7,630
  • 1
  • 27
  • 34
33

From the W3 Schools reference site:

<area />
<base />
<basefont />
<br />
<hr />
<input />
<img />
<link />
<meta />
Sheridan
  • 64,785
  • 21
  • 128
  • 175
ConroyP
  • 38,904
  • 16
  • 76
  • 86
  • 7
    http://www.w3schools.com/tags/default.asp I see 12 tags ending with `/>` : `"area", "base", "basefont", "br", "col", "frame", "hr", "img", "input", "link", "meta", "param"` – mpen Oct 23 '10 at 06:37
  • 96
    Please note that W3schools is not affiliated with W3C, and even fails to respond to corrections sent by W3C members. – Kornel Nov 05 '10 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` – cayhorstmann Jan 20 '13 at 02: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. – Priidu Neemre Oct 02 '15 at 08:00
30

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

Dmitry Osinovskiy
  • 9,629
  • 1
  • 45
  • 36
10

Hope this helps someone:

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

<area />
<br />
<col />
<hr />
<img />
<input />
<param />
Jeff
  • 5,535
  • 13
  • 43
  • 72
5

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!

AmbroseChapel
  • 11,181
  • 7
  • 41
  • 65
4

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

mpen
  • 237,624
  • 230
  • 766
  • 1,119
4

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).

Shadow2531
  • 11,352
  • 5
  • 29
  • 40
4

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 />
Kevin
  • 48,059
  • 14
  • 92
  • 127
e-satis
  • 515,820
  • 103
  • 283
  • 322
2

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.

Kevin Hakanson
  • 38,937
  • 23
  • 119
  • 148
2

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!

LarsH
  • 25,732
  • 8
  • 77
  • 136
-2

<hr /> is another

Darren Kopp
  • 71,547
  • 9
  • 71
  • 90