HTML Entity Encoder/Decoder

XSS (Cross-Site Scripting) injects malicious scripts into pages. Without encoding: user input <script>alert("XSS")</script> executes as code. With encoding: <script>alert("XSS")</script> displays as text. Attack vectors: form inputs, URL parameters, cookies, database content. Defense layers: (1) Encode output (HTML entities), (2) Validate input (whitelist), (3) Content Security Policy headers, (4) HttpOnly cookies. Encoding alone not sufficient: use comprehensive XSS prevention, sanitize HTML if allowing markup, use frameworks that auto-encode (React, Vue). This tool helps encode untrusted content before rendering.

HTML encoding: for HTML content, encodes <>&"' to entities, used in HTML body/attributes, prevents HTML interpretation. URL encoding (percent encoding): for URLs, encodes space as %20 or +, special chars as %XX hex, used in query strings/paths, prevents URL parsing issues. Different contexts need different encoding: HTML entity: < for <, URL encoding: %3C for <. Don't mix: URL-encoded in HTML looks wrong (%20 displays as %20). When to use: HTML encoding in page content, URL encoding in hrefs/src attributes, both in JavaScript strings. This tool does HTML entity encoding; use separate tool for URL encoding.

Required in attribute values: double quote becomes " if using double-quoted attributes, single quote becomes ' if using single-quoted attributes, < becomes < (less common but safe), & becomes & (always). Example:

Unicode characters can be: (1) Used directly if UTF-8 charset: <meta charset="UTF-8">, no encoding needed. (2) HTML entities: é for é (named), é for é (decimal), é for é (hex). Modern approach: use UTF-8 directly, it's simpler and more readable. Encode entities only for: HTML special chars (<>&"), control characters, invisible chars, compatibility with non-UTF-8 systems. Emoji: use directly in UTF-8 or numeric entities 😀 😀. Right-to-left text: use proper HTML markup (dir="rtl"), not entities. This tool preserves Unicode by default, encodes only HTML special characters.

Encoding: converts special chars to entities, displays everything as text, no HTML tags work, safest for untrusted content, example: <b> → <b>. Sanitizing: allows some HTML, removes dangerous tags/attributes, permits formatting (<b>, <i>, <p>), blocks scripts (<script>, onclick), more complex. Use encoding when: displaying plain text, user input shown as-is, no formatting needed, maximum security. Use sanitizing when: allowing rich text editors, blog comments with formatting, markdown converted to HTML. Libraries: DOMPurify, sanitize-html for sanitizing. Never trust user HTML: always sanitize or encode. This tool does encoding (safest); use sanitizing libraries for rich text.

JavaScript: no built-in HTML encode. Manual: text.replace(/</g, "&lt;").replace(/>/g, "&gt;"). Libraries: DOMPurify, he, lodash escape. DOM method: textContent auto-encodes (safe), innerHTML doesn't (unsafe). Python: html.escape(text) built-in, or markupsafe.escape(). PHP: htmlspecialchars($text) or htmlentities($text). Java: StringEscapeUtils.escapeHtml4() (Apache Commons). Ruby: ERB::Util.html_escape() or CGI.escapeHTML(). C#: HttpUtility.HtmlEncode() or WebUtility.HtmlEncode(). Server-side encoding preferred: do before sending to browser. This tool for quick manual encoding and testing; use language built-ins in production code.

Double encoding: encoding already-encoded text, < becomes <, displays as < not <. Fix: decode first, then encode. Wrong context: HTML encoding in JavaScript strings, needs JSON escaping too. Incomplete encoding: missing quotes or ampersands, still vulnerable. Over-encoding: encoding Unicode unnecessarily, makes text unreadable. Not encoding: forgetting to encode user input, XSS vulnerability. Encoding at wrong time: too early (breaks processing), too late (already executed). Inconsistent encoding: some fields encoded, others not. Testing: verify with XSS payloads: <script>alert(1)</script>, " onclick="...". This tool helps test encoding correctness before deploying.