HTML Entities Encoder

Escape the angle brackets and the ampersand, then wrap the result in pre and code. Once <div> is written as &lt;div&gt;, the browser prints the characters instead of building an element, and pre keeps your line breaks and indentation. The ampersand has to be escaped as well, otherwise a snippet containing &copy; renders as ©. Syntax highlighters expect the same thing: escaped text in the source, highlighted markup added on top. Anything that ends up inside innerHTML unescaped is not just a display problem, it is the standard route for stored XSS.

An HTML entity is a way to write a character using only ASCII: &amp; for &, &lt; for <, &auml; for ä. It exists so that characters with structural meaning in HTML can appear as text, and so documents in ASCII-only encodings can still contain any Unicode character. Entities come in three forms: named (&copy;), decimal numeric (&#169;) and hexadecimal numeric (&#xA9;), all producing the same character.

Five, and the list is short enough to memorise: & becomes &amp;, < becomes &lt;, > becomes &gt;, " becomes &quot; and ' becomes &#39;. The ampersand has to be first, otherwise you double-escape your own output. In element text, & and < are strictly required; inside an attribute value, the quote character that delimits the attribute is required as well. Escaping all five everywhere is simpler and never wrong.

It prevents the most common form of it, injection into HTML text or attribute values, but only when the escaping matches the context. Text inside a <script> block, a style attribute, or a URL in href needs different treatment: JavaScript string escaping, CSS escaping, or URL validation. The rule that holds up is to escape at the point of output, in the encoding that the destination context requires, and to use a template engine that does it automatically.

Only their origin. &quot; is a named entity for the double quote and has existed since HTML 2.0; the single quote (apostrophe) has the named entity &apos;, but that name was only added in HTML5 and older Internet Explorer versions do not understand it. The numeric reference &#39; works everywhere, which is why most escaping libraries emit it instead. This tool does the same.

Not for correctness, as long as your page declares UTF-8 via <meta charset="utf-8"> and the file is actually saved as UTF-8. Then ä, é and € can appear as plain characters. Entities remain useful in three situations: content that travels through systems with unclear encoding (email templates, legacy CMS fields), files that must stay pure ASCII, and characters that are invisible or ambiguous in an editor, like a non-breaking space, where &nbsp; documents the intent.

The page is UTF-8 but the browser reads it as Latin-1, or a Latin-1 file is being served as UTF-8. This is a charset declaration problem, not an entity problem, and escaping the characters is a workaround rather than a fix. Check that the file is saved as UTF-8, that <meta charset="utf-8"> is present in the first kilobyte of the document, and that the Content-Type header agrees with it. The header wins over the meta tag when they disagree.

JavaScript has no built-in escape function; the common approach is a replace chain over the five characters, or letting the DOM do it via element.textContent = value, which never interprets markup. Python: html.escape(s, quote=True). PHP: htmlspecialchars($s, ENT_QUOTES | ENT_SUBSTITUTE, "UTF-8"), where the ENT_QUOTES flag matters because the default leaves single quotes untouched. In templates, prefer the engine's auto-escaping over manual calls.

Something escaped an already escaped string. Each pass turns the & of an existing entity into &amp;, so &lt; becomes &amp;lt; and the reader sees the entity spelled out instead of the character. It happens when a template engine auto-escapes a value that the application layer escaped first, or when data is escaped on the way into the database and again on the way out. Fix it by escaping exactly once, at the point of output, and store raw text everywhere else. Stripping the extra layer with a decoder repairs the display but leaves the double-escaping in place for the next record.

When displaying it. Store the raw text the user typed and escape at the point of output, because that is the only place where you know the destination, HTML text, an attribute, a JSON response, a CSV export or a plain-text email. Escaping on input corrupts the data for every consumer that is not a web page, breaks search and sorting, and produces the double-escaped output above as soon as the template escapes it again. Validate on input, escape on output is the rule that holds. Rejecting or sanitising markup on input is a separate decision and only makes sense when the field is genuinely allowed to contain HTML.

A non-breaking space (&nbsp;, U+00A0) renders as a space but prevents a line break at that position, and consecutive ones are not collapsed the way normal spaces are. Legitimate uses: keeping a number with its unit ("5 kg"), a name with its title, or a value with its currency symbol. Using it for layout spacing is a habit from the table-layout era; CSS margins and padding do that job without polluting the text content, which also matters for anyone copying the text out.