When any `mj-selector` element is present, `<br>` elements are sometimes compiled to `<br></br>`

[emma-k-alexandra]

Describe the bug
<br> is getting compiled to different things based on if an mj-selector element is present in the MJML. It does not seem to matter if the mj-selector actually selects the block the <br> is in.

To Reproduce
Case 1: Example without mj-selector: https://mjml.io/try-it-live/To2DOPgd8

In this example,

...
<mj-text css-class="custom">
  <p>
    Hello World!<br>
  </p>
</mj-text>
...

is compiled to

...
<p> Hello World!<br>
</p>
...

Case 2: Example with mj-selector, <br> is compiled to <br></br>: https://mjml.io/try-it-live/vjWLQhb0L

In this example,

...
<mj-text css-class="custom">
  <p>
    Hello World!<br>
  </p>
</mj-text>
...

is compiled to

...
<p> Hello World!<br>
  </br></p>
...

Note that the path of the mj-selector does not actually select the mj-text the <br> is in.

Case 3: Example with mj-selector but <br> is compiled to <br />: https://mjml.io/try-it-live/mjLo-DtRrc

In this example, the <br> is not placed in a <p>.

...
<mj-text css-class="custom">
  Hello World!<br>
</mj-text>
...

is compiled to

...
Hello World!<br />
...

Again, the path of the mj-selector does not actually select the mj-text the <br> is in.

Expected behavior
Adding an mj-selector should not change what <br> is compiled to.

MJML environment (please complete the following information):

• MJML Version 5.3.0
• MJML tool used Try it Live

[iRyusa]

Not really a bug due to the lib parsing the html as an XML document and it doesn't know how to skip html's self closing tag like br/img/... In your exemple the class isn't applied just because the selector is targetting a whatever class instead of the "custom" you use on your mj-text. Replacing custom to whatever actually put the selector in place. I think without a cheerio equivalent that support actual html5 document it's not fixable from our side ?

…

On Thu, Jun 25, 2026 at 11:19 PM Emma K Alexandra ***@***.***> wrote: *emma-k-alexandra* created an issue (mjmlio/mjml#3112) <#3112> *Describe the bug* <br> is getting compiled to different things based on if an mj-selector element is present in the MJML. It does not seem to matter if the mj-selector actually selects the block the <br> is in. *To Reproduce* Case 1: Example without mj-selector: https://mjml.io/try-it-live/To2DOPgd8 In this example, ...<mj-text css-class="custom"> <p> Hello World!<br> </p></mj-text> ... is compiled to ...<p> Hello World!<br></p> ... Case 2: Example with mj-selector, <br> is compiled to <br></br>: https://mjml.io/try-it-live/vjWLQhb0L In this example, ...<mj-text css-class="custom"> <p> Hello World!<br> </p></mj-text> ... is compiled to ...<p> Hello World!<br> </br></p> ... Note that the path of the mj-selector does not actually select the mj-text the <br> is in. Case 3: Example with mj-selector but <br> is compiled to <br />: https://mjml.io/try-it-live/mjLo-DtRrc In this example, the <br> is not placed in a <p>. ...<mj-text css-class="custom"> Hello World!<br></mj-text> ... is compiled to ... Hello World!<br /> ... Again, the path of the mj-selector does not actually select the mj-text the <br> is in. *Expected behavior* Adding an mj-selector should not change what <br> is compiled to. *MJML environment (please complete the following information):* - MJML Version 5.3.0 - MJML tool used Try it Live — Reply to this email directly, view it on GitHub <#3112?email_source=notifications&email_token=AAELHTNUVANSKBZATK3VSH35BWJOBA5CNFSL4Z3JMQ5C6L3HNF2C22DVMIXUS43TOVSS6NBXGQ3TINZVGI4DFJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAELHTPOQJTRVYRVZOVABYL5BWJOBAVCNFSNUABEKJSXA33TNF2G64TZHM2TANJYGY4DIMB3JFZXG5LFHM2DONBXGQ3TKMRYGKQXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AAELHTLNMLL6JV6EO2C5DR35BWJOBA5CNFSL4Z3JMQ5C6L3HNF2C22DVMIXUS43TOVSS6NBXGQ3TINZVGI4DFJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/AAELHTOYW2ZPGBO5ZTI3LYL5BWJOBA5CNFSL4Z3JMQ5C6L3HNF2C22DVMIXUS43TOVSS6NBXGQ3TINZVGI4DFJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[emma-k-alexandra]

Yeah, I'm not expecting the mj-selector to actually apply the attribute in those examples. It's just to show that the mj-selector element being present at all is enough to trigger this issue.

My current workaround is to replace all <br> elements with <br/> before compiling with MJML. This seems to yield consistent HTML.

[iRyusa]

My bad I've totally misread it about the attribute being applied 👍
Yeah that would be the only workaround for now, there's a similar issue if you produce invalid HTML the parser goes crazy and alter the HTML in a unrecoverable state 😕