HTML decoder
Processed in your browser · nothing is uploaded
Turns HTML entities back into the characters they stand for: named ones like `&` and `—`, decimal ones like `é`, and hexadecimal ones like `é`.
How to use the html decoder
Double-encoding is the reason most people arrive here. A string that has been escaped twice shows & on the page, and decoding once gives &, which still looks wrong. The fix is decoding twice, and then finding where in the pipeline the value was escaped a second time, because the double encoding will come back tomorrow otherwise. Two escapes almost always means a template escaping a value that a framework had already escaped.
Decoding is not sanitising, and the direction matters. Turning <script> back into <script> produces working markup, so decoded output must never be inserted into a page with innerHTML. If your aim is to display it, keep it encoded; if your aim is to read it, this is the tool.
One detail: decodes to a non-breaking space (U+00A0), not an ordinary space. It looks identical and behaves differently; it will not wrap, and a string comparison against a normal space fails. That is the invisible cause of a great many "identical strings do not match" bugs.
Questions
It was encoded twice. Decode again, then find where in the pipeline the second escape happens.
Yes, both decimal (é) and hexadecimal (é).
No. Decoding turns <script> back into working markup. Keep it encoded for display.
A non-breaking space, U+00A0, which looks like a space and is not one, and will not compare equal to it.
No. Everything runs in your browser, which matters when the file holds credentials or customer data.