Difference Between <br> and <br/> Tag in HTML

Introduction

Suppose you want your webpage to show the below message with the same format, How will you write it in HTML?

If you are planning to use carriage return (ENTER key) to produce line breaks, then let me tell you that it won’t work because HTML will ignore any carriage return and extra spaces.

You can use the br tag which is used to produce line breaks in HTML and here are the two possible ways of using br tag.

Snippet 1:

<div>
Hello <br>
Welcome to <br>
the blog<br>
</div>

Snippet 2:

<div>
Hello <br/>
Welcome to <br/>
the blog <br/>
</div>

Both will give the same output, but what is the difference between br and br/?

But before that let’s look at some pointers.

• br tag is used to produce line breaks in an HTML document and it is a self-closing tag.
• When a tag is used with nothing between it, then a self-closing tag (or empty tag) can be used. br is one such self closing tag, which means there is no need of closing tag ( /br) while using br.
• Generally, TAG/ (not to be confused with /TAG) is used as a condensed way of writing TAG.../TAG.

So from the above pointers, it is evident that br and br/ will provide the same results when used in HTML.

But, whenever we are using XHTML (which is more strict than HTML), it doesn’t allow leaving tags open (like you cannot write just br, you have to close it also but /br doesn't make sense since it is a self-closing tag ), hence br/ will be used in that case.

Also using br is less effective when it comes to code neatness and readability than br/. Hence br/ is generally preferred over br

To sum up, the key differences between br and br/ in HTML can be understood with the help of the following table:

Difference between br and br/ Tag

Browser Compatibility

Let’s look at its browser compatibility now

Desktop Browsers

Conclusion

Both br and br/ produces the same result i.e line break. But br/ is preferred because it can be used with strict rules as well(like while writing XHTML document) and the latter looks cleaner and readable.

Read more about other self-closing tags on Scaler topics.

Author: Rdiddhi Suteri

Comments

[Mike Talbot ⭐]

Most people now use HTML5 rather than XHTML (which was initially the proposed derivative of HTML4). W3C does not recommend using XHTML serialization for most authors (ref)

[peerreynders]

TL:DNR: The HTML standard perspective is:

Self-closing tags don't exist in HTML.

Also using <br> is less effective when it comes to code neatness and readability than <br/>. Hence <br/> is generally preferred over <br>.

That's an opinion (OK when expressed as such).

The living HTML standard talks about the br element and only uses the <br> version.

What it does mention: "Content Model: Nothing"

When an element's content model is nothing, the element must contain no Text nodes (other than inter-element whitespace) and no element nodes.

The standard further defines the concept of void elements

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

All of these are "Content Model: Nothing"

Under parse errors (non-void-html-element-start-tag-with-trailing-solidus) we can find:

"The trailing U+002F (/) in a start tag name can be used only in foreign content to specify self-closing tags. (Self-closing tags don't exist in HTML.) It is also allowed for void elements, but doesn't have any effect in this case."

So the "trailing solidus" isn't an HTML feature but is merely tolerated on void elements.

So the "trailing solidus preference" comes from

• wishing that HTML was more like XML (it isn't)
• not wanting to remember which elements are void elements but instead desiring an explicit reminder when a tag doesn't support children.

[david palmer]

So, maybe best to use HTML standard for HTML processing, and convert to XML standard (
) as necessary for integration?

[peerreynders]

It's one thing to go XML -> HTML (e.g. via XSLT). As the output isn't XML there is no reason to use self-closing tags (as they don't exist in HTML).

HTML -> XML is in many cases a lost cause unless one is prepared to apply Postel's law in bulk - in many cases HTML source isn't even "valid" HTML (example Alpine.js site).

HTML and XML have very different parsing philosophies.

XML parsing:

• Is it well formed?
• Is it valid with reference to the identified schema?

HTML parsing on the other hand is very forgiving, usually resulting in a "best effort parse" in line with the web's philosophy of resilience and robustness. Given "content is the foundation, markup is an enhancement" it rather show a little bit of "garbage" to the user than hold back any content. That way an error may affect only part of a page while the rest renders as intended.

This robustness also creates some breathing room for innovation - a legacy browser may not know what to do with a web component but that won't affect the parts of the page that are implemented by more traditional means.

The fact that HTML will accept void elements as self-closing tags despite the fact that self-closing tags don't exist in HTML is a testament to its alignment with the "robustness principle" (while XML doesn't tolerate deviations).

So while XHTML seemed like a good idea on the surface its conformance requirement ultimately would have left the web more fragile ("less robust") in terms of encouraging experimentation/innovation and denying users access to all content even in the face of the most insignificant of errors.