Why do I need to encode characters like < and & for HTML?
Browsers parse < as the start of a tag. To display a literal < as text instead of markup, it must be encoded as <.
Encode HTML special characters or decode entities back into text.
Your markup is processed locally in the browser. Nothing is uploaded or stored. Decoding recognizes the complete WHATWG named-entity table (2,032 entities), so any standard name converts correctly — not just the common ones.
Browsers parse < as the start of a tag. To display a literal < as text instead of markup, it must be encoded as <.
Named entities use descriptive names (&, ©) — this converter recognizes and decodes the full WHATWG set of 2,032 standard names. Numeric entities (&, ©) use a character code instead and work for any character, including the handful without a standard name.
When Format is set to Named, a character without a standard entity name — many emoji and less-common symbols fall into this group — automatically falls back to a numeric reference instead. The output is still valid HTML; that character just has no name to use.
No — HTML entity encoding protects characters inside HTML markup; URL encoding protects characters inside a URL. Use the URL Encoder for the latter.
It's one layer of defense — encoding user input before displaying it in HTML prevents that input from being interpreted as executable markup or script.
Yes — encoding iterates by Unicode code point, not UTF-16 code unit, so multi-byte characters like emoji stay intact rather than being split. Set Scope to Non-ASCII to encode every non-ASCII character, or leave it on the default to encode only <, >, &, ", and '.
No — encoding and decoding run entirely in your browser.