How to Encode HTML Entities Online for Free (2026 Guide)

Try pasting <div>Hello</div> into a blog post and you'll see the problem: the browser interprets <div> as an actual HTML tag instead of displaying it as text. The fix is HTML encoding — converting special characters into entities like < that browsers display literally. Bloggers, CMS users, email-template builders, and developers all need it constantly. This guide shows you how to encode and decode HTML entities with our free HTML Encoder, gives you a handy reference table, and explains the honest security boundaries of encoding.

What are HTML entities?

An HTML entity is a text sequence that represents a single character, written as &name; (named) or &#number; (numeric). When a browser sees < in page source, it renders a literal < character instead of starting a tag. The five characters that matter most:

• < → < (less-than — would otherwise start a tag)
• > → > (greater-than — would otherwise end a tag)
• & → & (ampersand — would otherwise start an entity)
• " → " (double quote — would otherwise end an attribute value)
• ' → ' (single quote — same concern in single-quoted attributes)

Encode the ampersand first (or let a tool handle ordering) — otherwise you'd double-encode the entities you just created.

Step 1: Open the HTML Encoder

Open our HTML Encoder in any browser. No signup, no installation. You'll see an input area, encode/decode buttons, and an output area.

Step 2: Encode your code or text

1. Paste the snippet you want to display — for example: <p class="note">Tom & Jerry</p>.
2. Click Encode.
3. The output shows the entity-encoded version, safe to paste into any HTML page, blog editor, or CMS that accepts raw HTML.
4. Copy the result with the copy button.

When you view the page containing the encoded snippet, visitors see the code exactly as you wrote it — tags, quotes, and all — instead of the browser trying to render it.

Step 3: Decode entities back to characters

1. Paste entity-encoded text (like something copied from a page's source view).
2. Click Decode.
3. The original characters are restored.

Decoding is handy when you've inherited encoded content — from a database export, an old CMS, or scraped HTML — and need the clean original back.

When do you need HTML encoding?

• Code snippets in articles: tutorials showing HTML, or even text containing < > &, break without encoding.
• CMS and blog content: pasting code into WordPress-style editors or static-site markdown often requires encoded entities to survive rendering.
• Email templates: HTML emails with literal code samples or special characters need entities to display consistently across mail clients.
• Displaying user input: showing text a user typed (comments, form previews) without encoding lets their <script> become your page's script — the classic stored-XSS setup.
• Attribute values: quotes inside attribute values must be encoded or the attribute (and potentially the markup) breaks.

Quick entity reference table

• < — < · > — > · & — &
• " — " · ' — ' ·   — non-breaking space
• © — © · ® — ® · ™ — ™
• – — – · — — — · … — …
• € — € · £ — £ · ° — °

Named entities cover the common cases; numeric entities (< for <, for instance) can represent any Unicode character.

The honest security picture

HTML-encoding user content before displaying it is a genuine, important defense against cross-site scripting (XSS) — it's how comments stay comments instead of becoming executable code. But keep the boundaries straight:

• Encoding is context-dependent. HTML-encoding protects text placed into HTML body content. It does not make the same string safe inside a <script> block, a CSS context, or a URL — each context needs its own encoding (URL encoding for URLs, for example).
• Encoding is one layer, not a complete strategy. Serious applications combine output encoding with input validation, Content-Security-Policy headers (see our Security Headers Checker), and framework-provided auto-escaping.
• Encoding ≠ encryption or hiding. Entities are trivially reversible — don't use them to conceal secrets.

Mistakes to avoid

• Double encoding: encoding < again produces <, which displays literally as "&lt;" instead of "<". If your page shows entity names as text, something was encoded twice.
• Encoding the ampersand last: always encode & first (tools do this automatically); doing it last corrupts the entities you just created.
• Forgetting quotes in attributes: < and > get all the attention, but an unencoded quote inside an attribute value is what breaks markup — and enables injection.

Frequently asked questions

Is the HTML encoder private?

Yes — encoding and decoding run entirely in your browser. Nothing you paste is uploaded anywhere.

What's the difference between named and numeric entities?

Named entities (<) are readable mnemonics for common characters; numeric entities (< or <) address characters by Unicode code point and can represent anything. Browsers treat them identically.

Do I still need encoding if my framework auto-escapes?

Modern frameworks (React, Vue, Django templates) escape by default in most contexts — which is great. You still need manual encoding for raw HTML insertion points, email templates, static content, and anywhere you bypass the framework's escaping.

Can encoded text contain a virus or hack?

Encoded text is inert — it's just characters. The danger was always in the unencoded version being interpreted as code. That's precisely what encoding prevents.

Try it now: Free HTML Encoder · Free URL Encoder · Free Base64 Encoder