Text & code / MULTIVERTO
Decode HTML entities such as &, < and numeric character references back to readable text.
Apply each text tool to the previous result.
01 / Guide
The decoder resolves character references to their Unicode characters. The output is plain text, not rendered HTML.
Decoded output is shown as text. If you later insert it into a webpage as markup, it may contain tags and needs separate safety checks.
02 / Example
<p class="greeting">Hello & welcome</p><p class="greeting">Hello & welcome</p>03 / Guide
Use this direction when a copied string contains references such as &, < or a numeric reference and you need the underlying readable characters. A sequence representing an ampersand becomes an ampersand; a sequence representing a less-than sign becomes that character in the output. The converter presents the decoded result as plain text. This is useful when inspecting logs, exported content or a message that has been escaped for display, because the references can obscure the intended punctuation.
The output is not a promise that the text is safe to treat as markup. For example, decoding a reference for an opening bracket may reveal a tag-shaped sequence. Inserting the result later with innerHTML could give that sequence HTML meaning, whereas assigning textContent keeps it as text. Some references are named and others numeric, and browser parsing rules can be nuanced. When exact round-trip behavior matters, compare the original bytes and the destination parser instead of assuming every double-escaped string needs only one decoding pass.
HTML reserves characters such as the ampersand and angle brackets for markup. Character references let a document represent those characters as data: for example, an ampersand can be written as &, while a less-than sign can be written as <. Browsers interpret references when parsing HTML. Named references and numeric references are both possible, but a reference is only meaningful in the context in which an HTML parser consumes it. Seeing entity-like text in a plain text file does not mean the file itself has been rendered as HTML.
The distinction between text content and executable markup matters. Showing user-supplied text safely inside a page is different from inserting a trusted fragment of HTML. Likewise, an HTML text node, an attribute, a URL attribute, a CSS rule and a JavaScript string have different escaping requirements. Entity conversion is a useful representation step, not a complete security policy or sanitizer. Keep untrusted input out of dangerous contexts, and use the templating or DOM APIs appropriate to the place where the value will be inserted.
Begin with a value that is actually written in the expected representation. Paste one encoded component or byte sequence, then compare the readable output with the surrounding record that supplied it. The decoder runs in this browser and does not upload the string to a conversion service. If the input is damaged or uses another format, it may fail or remain partly unchanged, depending on the operation. Preserve the original encoded value so that you can identify whether a surprising character came from the source or from your interpretation.
Treat the decoded text as new, potentially untrusted input. A readable sentence can still contain markup, a URL, a command-like string or private information that needs separate handling. Do not insert it into an executable context just because decoding succeeded. If the output seems wrong, verify the declared character encoding and ask whether an earlier system encoded the value more than once. Repeating a decode without understanding the layers can turn a literal separator into structural punctuation or create a result that was never intended by the sender.