HTML Encoder & Decoder — Escape Special Characters

Escaping only protects one context at a time

Entity encoding converts the characters that carry structural meaning in HTML into named or numeric entities, so the browser renders them as visible text rather than parsing them as markup. This tool escapes exactly five: &, <, >, " and '.

The important thing to understand is that this is not the way to escape things — it is the way to escape one specific context. Get the context wrong and the escaping provides no protection whatsoever, while still looking like it did something.

Different contexts need different rules

• HTML text between tags — entity escaping is the correct defence, and this is the case the tool handles.
• Attribute values — also need escaping, and quoting matters: an unquoted attribute can be escaped out of with nothing more than a space, so always quote.
• Inside a script block — entity escaping does nothing at all, because the contents are parsed as JavaScript rather than HTML. Data destined for code needs JavaScript escaping, or better, should be handed over as data — a JSON block or a data attribute — instead of being interpolated into source.
• A URL in an href or src — needs URL encoding, and the scheme itself is a separate problem: javascript: is dangerous however carefully the rest is escaped, so schemes must be checked against an allowlist.
• Inside a CSS block — different rules again.

Five contexts, five answers. This is why escaping is a job for something that knows where the value is going.

This tool is a manual utility, not a security control

Real applications should escape at the point of output, using a template engine that knows the context of each insertion, and should sanitise untrusted HTML with a dedicated library such as DOMPurify that understands the full parsing behaviour of the spec.

Pasting user input through a web page by hand is not a security architecture. It cannot be applied consistently, it cannot be tested, and it is not there on the day someone adds a new field. Use this to inspect and prepare text, not to defend an application.

Decoding is the reverse, and it is the risky direction

Decoding turns escaped text back into live markup. That is the whole point of it, and also the hazard: decoding untrusted content and then inserting it into a page is precisely the shape of an injection. Decode in order to read something, not in order to publish it.

The legitimate uses are worth knowing, because they are common. Showing code samples on a page requires escaping, not decoding. Fixing double-encoded text — where an ampersand has itself been escaped, so a reader sees the entity spelled out rather than the character — is a decode job, and one of the most frequent reasons to reach for a tool like this. So is preparing content for a CMS field that does not escape on output, though that is a bug in the CMS worth fixing rather than working around.

Escaping for HTML and escaping for a URL are different rule sets, and using one where the other belongs is a common source of mangled output. The URL encoder and decoder covers the other context.