Free Free Tool

HTML Entity Encoder / Decoder

Encode HTML special characters (< > & " ') or decode them back to plain text.

Free · no sign-up
Instant results
Privacy-friendly

Direction

Scope

Input

Output

Other Developer Tools

JSON Formatter JSON → XML XML → JSON CSV → JSON JSON → CSV Base64 HTML Entities Markdown → HTML UUID Generator JWT Decoder Slug Generator HTML Live Editor Python Compiler C Compiler

Why escaping exists

A browser cannot tell the difference between a < that begins a tag and a < you meant as a literal character. Escaping resolves that ambiguity: the character is replaced by an entity — < for <, > for >, & for &, " for a double quote, ' for an apostrophe — which the browser renders as the original symbol without ever treating it as markup.

This is why escaping is the foundation of preventing cross-site scripting. If user-supplied text containing a script tag is escaped before it reaches the page, the browser displays the words rather than executing them. Nearly every XSS vulnerability is a place where that step was skipped or undone.

Choosing a scope

Special characters only converts the five that carry meaning in HTML and leaves everything else untouched. This is almost always the right choice. Accented letters, CJK text, and emoji stay as readable UTF-8, which keeps your output legible and your file size down — and on any page correctly served as UTF-8, they render perfectly.

All applicable characters additionally converts every character with a named entity, so é becomes é and — becomes —. Reach for this only when output has to survive a pipeline you do not control: a legacy system that mangles non-ASCII, an email template of uncertain encoding, or a database column that is not UTF-8. It produces significantly larger output for no benefit on a modern, correctly configured page.

Escape at output, not at input

The most common architectural mistake is escaping data as it is saved. Store what the user actually typed and escape at the moment you render it. Escaping on the way in corrupts your data for every other consumer — an API response, a CSV export, a plain-text email, a search index — all of which now contain &quot; where a quote should be, and none of which want HTML entities.

It also causes double-encoding, the most familiar symptom of getting this wrong. Escape once and & becomes &. Escape the result again and it becomes &amp;, which renders on the page as the literal text &. If you are seeing &amp; or &quot; in your output, something in the chain is escaping data that was already escaped. Use the decode direction here to confirm how many layers deep it goes.

Context matters more than the escape itself

HTML escaping protects HTML body content. It is not sufficient — and sometimes not correct — elsewhere. Text going into a JavaScript string needs JavaScript escaping; a value going into a URL needs percent-encoding; a value in a CSS context needs CSS escaping. Applying HTML escaping to a URL parameter and calling it safe is a genuine and common vulnerability.

Unquoted HTML attributes deserve particular caution. Inside an unquoted attribute an attacker can break out with a space alone, without needing any of the five escaped characters. Always quote attribute values, and escape what goes inside them.

Frequently asked questions

Which characters actually need escaping in HTML? #

Five carry structural meaning: < and > which delimit tags, & which begins an entity, and the double and single quotes which terminate attribute values. Escaping those five is what the "special chars only" mode does and it covers standard HTML output.

Why is my page showing &amp; instead of &? #

Double-encoding — something escaped text that had already been escaped. Most often the data was escaped when it was saved and escaped again when rendered. Store raw text and escape only at output. Use decode here to see how many layers were applied.

Should I escape data before saving it to the database? #

No. Store what the user typed and escape when you render. Escaping on save corrupts the value for every non-HTML consumer — APIs, CSV exports, plain-text email, search indexing — and is the usual root cause of double-encoding.

Does escaping make my site safe from XSS? #

It is necessary but not sufficient on its own. HTML escaping protects HTML body context. Values placed into JavaScript, URLs, or CSS need the escaping appropriate to those contexts, and attributes must always be quoted — inside an unquoted attribute a space alone is enough to break out.

When should I use "all applicable characters"? #

Only when output must pass through a system whose encoding you do not control — a legacy platform, an uncertain email pipeline, or a non-UTF-8 column. On a correctly served UTF-8 page it just makes the output much larger and harder to read.

Is ' the same as '? #

They render identically in HTML5, but ' is the safer choice because the numeric reference is universally supported, while ' was not valid in HTML 4 and can still trip up older parsers and some XML tooling.