I don't know if this is exactly a feature or bug, but to me looks like a bug.
When any HTML entity is inserted in a template to render, like < -> < it get's rendered as part of the HTML and is not displayed as part of the text. The problem if that if you are sending an email where the user name is entered by the and the user put something like <b>username</b> this leads to HTML injection it does not matter if the the items gets escaped before.
Example:
<mjml>
<mj-body>
<mj-container>
<mj-section>
<mj-column>
<mj-image width="100" src="/assets/img/logo-small.png"></mj-image>
<mj-divider border-color="#F45E43"></mj-divider>
<mj-text font-size="20px" color="#F45E43" font-family="helvetica">Hello <b>bold</b> World</mj-text>
</mj-column>
</mj-section>
</mj-container>
</mj-body>
</mjml>

Hi @edelvalle, there is indeed an issue with the way special characters are parsed and replaced, sorry for that. It's a known issue, so I'm closing this one.
It's something we're working to fix in MJML 4.
Hey all,
I just ran into this issue and was able to find a nice work-around. If we know that our mjml is effectively being parsed twice, then we just need to get two steps behind the actual characters we want.
For < this can be accomplished by using &lt; the first pass will convert & into an actual & and then the second pass will convert < into our < symbol.
The same methodology can be followed for the rest of the symbols you are having an issue with parsing.

Most helpful comment
Hey all,
I just ran into this issue and was able to find a nice work-around. If we know that our mjml is effectively being parsed twice, then we just need to get two steps behind the actual characters we want.
For
<this can be accomplished by using&lt;the first pass will convert&into an actual&and then the second pass will convert<into our<symbol.The same methodology can be followed for the rest of the symbols you are having an issue with parsing.