HTML Entity Encoder / Decoder
HTML-encode text into HTML entities — named (©), decimal (©) or hex (©) — or decode entities back to plain text. Encode the five XSS-relevant characters & < > " ' plus all non-ASCII, or just the specials. Everything runs in your browser; nothing is uploaded.
HTML-entity encoding is context-dependent: escaping for HTML text/attribute context is the right XSS defense there, but it is not sufficient inside a <script> block, an inline event handler, a style, or a URL — those need JavaScript, CSS or URL encoding instead.
Runs entirely in your browser — nothing you paste is uploaded or sent to any server.
What this tool is
- A free, in-browser HTML entity encoder and decoder: convert text to HTML entities, or turn HTML entities back into plain text, in one tool with a direction toggle.
- Encode to named entities (&copy;), decimal numeric references (©) or hex (©) — your choice.
- Pick the scope: encode every non-ASCII character plus the five HTML specials, or just the five specials & < > " ' for minimal, readable output.
- Decoding is automatic: it resolves named, decimal and hexadecimal entities in the same pass, and leaves anything it does not recognise untouched.
- Everything runs client-side in your browser — paste a snippet from a page, a log or a suspicious email and nothing is ever sent to a server.
What HTML entities are
An HTML entity (a character reference) lets you write a character using only plain ASCII, so the browser renders it literally instead of treating it as markup. The classic case is the less-than sign: writing < in page text would start a tag, so you write < instead. Entities come in two shapes.
Named vs numeric
- Named entities. A mnemonic between
∧—&,<,©. Readable, but only a few hundred characters have a name. - Numeric references. The Unicode code point, in decimal (
©) or hexadecimal (©). Works for any character — all three spellings here decode to the same©.
The five characters that matter
Five characters are special in HTML and are the ones that turn user input into an injection if left raw: & < > " '. Which ones you must encode depends on where the value is used:
- Element text (between tags): encode
&and<at minimum;>is encoded by convention. - Double-quoted attribute: also encode the double quote
"so the value cannot break out of the quotes. - Single-quoted attribute: also encode the single quote
'. Encoding all five everywhere is the safe default.
So <a href="x"> HTML-encodes to <a href="x">, and decoding it reverses the transformation exactly.
Encoding and security (XSS)
HTML-entity encoding of untrusted data is one of the core defenses against cross-site scripting (XSS): it stops attacker-controlled text from closing a tag, opening a new one, or breaking out of an attribute. But it is context-dependent, and that is the part people get wrong.
Security note: HTML-entity encoding is the right defense only for the HTML text and attribute contexts. It is not sufficient inside a <script> block, an inline event handler such as onclick, a CSS style, or a URL (href/src) — those require JavaScript-string, CSS or URL encoding instead, and some still execute after HTML-encoding. Always encode for the exact output context, and avoid putting untrusted data into script, style or URL sinks in the first place.
Frequently asked questions
What is an HTML entity?
An HTML entity (also called a character reference) is a way of writing a character using only plain ASCII so a browser does not mistake it for markup. There are two kinds. Named entities use a mnemonic between an ampersand and a semicolon, such as & for an ampersand, < for a less-than sign, or © for the copyright symbol. Numeric character references use the character’s Unicode code point, written in decimal as © or in hexadecimal as © (both produce ©). Encoding a character as an entity tells the browser to display the character literally rather than interpret it as HTML syntax.
Which characters must I HTML-encode, and when?
Five characters are special in HTML: & (ampersand), < (less-than), > (greater-than), " (double quote) and ’ (single quote / apostrophe). Where each one must be encoded depends on the context the value lands in. In element text, & and < must be encoded (> is encoded by convention for safety). Inside a double-quoted attribute value you must also encode the double quote; inside a single-quoted attribute, the single quote. Encoding all five everywhere is the safe default. Non-ASCII characters (accents, symbols, emoji) do not strictly need encoding when the page is served as UTF-8, but encoding them guarantees they survive transports and editors that are not UTF-8-clean.
What is the difference between named and numeric entities?
They are two spellings of the same thing. A named entity like © is readable but only works for characters that have a defined name — there are a few hundred. A numeric character reference works for any Unicode code point: decimal © or hexadecimal ©. Hex is common because it matches the U+00A9 notation used in the Unicode standard. All three forms decode to exactly the same character. This tool lets you encode to named (falling back to numeric where no name exists) or force numeric in decimal or hex, and it decodes all three forms automatically.
Is HTML-encoding enough to stop XSS (cross-site scripting)?
Only in the right context. HTML-entity encoding is the correct defense when untrusted data is inserted into HTML element text or into a quoted attribute value — it stops the data from breaking out and becoming markup or a new tag. But it is context-dependent and is NOT sufficient everywhere. Data placed inside a <script> block, an inline event handler (onclick=...), a style attribute, or a URL (href/src) needs JavaScript-string, CSS or URL encoding respectively; HTML-entity encoding there can still execute or be bypassed. The rule of thumb: encode for the exact context the value is used in, and prefer not to put untrusted data into dangerous sinks (script/style/URL) at all.
Does anything I paste get sent to a server?
No. All encoding and decoding happens in your browser with local JavaScript — there is no network request, no upload and no logging. That makes it safe to paste a snippet from an internal page, an application log, or a suspicious phishing email and inspect how it decodes, without the content ever leaving your machine.