Home/ Questions/Q 8271441
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-08T06:50:42+00:00

Apparently, if you have a </p> end tag with no matching start tag within

  • 0

Apparently, if you have a </p> end tag with no matching start tag within the body element, most if not all browsers will generate an empty paragraph in its place:

<!DOCTYPE html>
<title></title>
<body>
</p>
</body>

Even if any text exists around the end tag, none of it is made part of this p element — it will always be empty and the text nodes will always exist on their own:

<!DOCTYPE html>
<title></title>
<body>
some text</p>more text
</body>

If the above contents of body are wrapped in <p> and </p> tags… I’ll leave you to guess what happens:

<!DOCTYPE html>
<title></title>
<body>
<p>some text</p>more text</p>
</body>

Interestingly, if the </p> tag is not preceded by a <body> or </body> tag, all browsers except IE9 and older will not generate an empty paragraph (IE ≤ 9 on the other hand will always create one, while IE10 and later behave the same as all other browsers):

<!DOCTYPE html>
<title></title>
</p>

<!DOCTYPE html>
<title></title>
</p><body>

<!DOCTYPE html>
<title></title>
</p></body>

I can’t find any references stipulating that an end tag with no corresponding start tag should generate an empty element, but that shouldn’t come across as surprising considering that it’s not even valid HTML in the first place. Indeed, I’ve only found browsers to do this with the p element (and to some extent the br element as well!), but not any explanation as to why.

It is rather consistent across browsers using both traditional HTML parsers and HTML5 parsers, though, applying both in quirks mode and in standards mode. So, it’s probably fair to deduce that this is for backward compatibility with early specifications or legacy behavior.

In fact, I did find this comment on an answer to a somewhat related question, which basically confirms it:

The reason why <p> tags are valid unclosed is that originally <p> was defined as a “new paragraph” marker, rather than p being a container element. Equivalent to <br> being a “new line” marker. You can see so defined in this document from 1992:http://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/Tags.html and this one from 1993: http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt Because there were web pages pre-dating the change and browser parsers have always been as backward compatible as possible with existing web content, it’s always stayed possible to use <p> that way.

But it doesn’t quite explain why parsers treat an explicit </p> end tag (with the slash) as simply… a tag, and generate an empty element in the DOM. Is this part of some parser error handling convention from way back when the syntax wasn’t as strictly defined as it was more recently or something? If so, is it documented anywhere at all?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    That it is required is documented in HTML5. See http://w3c.github.io/html/syntax.html#the-in-body-insertion-mode and search down for An end tag whose tag name is "p" and it says:

    If the stack of open elements does not have an element in button scope
    with the same tag name as that of the token, then this is a parse
    error; act as if a start tag with the tag name “p” had been seen, then
    reprocess the current token.

    Which translated into English means create a p element if the </p> tag can’t be matched with an existing <p> tag.

    Why it is so, is harder to ascertain. Usually, this is because some browser in the past caused this to happen as a bug, and web pages came to rely on the behaviour, so other browsers had to implement it too.

    • 0