ToolBoxOnline
Developer

HTML Entities Special Characters Guide How to Encode & < > and © So They Display Correctly Across Every Browser Email and Platform

You typed an ampersand in your HTML. It broke the page. You typed a copyright symbol in your email. It showed as ?. HTML entities prevent these failures — here's when and how to use them.

HTML entitiesspecial charactersencodingampersandcross-platform

You write a blog post that mentions "AT&T." The page breaks because the browser interprets & as the start of an HTML entity and tries to parse the rest of the text as one. You write a privacy policy that includes the copyright symbol ©. It looks fine in your browser but shows as a garbled character in Outlook 2016 and as a blank square on an older Android phone. You write a tutorial that includes <div> in a code example. The browser renders an actual div instead of displaying the text.

Special characters are the most common source of cross-platform rendering failures — and the fix is HTML entities. A HTML entities converter encodes characters into their safe, universal representations. Here is which characters need encoding and why.

The Three Characters You Must Always Encode

Ampersand (& → &amp;): The ampersand is the escape character in HTML. It signals the start of an entity. If you want to display a literal ampersand — in "AT&T," "Procter & Gamble," "Simon & Schuster" — you must encode it. An unencoded ampersand in HTML is a syntax error. Browsers are forgiving and often recover, but email clients and older browsers are not. Always encode ampersands in any text that will be rendered as HTML.

Less than (< → &lt;): The less-than sign starts an HTML tag. If you write <div> in a blog post about HTML, the browser sees a tag, not text. Encode it as &lt;div&gt; to display the literal characters. This is especially important in code tutorials, documentation, and any content that includes HTML or XML examples.

Greater than (> → &gt;): The greater-than sign ends an HTML tag. It is less dangerous than < (browsers handle unencoded > better) but it should still be encoded for consistency and safety. In practice, always encode both < and > together.

Characters That Need Encoding in Specific Contexts

Quotes in attributes: If your HTML attribute value contains a double quote, encode it as &quot;. Otherwise the quote terminates the attribute early. <img alt="He said &quot;hello&quot;"> — the encoded quotes are part of the alt text, not the end of the attribute.

Non-breaking space: &nbsp; creates a space that prevents line breaks. Use it to keep words together: Dr.&nbsp;Smith ensures "Dr." and "Smith" never split across lines. Overusing &nbsp; for layout (instead of CSS margins/padding) is a classic beginner mistake — it is a content character, not a layout tool.

Copyright, trademark, and special symbols: © → &copy;, ® → &reg;, ™ → &trade;, € → &euro;, £ → &pound;, ¥ → &yen;. These symbols have named entities that are easier to remember than numeric codes. Named entities work in all browsers and email clients, while the raw Unicode characters sometimes fail in older systems.

HTML Entities in Email: The Strictest Rendering Environment

Email clients are the most hostile rendering environment for special characters. Outlook uses Word's HTML rendering engine (not a browser engine), which has incomplete Unicode support. Some Android email clients use stripped-down renderers that lack entire character ranges. The solution: encode all non-ASCII characters as HTML entities in email HTML. The copyright symbol, the em dash, the curly quotes from a word processor — encode them all. It makes the HTML source uglier but ensures the rendered email looks correct everywhere.

Use the HTML entities converter to encode and decode any text. Paste your content, see the encoded version, and copy the safe representation that renders correctly on every platform.

Tools mentioned in this article

Compartir esta herramienta