HTML Entities Decoder

Decode them once, then stop the layer that put them there. Content saved through an old editor, an importer or a form with PHP magic quotes ends up with ' and & sitting in the table itself, so every page renders the entity as visible text no matter what the template does. The repair is a one-off UPDATE with REPLACE over the affected column (take a dump first), or in WordPress the search-and-replace step of a migration plugin. Before you run it, find out which code path escapes on save, because a cleaned column refills within days if the writer is still escaping. Decode a few sample rows here first to see how many layers you are dealing with.

Remove the tags with a parser, then decode the entities, in that order. Reversing the two lets an encoded <script> turn into a real tag after the tag removal has already run, which is a classic filter bypass. In Python: BeautifulSoup(html, "html.parser").get_text() handles both steps correctly. In PHP: html_entity_decode(strip_tags($s), ENT_QUOTES, "UTF-8"). In JavaScript, parse with DOMParser and read textContent instead of writing your own regex, because a regex over tags fails on attributes containing angle brackets, on comments and on unclosed elements. Expect to normalise whitespace afterwards, since block tags leave nothing where a line break used to be.

It is double-escaped text: & is itself the entity for &, so one decoding round produces ä and only the second round produces ä. It happens when text passes through two escaping layers, typically a template engine that auto-escapes plus application code that escaped the value already. Turn on --repeat here to see the final text, but treat it as a bug report rather than a fix, because the extra layer is corrupting other characters too.

The reliable one-liner uses the browser's own parser through a detached element: const ta = document.createElement("textarea"); ta.innerHTML = str; return ta.value. A textarea is important, because its content model is plain text, so tags in the input cannot become elements. Never use innerHTML on a div for this, and never use eval-style tricks. On the server, use a library (he in Node.js, html.unescape in Python) rather than a regex over a hand-written table.

Because the ampersand was escaped a second time, so the browser sees ä and correctly renders the text ä. The cause is nearly always double escaping in the output chain: a template that auto-escapes receiving a value that was already escaped. The fix is to remove one of the two escaping steps, not to decode the text before storing it, which just moves the problem into the database.

They should have one, and in XML they must. HTML5 tolerates a set of legacy entities without it, so &copy renders as © in a browser, which is why you sometimes see a copyright symbol appear in the middle of a URL containing "copy". That tolerance is limited to about a hundred historical names; a numeric reference without a semicolon is a parse error in some contexts. Always write the semicolon.

Different alphabets for different destinations. HTML entities (&, é) protect characters from the HTML parser and appear in markup. Percent encoding (%26, %C3%A9) protects characters from the URL parser and appears in addresses. They are not interchangeable, and a value that travels through both needs both, applied in the right order: percent-encode for the URL, then HTML-escape the resulting attribute value.

The decoded text can absolutely contain <script> or an onerror attribute, because decoding is exactly the step that turns harmless text back into markup. This page never renders it, but your application must not either. If you decode entities server-side and then write the result into a page, you have removed your own protection. Decode for reading and processing; escape again at output.

&#8217; is the right single quotation mark (U+2019), the typographic apostrophe that word processors and CMS editors substitute automatically. It is a different character from the ASCII apostrophe ', and code that compares strings or matches on ' will not find it. When cleaning imported text, decoding the entity is only half the job: you often also want to normalise the curly quotes to straight ones before the data hits a search index.

&nbsp; is a non-breaking space (U+00A0). WYSIWYG editors emit it to preserve consecutive spaces and to prevent line breaks, so pasted content from Word or an older CMS is often full of them. After decoding here they become invisible U+00A0 characters that look like normal spaces but do not match a \s+ split in some regex flavours and break trimming. When cleaning such text, replace them explicitly rather than trusting a visual check.