HTML Encoder/Decoder

The tool works in two modes that switch with a single click.

To encode HTML: Select Encode mode. Paste or type your text into the input field. Click the Encode button. Special characters that have meaning in HTML are replaced with their entity equivalents. The encoded output appears instantly in the output area, ready to copy.

To decode HTML: Select Decode mode. Paste your HTML-encoded text containing entities like < or & into the input field. Click the Decode button. The entities are converted back to their original characters.

All processing happens entirely in your browser using JavaScript. No content you enter is sent to any server.

HTML entities are special character sequences used to represent characters that either have special meaning in HTML syntax or are not easily typed on a standard keyboard. They allow characters to appear in web page content without being interpreted as HTML markup.

An HTML entity begins with an ampersand (&) and ends with a semicolon (;). Between those delimiters is either a named entity reference or a numeric character reference.

Named entity references use a predefined name for the character. For example, the ampersand character itself is represented as &. The less-than symbol is represented as <. The greater-than symbol is >. The double quotation mark is ". These named references are defined in the HTML specification and are supported by all browsers.

Numeric character references use the character's Unicode code point expressed either in decimal or hexadecimal. The decimal form is a hash symbol followed by the decimal code point number, wrapped in ampersand and semicolon. The hexadecimal form uses hash-x followed by the hexadecimal code point, wrapped the same way.

HTML entities allow any Unicode character to be represented safely in an HTML document, regardless of whether the document's character encoding supports that character directly or whether the character has special meaning in HTML syntax.

HTML encoding exists because certain characters are syntactically significant in HTML. Using them as literal characters in content creates ambiguity or outright errors that browsers handle inconsistently or insecurely.

The less-than symbol is the opening delimiter of HTML tags. If you write a literal less-than sign in a paragraph of text, the browser begins looking for a tag name. Depending on what follows, the browser may silently consume or misparse your content. The browser may display nothing, or it may display garbled content as it tries to interpret the surrounding text as markup.

The greater-than symbol is the closing delimiter of HTML tags. While browsers are often more forgiving about literal greater-than signs in text content, the HTML specification requires it to be encoded as an entity in attribute values and certain content contexts.

The ampersand is the opening character of every HTML entity. A literal ampersand in content must be encoded, otherwise the browser begins parsing what follows as an entity reference. An unencoded ampersand followed by text and a semicolon may be mistakenly interpreted as an entity, resulting in unexpected characters or content disappearing.

Double quotation marks are used to delimit HTML attribute values. A literal quotation mark inside an attribute value would terminate the attribute prematurely, breaking the HTML structure.

Single quotation marks are used as an alternative attribute delimiter. Like double quotes, they must be encoded when appearing inside an attribute value that uses them as the delimiter.

Failing to encode these characters correctly causes pages to render incorrectly. But more seriously, failing to encode user-provided content before inserting it into an HTML page is one of the most common causes of Cross-Site Scripting (XSS) vulnerabilities.

Cross-Site Scripting, commonly abbreviated as XSS, is a security vulnerability that occurs when an attacker's malicious code gets injected into a web page and executed by other users' browsers. HTML encoding is one of the primary defenses against XSS attacks.

The attack works like this: a web application takes user-supplied input and displays it back in the page without encoding it. An attacker submits input containing a script tag with malicious JavaScript. When other users view the page, their browsers parse the unencoded input as HTML, execute the script, and the attacker's code runs in the context of the victim's browser session. This can be used to steal cookies and session tokens, redirect users to malicious sites, log keystrokes, perform actions on the user's behalf, and much more.

HTML encoding prevents this attack by converting the less-than sign that opens a script tag into its entity equivalent before inserting it into the page. The browser then renders the entity as a literal less-than character in text rather than parsing the following characters as a tag name. The injected content is displayed as harmless text instead of being executed as code.

Every framework and web development language provides built-in functions for HTML encoding that should be used whenever user-supplied content is inserted into an HTML document. The key principle is: never trust user input, always encode before output.

Thetoolity's HTML encoder is useful for manually encoding content during development and testing, for understanding what encoding looks like, and for encoding snippets of content to be pasted into code samples and documentation.

Here is a complete reference of the most commonly needed HTML entities with their named forms and numeric forms.

