HTML Entity Encoder & Decoder
Paste text → Encode or Decode → Copy result. Prevent XSS, display HTML safely.
Common HTML entities with named, numeric, and hex codes
How to encode/decode HTML entities in popular languages
Click to load an example into the input
What is HTML Entity Encoding?
HTML entity encoding is the process of converting special characters in HTML into their corresponding reference codes, ensuring they are displayed correctly on a web page instead of being interpreted as HTML syntax by the browser. For example, the character < is converted to < so the browser displays a less-than sign rather than starting a new HTML tag.
This is a fundamental technique in web development, critically important for preventing Cross-Site Scripting (XSS) attacks — one of the most common security vulnerabilities on the web. When user-supplied data is displayed directly without encoding, attackers can inject malicious JavaScript that steals session cookies, user data, or redirects visitors to phishing pages. The OWASP Top 10 consistently ranks injection attacks among the most dangerous web security risks.
How HTML Encoding Works
The HTML encoding process is straightforward: each special character is replaced with an “entity reference” that starts with & and ends with ;. There are three types of entities:
- Named entities: Use human-readable names, e.g.,
&for &,<for <,©for ©. Easy to read and remember, but not every character has a named entity. - Numeric entities (decimal): Use the Unicode code point as a number, e.g.,
&for &,©for ©. Works for any Unicode character and provides excellent XML compatibility. - Hex entities: Similar to numeric but use hexadecimal notation, e.g.,
&for &,©for ©. Convenient when working with Unicode code points directly.
Five characters must always be encoded in HTML content: & (ampersand), < (less than), > (greater than), " (double quote), and ' (single quote / apostrophe). If these characters appear unencoded, the browser will treat them as part of the HTML structure, causing display errors or creating security vulnerabilities.
Named vs Numeric vs Hex Entities
| Type | Syntax | Example | Pros / Cons |
|---|---|---|---|
| Named | &name; | & © | Readable, memorable. Not all characters have names |
| Numeric | &#number; | & © | Works with any Unicode character. Good XML support |
| Hex | &#xHEX; | & © | Like numeric, convenient with Unicode code points |
Best practice: Use named entities for the five core characters (& < > " ') because they are most readable. Use numeric or hex entities for other special characters, or when XML compatibility is required. Modern HTML5 supports over 2,000 named entities covering mathematical symbols, arrows, currency signs, and more.
Common Mistakes and XSS Prevention
Cross-Site Scripting (XSS) occurs when a web application displays user input without proper encoding. An attacker could submit:
If the application renders this string directly into the page, the browser will execute the script and send the victim's session cookie to the attacker's server. The fix: always HTML-encode all user-provided data before rendering it in the page. This converts the <script> tags into harmless text that the browser displays literally.
- Output encoding: The primary defense — encode data for the correct context (HTML body, JS string, URL parameter, CSS value). Each context requires different encoding rules.
- Content Security Policy (CSP): Add CSP headers to block inline scripts. Even if encoding is missed, CSP provides a safety net by preventing unauthorized script execution.
- Avoid innerHTML: Use
textContentorinnerTextinstead ofinnerHTMLwhen inserting text. The DOM API handles encoding automatically with text methods. - HTML sanitization: If you must allow limited HTML (rich text editors, markdown), use a proven library like DOMPurify to strip dangerous elements while preserving safe formatting.
- Double encoding pitfall: Be careful not to encode content twice. Double-encoded entities like
&lt;will display as<instead of<, breaking your content.
Using HTML Encoding in Your Code
Most modern programming languages and frameworks provide built-in HTML encoding support:
- JavaScript: Create a DOM element and assign
textContent, then readinnerHTMLto get the encoded string. For Node.js, use theheorhtml-entitiesnpm package. - Python: Use
html.escape()andhtml.unescape()from the standard library. These handle all five core characters and numeric entities by default. - PHP: Use
htmlspecialchars()with theENT_QUOTES | ENT_HTML5flags and specify UTF-8 encoding explicitly. Usehtmlentities()to encode all applicable characters. - React / Vue / Angular: These frameworks automatically encode content inserted via JSX expressions, template interpolation, or data binding. The danger arises only when using escape hatches like
dangerouslySetInnerHTML(React),v-html(Vue), orbypassSecurityTrustHtml(Angular). - Go: Use
html.EscapeString()from the standard library, or use thehtml/templatepackage which automatically escapes by context.
Check the Code Snippets card above for copy-paste ready examples in JavaScript, Python, and PHP for both encoding and decoding operations.
About Developer Tools
Developer tools automate the repetitive parts of software work: formatting JSON, encoding/decoding Base64, decoding JWTs to verify token claims, generating UUIDs, formatting XML, diffing configurations. These aren't glamorous tasks, but they're the friction points that eat 10-15 minutes multiple times a day — adding up to hours weekly. Running them in a clean browser tab beats wrestling with CLI dependencies or IDE extensions that might ship your private data to a third party.
Why it matters
Fast, client-side developer tools fundamentally matter because they're used with sensitive data. JWT tokens contain user identity. Base64 payloads might encode API keys. JSON dumps include customer records. If a 'developer tool' sends your input to a server to process, you've just leaked production secrets. ZestLab's dev tools run 100% client-side with no network calls after page load — what you paste stays in your browser.
Privacy and safety
All developer tools here execute in-browser using pure JavaScript. There's no 'decode server' or 'format API' — your JWT, your JSON, your encoded payload is parsed by code running on your laptop. Verify this yourself with browser DevTools → Network tab: you'll see zero outbound requests when using any tool. That's a standard we hold because dev tools handle secrets.
Best practices
- Never paste production JWT or API tokens into ANY online tool without verifying it runs client-side (check the Network tab)
- Use browser private/incognito mode for one-off decoding of sensitive payloads
- Bookmark tools you use daily — ZestLab tool URLs are stable and don't require accounts
- When formatting JSON with secrets for team review, redact credentials before sharing the formatted output