Encoding HTML Entities: When < > & and " Must Be Escaped

Browsers do not read HTML the way you read it. To you, <div> is three letters wrapped in angle brackets. To the parser, it is a command: open a division element. That gap between "what the characters look like" and "what the browser does with them" is the entire reason HTML entities exist. When you want a character to mean itself and nothing else, you escape it.

This post walks through the four characters that almost always need escaping, the difference between named and numeric entities, and the security reason this matters more than cosmetics. If you just want to convert text right now, the HTML Entities Encoder does both directions in your browser with no upload.

The Five Characters the Parser Steals

A handful of characters carry structural meaning in HTML. Leave them raw and the browser interprets them instead of printing them:

• < opens a tag, so the browser starts reading an element name
• > closes a tag
• & begins an entity reference, so © becomes ©
• " and ' terminate attribute values inside quotes

The fix is to swap each one for its entity. So < becomes <, > becomes >, & becomes &, " becomes ", and ' becomes '. Once escaped, the parser sees a harmless reference, resolves it back to the literal glyph at render time, and paints the character on screen without ever treating it as markup. This is the one concrete fact worth memorizing: < becomes < and & becomes &; otherwise the browser parses them as the start of a tag and the start of an entity.

The ampersand is the sneaky one. Because & introduces every entity, you have to escape it first when you escape a block of text. If you replaced < with < after replacing & with &, you would be fine, but do it in the wrong order and you double-escape your own output into <. Encode the ampersand first, then the angle brackets and quotes.

Named Versus Numeric Entities

There are two ways to spell the same escape. A named entity uses a human-readable label between the ampersand and semicolon: &, <, ©, —. A numeric reference uses the character's code point instead, in decimal as & or in hexadecimal as & — both of which resolve to &.

Named entities win on readability. Anyone reviewing a diff understands < faster than <. The catch is that only a few hundred characters have official names, so for anything outside that list you fall back to numeric form. Numeric references can encode any Unicode character at all, which is why decoders accept them universally. A good encoder uses the named form where one exists and the numeric form otherwise — that is exactly what this tool does by default, escaping the five dangerous ASCII characters and letting UTF-8 text like é or an emoji pass through untouched, since modern HTML handles those directly.

One detail that trips people up: decoding is layered. If text was double-escaped, & decodes to & on the first pass, not straight to &. Each decode pass peels exactly one layer, which is deliberate — it lets you unwind precisely as many escapes as were applied.

Why This Is a Security Control, Not a Style Choice

Escaping looks like formatting housekeeping until you remember where untrusted text ends up. Cross-site scripting (XSS) is the attack where someone injects markup into a page that your server then echoes back to other users. The classic payload is a comment or username containing <script>alert(1)</script>. If your template drops that string into the page raw, the browser sees a real script tag and runs it — in your visitors' sessions, with their cookies.

Entity encoding closes the hole. Run that payload through the encoder before it reaches the page and it becomes <script>alert(1)</script>. The browser now renders the literal text <script>alert(1)</script> as inert characters. No tag opens, no script runs. Those same five characters that break your layout are the ones that open the door to injection, so escaping them is both a display fix and a defense.

A caveat worth stating plainly: entity encoding protects HTML body context. Inside an attribute like href= or an onclick= handler you also need URL or JavaScript escaping, because entity encoding alone will not stop a javascript: URL from firing. Escape at output time, in the right context, every time.

A Worked Example: Showing a Tag Literally

Say you are writing a tutorial and want readers to see the literal markup for a card component. You type it into your editor:

<div class="card">
  <a href="/home">Home</a>
</div>

Drop that into your blog's HTML as-is and it vanishes — the browser builds a real div with a real link instead of printing the code. Run it through the encoder and you get this, which you paste into the page so the tags survive:

<div class="card">
  <a href="/home">Home</a>
</div>

Now every < is <, every > is >, and every attribute quote is ". The browser decodes each reference at paint time and shows your readers the exact source they need to copy, character for character, instead of an empty rectangle where a div used to be.

How I Use It

I maintain a docs site where almost every page contains code that itself contains code. Early on I kept losing example snippets — I would paste <input type="text"> into a paragraph, publish, and find a real text box sitting in my prose. The first few times I escaped by hand, missing a bracket here, double-escaping an ampersand there, and shipping < to production more than once. Now my reflex is to encode any inline markup before it goes near the page, and to decode anything that arrives from a CMS already mangled into —. It removed an entire category of "why is this rendering wrong" from my week.

Encoding's Close Cousin

HTML entities are one of several escaping schemes you meet across the stack, each tuned to a different parser. The same character that needs < in HTML needs %3C in a URL query string, because URLs reserve their own set of structural characters. If you are wrangling query parameters or building links, the URL Encoder handles that percent-encoding the same way this tool handles entities — convert at the boundary, decode on the other side, and never let a structural character get parsed when you meant it literally.

Keep the mental model simple: a character can be data or it can be syntax, and escaping is how you tell the parser which one you mean. For HTML, that means reaching for <, >, &, ", and ' whenever raw text lands inside markup.

---

Made by Toolora · Updated 2026-06-13