HTML Encoder & Decoder - Free Online HTML Entity Converter

An HTML encoder/decoder is a utility that converts text between two forms: raw characters and HTML entities. HTML encoding (also called HTML escaping) takes special characters such as <, >, &, ", and ' and replaces them with entity references like <, >, and & so browsers display them as literal text instead of interpreting them as markup. HTML decoding reverses the process, converting entity references back into their original characters.

This free online HTML entity encoder and decoder handles both directions instantly, with a live preview so you can see the converted output as you type. It supports the core reserved characters required for safe HTML output, plus a large set of named entities for copyright, currency, and mathematical symbols. Everything runs client-side in your browser, so nothing you paste is uploaded or stored on a server.

Developers reach for an HTML character encoder whenever they need to safely display user-generated content, embed code snippets in a blog post or documentation page, sanitize form input, or debug why a page is rendering raw tags instead of formatted text. It is one of the most commonly used developer utilities, alongside a JSON formatter, a Base64 encoder, or a URL encoder/decoder.

HTML encoding is not just a display convenience - it is a core web security practice. Characters like < and > define HTML tags, and & introduces entity references. When an application inserts untrusted, unencoded user input directly into a page, a browser can interpret that input as real markup or executable script rather than plain text. This is the root cause of Cross-Site Scripting (XSS), one of the most common web application vulnerabilities.

Consider a comment form that accepts the string <script>alert('XSS')</script>. If that string is rendered on the page without encoding, the browser executes it as JavaScript for every visitor who views the comment - potentially stealing session cookies, logging keystrokes, or redirecting users to a phishing page. Encoding the same string first turns it into <script>alert('XSS')</script>, which the browser displays as harmless, readable text instead of running it.

At minimum, encode these five characters before inserting any untrusted text into HTML: &, <, >, ", and '. Quotes matter as much as angle brackets - if user input is placed inside an HTML attribute (for example <div title="...">), an unescaped quote character lets an attacker break out of the attribute and inject new attributes or event handlers such as onerror or onclick.

It is worth noting that HTML encoding alone is not a complete defense for every context. Encoding is context-sensitive: text inserted into an HTML body needs HTML entity encoding, text inserted into a JavaScript string needs JavaScript escaping, and text inserted into a URL needs URL encoding. Applications that intentionally allow user-submitted HTML (rich text editors, for example) need a maintained HTML sanitization library on top of encoding, not encoding alone. And decoding does not make content "safe" - an encoded tag can become a live tag again once decoded, so decoded output should never be inserted back into the DOM as raw HTML without further sanitization.

HTML entities come in two formats: named references like ©, which are easier to read in source code, and numeric references like © or © (decimal and hexadecimal respectively), which work even when a named entity is not supported. Below are the characters developers encode most often.

Beyond these, this tool also handles a wide set of mathematical and set-theory symbols (∑, ∞, √, ≤, ≥, ∈, ⊂, and more), which are frequently needed in scientific documentation, LaTeX-to-HTML conversion, and technical publishing.

HTML supports three ways to reference the same character:

• Named character references - human-readable mnemonics such as & or ©. These are easy to read in source code but only work for the fixed set of names the HTML spec defines.
• Decimal numeric references - written as &# followed by a Unicode code point in base 10, for example © for the copyright symbol.
• Hexadecimal numeric references - written as &#x followed by a code point in hex, for example ©, also representing the copyright symbol.

Numeric references can represent any Unicode code point, which makes them useful when a character has no named entity, or when generating output programmatically is simpler with a single numeric formula rather than a lookup table of names. Named references are generally preferred for readability in hand-written markup and templates.

While this tool is convenient for one-off conversions, most applications need to encode and decode programmatically. Here is how to do it in the languages developers ask about most.

JavaScript

