HTML Encoder / Decoder
Encode special characters to HTML entities or decode HTML entities back to plain text instantly.
HTML Encoder / Decoder
Free ToolHow to use HTML Encoder / Decoder
**What Is HTML Encoding?**
HTML encoding is the process of converting special characters into their HTML entity equivalents so browsers render them as text rather than interpreting them as code. When you type <script> into an HTML document, the browser reads it as an opening script tag. When you encode it as <script>, the browser displays the literal characters <script> on screen — no code execution, no confusion, no security hole.
Every web developer, content creator, and email marketer eventually needs to display characters like <, >, &, and quotes as visible text. HTML encoding is the standard solution built into the web since 1993.
**HTML Entities Reference Table**
| Character | HTML Entity | Description |
|-----------|-------------|-------------|
| & | & | Ampersand |
| < | < | Less than / opening tag |
| > | > | Greater than / closing tag |
| " | " | Double quote |
| (apostrophe) | ' | Single quote |
| (space) | | Non-breaking space |
| (c) | © | Copyright symbol |
| TM | ™ | Trademark symbol |
| -- | — | Em dash |
| (euro) | € | Euro sign |
| (pound) | £ | British pound |
| (yen) | ¥ | Japanese yen |
| (R) | ® | Registered trademark |
| (degree) | ° | Degree symbol |
**How to Use the HTML Encoder Tool**
1. **Paste or type your text** into the input box. This can be raw HTML you want to display as code, user-submitted content you're preparing to store safely, or any text containing special characters you need to escape.
2. **Click Encode** (or watch the output update in real time). The tool instantly converts every special character to its named or numeric HTML entity.
3. **Copy the encoded output** using the copy button. The encoded string is now safe to embed directly in your HTML documents, email templates, or database fields.
No signup required, no file uploads, no data sent to any server — encoding happens entirely in your browser.
**Real-World Examples**
**Example 1: Displaying Code Snippets on a Blog**
You're writing a tutorial about JavaScript and want to show: <script>alert('Hello!')</script>
If you paste that directly into your HTML, the browser executes it — visitors see an alert dialog, not the code. After encoding it becomes:
<script>alert('Hello!')</script>
Paste that encoded version into your blog post's HTML, and readers see exactly the code you intended. This is how every coding tutorial site (MDN, W3Schools, CSS-Tricks) displays code examples.
**Example 2: Encoding User Input Before Storing in a Database**
Your web app has a comment box. A user submits:
Great site! <img src=x onerror=alert(document.cookie)>
If you store and redisplay that raw input, every visitor who loads that page will trigger the malicious JavaScript — a classic stored XSS attack. Encoding the input first converts it to:
Great site! <img src=x onerror=alert(document.cookie)>
Now it displays as harmless text. The OWASP Top 10 Web Application Security Risks consistently lists injection (including XSS) as a top-3 vulnerability. Proper HTML encoding is the primary defense.
**Example 3: Email Template HTML Entities**
Email clients are notoriously inconsistent in rendering special characters. A promotional email with pricing like $49.99 — limited offer copyright 2024? The em dash and copyright symbol may render as garbage characters in Outlook if not encoded. Using — and © instead ensures consistent rendering across Gmail, Outlook, Apple Mail, and Yahoo Mail.
**Example 4: CMS Content Sanitization**
WordPress, Drupal, and Joomla automatically encode certain characters in post content — but custom fields and REST API inputs sometimes bypass this protection. If you're building a headless CMS or pulling content via API to render in a React or Vue.js frontend, you're responsible for encoding any user-generated content before rendering it with dangerouslySetInnerHTML (React) or v-html (Vue).
**HTML Encoding and Web Security: The XSS Connection**
Cross-site scripting (XSS) is one of the most exploited vulnerabilities on the web. The 2021 Equifax data breach exposed 147 million Americans' personal data — XSS was among the attack vectors. The British Airways breach in 2018 (500,000 customer records) exploited a JavaScript injection flaw. The Samy worm in 2005 infected over a million MySpace profiles in 20 hours — all through unencoded HTML in a profile field.
XSS occurs in three forms:
- **Reflected XSS**: Malicious script in a URL parameter gets echoed directly into the page
- **Stored XSS**: Malicious script saved to a database gets served to all visitors
- **DOM-based XSS**: Client-side JavaScript reads attacker-controlled data and writes it to the DOM
HTML encoding defeats all three by ensuring that script tags in user input are never interpreted as code. The OWASP XSS Prevention Cheat Sheet identifies output encoding as Rule #1.
**HTML Encoding vs. URL Encoding vs. Base64**
| Encoding | Output Example | Use When |
|----------|---------------|----------|
| HTML Encoding | <script> | Displaying text in HTML pages; preventing XSS |
| URL Encoding | %3Cscript%3E | Sending data in URL query strings |
| Base64 Encoding | PHNjcmlwdD4= | Embedding binary data in text; API payloads |
HTML encoding is for the browser's HTML parser. URL encoding is for the HTTP layer. Base64 is for binary-to-text conversion. Using the wrong encoding in the wrong context either breaks functionality or leaves security gaps.
**Decode vs. Encode: Two-Way Conversion**
Sometimes you need the reverse: you've received HTML-encoded content from an API or CMS and need to see the original characters. Decoding converts < back to <, & back to &, and so on.
Common decode scenarios:
- Receiving API responses where the server double-encoded content
- Copying encoded email content and needing to read the original text
- Debugging a CMS that stores encoded strings in the database
**5 Common Mistakes (And Their Consequences)**
**Mistake 1: Double-Encoding**
You encode < to <, then run it through the encoder again, getting &lt;. The page displays < as literal text instead of <. Fix: encode only once, at the final output stage.
**Mistake 2: Not Encoding in Email Templates**
Special characters in email subjects and bodies render differently across 40+ email clients. The em dash becomes garbled in Outlook on Windows if not encoded as —. Fix: use named entities for all non-ASCII characters in HTML email.
**Mistake 3: Forgetting Non-ASCII Characters**
Developers encode < > & but miss accented characters like e-acute, n-tilde, Chinese characters, and emoji. In UTF-8 encoded pages (which all modern pages should be), these don't need encoding — but older Latin-1 pages do. Fix: declare meta charset=UTF-8 at the top of every HTML document.
**Mistake 4: Encoding Already-Safe Static Content**
Encoding your own carefully written HTML (like a paragraph tag) breaks the markup — it becomes visible as entity-encoded text. Fix: only encode untrusted or user-generated content, not your own HTML structure.
**Mistake 5: Relying on Client-Side Encoding Alone**
Encoding in JavaScript (client-side) can be bypassed by an attacker who sends a direct HTTP request to your API endpoint. Fix: always encode on the server side as the primary defense, with client-side encoding as a secondary layer.
**Pro Tips for Developers**
PHP: Use htmlspecialchars($input, ENT_QUOTES | ENT_HTML5, 'UTF-8'). The ENT_QUOTES flag encodes both single and double quotes, critical for attribute context.
.NET: System.Web.HttpUtility.HtmlEncode() handles the main entities. For full coverage use System.Security.SecurityElement.Escape() or Microsoft's AntiXSS library.
JavaScript (no built-in function — two-line solution):
function escapeHtml(str) {
return str.replace(/[&<>"']/g,
m => ({'&':'&','<':'<','>':'>','"':'"',"'":'''}[m]));
}
React: JSX auto-escapes all content in curly brace expressions by default. Only dangerouslySetInnerHTML bypasses this — use it only with fully controlled or sanitized content.
Vue.js: Template interpolation (double curly braces) is auto-escaped. The v-html directive is NOT — use DOMPurify.sanitize() before passing any user content to v-html.
Template engines: Jinja2 (Python), Blade (Laravel), and Twig (Symfony) all auto-escape variables by default. Explicitly marking something as safe or using the raw output syntax disables escaping — do this only for content you fully control.
Frequently Asked Questions
What is the difference between HTML encoding and HTML escaping?
HTML encoding and HTML escaping are the same thing — two names for the same process. Both convert special characters like <, >, &, and quotes into their HTML entity equivalents (<, >, &, "). The terms are used interchangeably in security documentation, developer forums, and programming language documentation.
Does HTML encoding prevent XSS (cross-site scripting) attacks?
Yes — HTML output encoding is the primary defense against reflected and stored XSS attacks, per OWASP guidelines. By converting script tags to HTML entities before rendering user input in a browser, you prevent the browser from executing injected JavaScript. However, encoding must happen server-side; client-side-only encoding can be bypassed by direct API requests.
Which characters must be HTML encoded to be safe?
The five critical characters are: & (ampersand becomes &), < (less than becomes <), > (greater than becomes >), double quote (becomes "), and single quote (becomes '). These five, when present in user input and left unencoded, enable XSS attacks. Additional characters like copyright and em dash should be encoded for consistent cross-browser rendering.
Is there a difference between HTML encoding and URL encoding?
Yes — they serve different layers. HTML encoding converts characters for safe display inside HTML documents (< becomes <). URL encoding converts characters for safe transmission in URLs (< becomes %3C). Use HTML encoding when inserting data into HTML pages and URL encoding when building query strings or href attributes.
Do modern JavaScript frameworks like React and Vue automatically encode HTML?
React auto-encodes all JSX template expressions by default, making them safe against XSS. Vue.js auto-encodes standard template interpolations. However, both frameworks provide escape hatches — React's dangerouslySetInnerHTML and Vue's v-html — that skip encoding entirely. Only use these with content you fully control or have sanitized with a library like DOMPurify.
Recommended
Related Tools
Dev
Base64 Encoder / Decoder
Encode and decode Base64 text instantly, convert files to Base64, create data URLs, and use URL-safe Base64 when needed.
Open tool
DevJSON Formatter
Format, validate, minify and analyze JSON with syntax highlighting and stats.
Open tool
DevURL Encoder / Decoder
Encode plain text to URL-safe format or decode percent-encoded URLs back to readable text instantly.
Open tool