Ampersand (&): Named entity & — decimal entity &. This must be encoded in all content and attribute values. An unencoded ampersand in HTML creates potential for misparse as an entity reference.

Less-than sign (<): Named entity &lt; — decimal entity &#60;. This must always be encoded in text content and attributes. A literal less-than starts a tag.

Greater-than sign (>): Named entity &gt; — decimal entity &#62;. Required in attribute values and recommended in text content for strict HTML compliance.

Double quotation mark ("): Named entity &quot; — decimal entity &#34;. Required when the character appears inside an attribute value delimited by double quotes.

Single quotation mark ('): Named entity &apos; (in HTML5) or numeric form in HTML4 — decimal entity &#39; — hex entity &#x27;. Required when the character appears inside an attribute value delimited by single quotes.

Non-breaking space: Named entity &nbsp; — decimal entity &#160;. Used to insert a space that will not collapse or line-break. Commonly used for visual spacing in HTML when a regular space would collapse.

Copyright symbol: Named entity &copy; — decimal entity &#169;. Used for copyright notices in web page footers and content.

Registered trademark symbol: Named entity &reg; — decimal entity &#174;. Used in brand names and product documentation.

Trademark symbol: Named entity &trade; — decimal entity &#8482;. Used in brand names and product documentation.

Euro sign: Named entity &euro; — decimal entity &#8364;. Used for prices and financial content in European contexts.

Em dash: Named entity &mdash; — decimal entity &#8212;. Used as a punctuation separator in formal writing contexts.

En dash: Named entity &ndash; — decimal entity &#8211;. Used for ranges like dates or page numbers in formal writing.

Left and right double quotation marks: Named entities &ldquo; and &rdquo;. Used for typographically correct "curly" quotation marks in published content.

Left and right single quotation marks: Named entities &lsquo; and &rsquo;. Used for typographically correct curly single quotes and apostrophes in published content.

Both named and numeric entity forms are valid HTML and both produce the same character when rendered by a browser. The choice between them comes down to readability and context.

Named entities are more readable and self-documenting. When you see &amp; in code, it is immediately clear that you are looking at an encoded ampersand. Named entities are the right choice for characters that have widely recognized named forms, particularly the five most critical ones: ampersand, less-than, greater-than, double quote, and single quote.

Named entities are defined in the HTML specification and the WHATWG HTML Living Standard. Not every Unicode character has a named entity form. Only characters for which the HTML specification defines a name can be referenced by name. Thousands of Unicode characters including most emoji, many symbols, and characters outside the common Latin, Greek, and mathematical ranges have only numeric forms.

Numeric entities work for any Unicode character, making them universally applicable. They come in two forms: decimal (using a hash followed by the decimal code point) and hexadecimal (using hash-x followed by the hexadecimal code point). Both forms are equally valid. The decimal form is more commonly used because decimal numbers are more familiar to most developers.

For security-sensitive encoding where the five markup-significant characters must be reliably escaped, both forms work. For content that includes non-ASCII characters that need to survive transmission through ASCII-only systems, numeric entities ensure every character is represented as safe ASCII characters.

Thetoolity's encoder uses the most widely recognized form for each character, preferring named entities for characters that have them.

HTML encoding, URL encoding, and Base64 encoding all transform characters or data into a different representation, but they serve different purposes and are not interchangeable.

HTML encoding replaces characters that have special meaning in HTML with entity sequences that tell browsers to display the literal character rather than interpret it as markup. It is applied to content that will be inserted into an HTML document. The encoded form uses HTML entity syntax with ampersand and semicolon delimiters.

URL encoding (also called percent encoding) replaces characters that are unsafe or have special meaning in URLs with percent signs followed by the character's hexadecimal code point. It is applied to data that will be inserted into a URL, such as query string parameters. The encoded form uses percent signs: a space becomes %20, an ampersand becomes %26.

Base64 encoding converts binary data to a text string using a 64-character alphabet. It is used to embed binary data in text-based formats like JSON, email, or HTML attributes. It encodes every byte of the input, not just special characters, and produces output that has no correspondence to the original character.

Each encoding is appropriate for its specific context. Using HTML encoding in a URL would break the URL. Using URL encoding in HTML content would show percent signs instead of the intended characters. Using Base64 where HTML encoding is needed would not prevent XSS attacks.

When dealing with data that needs to appear in multiple contexts, such as a string that will be placed in an HTML attribute value that is also a URL, multiple layers of encoding may be needed, applied in the correct order.

Every web development language and framework provides built-in functions for HTML encoding. Using these built-in functions is always preferable to building your own encoding logic, as they handle edge cases correctly and are maintained to address newly discovered vulnerabilities.

• JavaScript (browser): The DOMParser and DOM APIs can be used for encoding and decoding. For encoding, create a text node and read its textContent. For decoding, set innerHTML on a temporary element and read the textContent. Libraries like he (HTML entities) provide more comprehensive and reliable encoding.

• Node.js: The he library is the most complete and widely used HTML entities encoder and decoder for Node.js. It handles all named entities, numeric entities, and edge cases correctly. For frameworks, template engines like Handlebars, Pug, and EJS perform automatic HTML encoding by default for variables inserted into templates.

• Python: The html module in Python's standard library provides html.escape() for encoding (replaces the five critical characters) and html.unescape() for decoding. For web frameworks, Django templates automatically encode variables, and Jinja2 does the same with its autoescape feature.

• PHP: htmlspecialchars() encodes the five critical characters (ampersand, less-than, greater-than, double quote, single quote). htmlentities() encodes all characters that have named HTML entity equivalents. html_entity_decode() reverses the encoding. In PHP template systems like Blade (Laravel) and Twig, variables are automatically HTML-encoded.

• Java: The Apache Commons Text library provides StringEscapeUtils.escapeHtml4() for encoding and StringEscapeUtils.unescapeHtml4() for decoding. Spring MVC and other Java web frameworks provide automatic encoding in their template systems.

• C# and .NET: HttpUtility.HtmlEncode() and HttpUtility.HtmlDecode() in the System.Web namespace. WebUtility.HtmlEncode() and WebUtility.HtmlDecode() in System.Net. ASP.NET Razor templates automatically HTML-encode variables.

• Ruby: CGI.escapeHTML() and CGI.unescapeHTML() in the standard library. ERB templates in Rails automatically HTML-encode variables.

For quick, one-off encoding and decoding during development and content preparation, Thetoolity's browser-based tool is the fastest option.

Even experienced developers make HTML encoding mistakes. Here are the most common ones and how to prevent them.

• Double encoding happens when content is encoded twice. If a string containing the encoded form of a less-than sign is encoded again, the ampersand in the entity sequence gets encoded too, producing a corrupted entity. Always track whether content has already been encoded before encoding it again. In template systems that auto-encode, inserting pre-encoded content as a raw unescaped value is the correct approach.

• Encoding only some contexts is a common security mistake. Developers sometimes encode content when inserting it into text node positions but forget to encode it for attribute values, script blocks, URL attributes, or CSS contexts. Each HTML context has its own encoding requirements. Text content contexts, attribute value contexts, script contexts, and URL contexts all require different or additional handling.

• Using HTML encoding in URLs treats the wrong context. An href attribute pointing to a URL with user-supplied query parameters needs URL encoding for the parameter values and HTML encoding for the attribute value as a whole. Applying only HTML encoding to the URL parameter leaves it vulnerable to URL injection. Applying only URL encoding to the attribute value leaves the angle brackets and quotes unescaped.

• Trusting encoding from third-party sources is risky. Content that arrives from an API, database, or user submission and appears to already be encoded may have been encoded inconsistently or incompletely. Decoding it and re-encoding with a reliable function is safer than trusting the existing encoding.

• Relying on the browser to fix encoding errors is not a security strategy. Browsers are designed to be lenient and will often display pages with encoding errors without complaint. But lenient parsing does not mean secure parsing. Malformed entities may be exploited by attackers even when browsers appear to display the page correctly.

Thetoolity is a growing collection of free, fast, and clean online tools for developers, security engineers, content writers, and anyone who works with web content. Our HTML encoder decoder is one of many tools designed to handle essential web development tasks instantly, with no account required and no data leaving your device.

No subscriptions. No paywalls. No cluttered interfaces. Just tools that load instantly and work every time.

Explore the full collection at Thetoolity.com and find generators, converters, calculators, checkers, and testers, all free and all instant.