Which characters actually need encoding?

Five: the ampersand, both angle brackets and both quote marks. The ampersand must be encoded first, otherwise encoding the others would produce entities that are themselves re-encoded.

Does this protect against XSS?

For text placed in element content, yes. For attributes, URLs, script blocks and style blocks, it is insufficient — each needs different escaping. Use your framework's context-aware output escaping rather than escaping by hand.

When should I encode non-ASCII characters?

Only when the document is not served as UTF-8, or when a system in the path mangles them. Modern pages declare UTF-8 and can carry accented letters and emoji directly, so encoding them adds size for nothing.

Named entities or numeric ones?

Named entities read better and are the conventional choice for the five reserved characters. Numeric references work for every codepoint, including the ones with no name, which is why the non-ASCII option uses them.

HTML Entity Encode

Escape &, <, > and quotes so markup renders as text.

Everything runs inside your browser. Your files never leave your device.

Input

Result

The result appears here as you type.

Ask about HTML Entity Encode

Questions about what this tool does, which option to pick, or what it can and cannot handle.

The question you type here is sent to an AI provider to be answered — your files and whatever you put in the tool above are not, and the assistant cannot see them. Answers are generated and can be wrong. The tool itself is not guessing: it runs deterministic code on your device.

About the HTML Entity Encode

HTML has five characters that cannot be written literally in content, because the browser reads them as markup. The angle brackets open and close tags, the ampersand starts an entity, and the quotes end attribute values. Encoding replaces each with a named entity so it is displayed rather than interpreted.

This encodes text for safe insertion into HTML, with an option to escape every non-ASCII character as a numeric reference for contexts that cannot carry UTF-8 — some email templates and older systems still need that.

The reason this matters is cross-site scripting, and it is worth being precise about the boundary. Inserting untrusted text into a page without encoding it lets that text become markup, and a string containing a script tag becomes a running script. Encoding the five characters prevents it in element content, which is the common case.

That is where the honest limit begins, and it is the part most explanations skip. Encoding is context-dependent. Text going into an unquoted attribute needs more escaping than these five characters provide, because a space or a slash can end the attribute. Text going into a script block needs JavaScript escaping, not HTML escaping. Text going into a URL attribute needs the scheme validated, because "javascript:" is a valid URL and encoding does nothing to it. Text inside a style attribute has its own rules again.

So this tool is right for the ordinary case and for understanding what encoding does. In application code, use your framework's context-aware escaping — React, Vue, Django, Rails and every other modern framework escape by default and are careful about the contexts this page cannot know about. Hand-rolled escaping is where XSS bugs come from.

How to use it

1Paste the text that needs to appear literally in an HTML page.
2Choose whether to encode only the five reserved characters or every non-ASCII character too.
3Copy the encoded result into your markup.
4In application code, prefer your framework's own escaping — it knows which context the value is going into and this page does not.

Questions

Which characters actually need encoding?: Five: the ampersand, both angle brackets and both quote marks. The ampersand must be encoded first, otherwise encoding the others would produce entities that are themselves re-encoded.
Does this protect against XSS?: For text placed in element content, yes. For attributes, URLs, script blocks and style blocks, it is insufficient — each needs different escaping. Use your framework's context-aware output escaping rather than escaping by hand.
When should I encode non-ASCII characters?: Only when the document is not served as UTF-8, or when a system in the path mangles them. Modern pages declare UTF-8 and can carry accented letters and emoji directly, so encoding them adds size for nothing.
Named entities or numeric ones?: Named entities read better and are the conventional choice for the five reserved characters. Numeric references work for every codepoint, including the ones with no name, which is why the non-ASCII option uses them.