function htmlEncode(str) {
  const entities = { '&': '&amp;', '<': '&lt;', '>': '&gt;', '"': '&quot;', "'": '&#39;' };
  return str.replace(/[&<>"']/g, (char) => entities[char]);
}

function htmlDecode(str) {
  const el = document.createElement('textarea');
  el.innerHTML = str;
  return el.value;
}

PHP

$encoded = htmlspecialchars($text, ENT_QUOTES, 'UTF-8');
$decoded = htmlspecialchars_decode($encoded, ENT_QUOTES);

// For the full named-entity table instead of just the core five:
$encoded = htmlentities($text, ENT_QUOTES, 'UTF-8');
$decoded = html_entity_decode($encoded, ENT_QUOTES, 'UTF-8');

Python

import html

encoded = html.escape("<script>alert('XSS')</script>")
decoded = html.unescape(encoded)

React / JSX

// React escapes text content by default - this is already safe:
const element = <div>{userInput}</div>;

// This bypasses escaping and can reintroduce XSS - avoid untrusted input here:
const dangerous = <div dangerouslySetInnerHTML={{ __html: userHtml }} />;

A frequent mistake is double encoding - running an already-encoded string through the encoder a second time, which turns & into & and breaks the original text. If you are not sure whether a string has already been encoded, decode it first, then encode once from the clean, decoded form.

It is easy to confuse HTML encoding with other encoding schemes developers use daily, but each solves a different problem:

• HTML entity encoding makes text safe to place inside HTML markup by escaping characters that have structural meaning to the HTML parser (<, >, &, quotes).
• URL encoding (percent-encoding) makes text safe to place inside a URL by converting reserved and non-ASCII characters into %XX sequences, for example a space becomes %20.
• Base64 encoding converts binary or text data into an ASCII-safe string for transport (email attachments, embedding images as data URIs, API tokens) and is not related to HTML markup safety at all.

Using the wrong one in the wrong place is a common source of bugs - URL-encoding text that is going into an HTML attribute, or HTML-encoding text that is going into a query string, will not produce correct results.

• Instant live preview as you type, with a 300ms debounce for smooth typing
• Two-way conversion: encode text to entities, or decode entities back to text
• Supports the five core reserved HTML characters plus 150+ named symbol and math entities
• One-click copy to clipboard for the converted output
• Distraction-free fullscreen mode for reviewing long output
• Resizable split-panel layout on desktop so you can widen input or output as needed
• Runs entirely client-side in your browser - no data is uploaded or logged
• No sign-up, no rate limits, completely free to use

Encoding and decoding both run as plain JavaScript string operations directly in your browser tab. There is no server round-trip involved in the conversion itself, which means this tool is safe to use on sensitive markup, internal templates, or anything you would not want logged on a remote server.

• No text is uploaded or transmitted for the encode/decode operation
• Your last input is saved only in your own browser's local storage, purely so you don't lose it on refresh
• No account, sign-up, or tracking required to use the tool
• No usage limits, no watermarking, and no rate limiting on conversions

What is the difference between HTML encoding and HTML escaping?

They refer to the same process. "HTML escaping" and "HTML entity encoding" are used interchangeably to describe converting reserved characters into entity references.

Does HTML encoding fully prevent XSS attacks?

Encoding the five reserved characters prevents the most common injection vector when inserting untrusted text into an HTML body or attribute. It is not a complete security solution on its own - context-specific escaping (for JavaScript, CSS, and URLs), a Content Security Policy, and server-side input validation should all be part of a defense-in-depth approach.

Why does my text show & instead of &?

This is double encoding - the text was already encoded once, and then encoded again. Decode the string back to plain text first, then encode it a single time from that clean version.

Can I decode HTML entities that appear as numbers, like ©?

Yes. Decimal references (©) and hexadecimal references (©) both represent Unicode code points and decode back to the same character as the named entity.

Is this HTML entity converter free to use?

Yes, this tool is completely free with no sign-up, no usage limits, and no watermarking on the output. Conversion happens locally in your browser.

Does this tool store or upload the text I enter?

No. Encoding and decoding both run in your browser using JavaScript. Your input is only saved locally in your own browser's storage (so you do not lose it on refresh) and is never sent to a server.