HTML Encoder & Decoder
Encode HTML special characters to named or numeric entities and decode HTML entities back online. Prevents XSS by escaping <, >, &, ", and ' — no signup required.
Common HTML Entities Reference
| Character | Named Entity | Numeric Entity | Description |
|---|---|---|---|
| & | & | & | Ampersand |
| < | < | < | Less than |
| > | > | > | Greater than |
| " | " | " | Double quote |
| ' | ' | ' | Single quote |
| |   | Non-breaking space | |
| © | © | © | Copyright |
| ® | ® | ® | Registered |
| ™ | ™ | ™ | Trademark |
| € | € | € | Euro |
| £ | £ | £ | Pound |
| — | — | — | Em dash |
| – | – | – | En dash |
| « | « | « | Left guillemet |
| » | » | » | Right guillemet |
About the HTML Encoder & Decoder
The DevToolHeaven HTML Encoder converts HTML special characters to their entity equivalents, making it safe to display HTML code as visible text in web pages, emails, and documentation. The decoder reverses the process, converting HTML entity sequences back to their original characters.
The five HTML reserved characters that must always be encoded are: & (ampersand → &), < (less-than → <), > (greater-than → >), " (double quote → "), and ' (apostrophe → '). These characters have structural meaning in HTML — appearing unencoded in content causes rendering errors or security vulnerabilities.
Choose between named entities (&, <) for readability, or numeric entities (&, <) for maximum compatibility across email clients and older parsers. Both are valid HTML5. Numeric entities can represent any Unicode character, while named entities only cover a defined set.
HTML encoding is a critical security control. Cross-site scripting (XSS) attacks inject malicious script tags or event handlers through unencoded user input — encoding converts < and > to their entity forms, so injected tags display as harmless text rather than executing as code. Most modern templating engines auto-escape by default, but understanding manual encoding is essential for edge cases.
Common use cases include: displaying code snippets on web pages without triggering HTML parsing, escaping user-generated content before storing it in HTML emails, encoding HTML for embedding in JSON or XML APIs, and safely rendering database content in web templates.
All processing is 100% client-side. Your content is never sent to any server, making this tool suitable for encoding sensitive HTML content from internal applications or proprietary systems.
Frequently Asked Questions
HTML entities are special codes used to represent characters that have special meaning in HTML or cannot be typed directly. For example, < and > are used in HTML tags, so to display them as text you must write < and > instead.
You need HTML encoding whenever you display user-generated content in a web page, embed HTML code inside another HTML page, write HTML in emails, or store HTML in a database or JSON. Without encoding, characters like < and & can break your page layout or create security vulnerabilities.
Named entities use descriptive names like & for & and < for <. Numeric entities use the character's Unicode code point — either decimal like & or hexadecimal like &. Both are valid HTML. Named entities are more readable while numeric entities work for any Unicode character.
Cross-site scripting (XSS) is a security attack where malicious JavaScript is injected into a web page through user input. HTML encoding prevents XSS by converting < to < and > to >, so injected script tags are displayed as text rather than executed as code.
You must always encode &, <, >, and " in HTML content. Encoding ' is recommended in attributes. Other characters like letters, numbers, and most punctuation are safe as-is. The entity is commonly used for non-breaking spaces in formatted content.
Yes. Switch to Decode mode and paste your HTML-encoded text. The decoder handles both named entities like & and numeric entities like & and &. It supports all standard HTML5 named entities and any valid numeric entity.
HTML encoding makes characters safe for display inside HTML documents — it converts < to <, & to &, etc. URL encoding makes characters safe for inclusion in URLs — it converts spaces to %20, & to %26, etc. They solve different problems: use HTML encoding for web page content and URL encoding for URL parameters.
Yes. Most modern web frameworks and templating engines — React, Vue, Angular, Django, Jinja2, Handlebars, Razor — auto-escape user content by default. Raw HTML insertion (like dangerouslySetInnerHTML in React or |safe in Jinja2) bypasses auto-escaping and must be used only with trusted, already-sanitized content. When in doubt, use this tool to verify your encoding.
React automatically HTML-encodes values rendered in JSX — {userInput} is safe without any manual encoding. The only case requiring care is dangerouslySetInnerHTML={{ __html: userInput }}, which bypasses encoding entirely. If you must use dangerouslySetInnerHTML with user content, sanitize it first with a library like DOMPurify.
Paste your string here and copy the encoded output. In email templates, always encode user-provided data — especially names, subjects, and body content. Email clients render HTML and are vulnerable to injection if special characters like < and & are not encoded. Most email libraries provide escaping functions, but this tool is useful for manual testing.
& is the named HTML entity for the & character. & is the decimal numeric entity for the same character (38 is the ASCII code for &). & is the hexadecimal numeric entity. All three produce the same result in a browser. Named entities are more readable; numeric entities work for any Unicode character even if it lacks a named form.
Yes, when the attribute is wrapped in single quotes: <input value='it\'s here'> — encode the apostrophe as ' or '. When using double quotes for attributes, apostrophes are safe without encoding. Best practice is to always use double quotes for HTML attributes, which makes apostrophes inside values safe and only requires encoding of double quotes.