HTML Escape and Unescape Tool — Convert Special Characters to HTML Entities Instantly
If you've ever pasted a code snippet into a webpage and watched it vanish — or worse, break the layout entirely — you already know why HTML escaping matters. When the browser sees a < character, it doesn't display it. It tries to parse it as the start of an HTML tag. Same with &, >, and quotes. To show these characters as actual visible text on a webpage, you have to convert them to their HTML entity equivalents first. That's exactly what this tool does — quickly, cleanly, and without any signup or download required.
This HTML escape unescape tool online free handles both directions. Escape takes your raw text or code and converts special characters into safe HTML entities. Unescape does the reverse — it takes a string full of things like < and & and converts them back to the original readable characters. Both operations are useful in different situations, and both are covered here with a single interface.
Quick reminder: Always escape & first before escaping other characters. If you escape < to < first and then escape the &, you'll end up double-escaping the ampersand in your entity name. Most good tools handle this automatically — this one does too.
What HTML Escaping Actually Does and Why It Exists
HTML was designed with a small set of characters that have special meaning in the markup syntax. The angle brackets < and > open and close tags. The ampersand & starts entity references. Double quotes delimit attribute values. Because the browser uses these characters to understand the structure of your page, you can't just drop them into text content and expect them to show up literally.
The solution is HTML entities. Instead of writing a literal <, you write < — which the browser renders as the less-than sign without trying to parse it as a tag opener. Our html entity encoder decoder online converts between these two representations so you don't have to remember the entity codes or do it manually.
Beyond display correctness, this matters enormously for security. When you take text input from a user and display it back on a page without escaping it, you've created a Cross-Site Scripting (XSS) vulnerability. An attacker could type <script>document.cookie</script> into a comment field and have your site execute their code for every visitor who sees that comment. Proper escaping converts those angle brackets into harmless entities before the content ever reaches the HTML output.
When to Escape HTML and When to Unescape It
The escape direction is what most people need most of the time. You're escaping when you want to escape special characters in HTML for safe display — things like code examples in a tutorial, user-generated comments on a blog, content pulled from a database or API, or anything where the source text might contain angle brackets, ampersands, or quotes that weren't meant to be interpreted as HTML markup.
The unescape direction comes up in different scenarios. You're unescaping when you receive already-encoded data and need to work with it as plain text. This happens when consuming API responses that return HTML-encoded strings, when processing content exported from CMS systems, when debugging encoded content, or when you need to convert stored HTML entities back into something readable for further processing.
The "Both Ways" mode in this tool is useful when you're not sure which direction you need, or when you're debugging and want to see both representations at once. Paste in your text, and you'll get the escaped version on the left and the unescaped version on the right.
Understanding Named Entities vs Numeric Entities
When this tool converts HTML entities to text online or vice versa, it can output either named or numeric entity formats. The difference is worth understanding because you'll see both in real code.
Named entities use readable abbreviations. < for less-than, & for ampersand, © for the copyright symbol. These exist only for a limited set of characters that were assigned names in the HTML specification. They're easier to read in source code and immediately obvious to any developer who sees them.
Numeric entities use character code numbers. < is the decimal encoding for less-than (character 60 in ASCII/Unicode). < is the hexadecimal version of the same character. Numeric entities work for any Unicode character, not just the ones with names. This is why they're the only option for encoding emoji, obscure symbols, or characters from non-Latin scripts that don't have named entity equivalents.
The tool's options let you choose which format you want. "Use named entities" enables the readable < style where available. "Use hexadecimal encoding" switches numeric entities to the hex format. If neither option is checked, numeric decimal format is the default.
How to Display Code Examples Safely on a Website
This is probably the most common practical use of an html escape tool for code snippet display. If you run a blog, documentation site, tutorial, or any page where you need to show raw HTML or other code to readers, you have to escape it first or it won't show up correctly.
Say you want to show this snippet as an example:
<a href="https://example.com" target="_blank">Visit Site</a>
Without escaping, pasting that directly into your HTML renders a live link, not visible code. The browser just interprets it as a real anchor tag. To show it as text, you escape it first and wrap it in a <pre><code> block. This tool does the escaping in two seconds — paste your code, click Copy Output, and you've got the escaped version ready to drop into your page.
The same principle applies to SQL queries, JavaScript snippets, CSS rules, or any other technical content. Escape it, put it in a code block, and your users see exactly what you intended.
Using HTML Escaping for XSS Prevention — The Basics
This deserves a direct, plain-English explanation because it comes up constantly in web security. XSS (Cross-Site Scripting) happens when an attacker manages to inject JavaScript into a page that then executes in another user's browser. The most common way this happens is through forms and comment fields where user input gets displayed back on the page without being sanitized.
Here's the simplest possible example. A user types this into a comment field:
<img src=x onerror="alert(document.cookie)">
If your server takes that string and dumps it straight into the HTML of your page, the browser parses it as an image tag, fails to load the image, and fires the onerror handler — which could do anything: steal session cookies, redirect to a phishing page, log keystrokes. That's XSS.
If you run that string through this html escape tool for user generated content before outputting it, the angle brackets become < and >. The browser renders them as visible characters rather than parsing them as a tag. The attack is neutralized. The user sees their text displayed on the page. Problem solved at the output layer.
One important clarification: this tool is for manually converting strings when you need to check output or prepare content. In production code, you should be using your language's built-in escaping functions — htmlspecialchars() in PHP, escape() in Jinja2, HtmlEncoder in .NET — not manually escaping each string. But this tool is invaluable for understanding what those functions produce, debugging encoded strings, and working with content outside of a running application.
Escaping HTML for Email Templates
Email HTML is its own world of pain, and it's a context where using an online tool to encode HTML for email templates saves a lot of headaches. Email clients handle HTML differently from browsers — some don't support certain characters, some render entity-encoded characters differently, and some strip out content that looks potentially malicious.
The safest approach for email is to use named entities for any character that isn't standard ASCII. The copyright symbol in your footer should be ©, not the raw © character. The em dash in your headline should be —, not —. Special characters like these can get corrupted during email processing or display incorrectly in older email clients if they're not properly encoded.
Paste your email HTML content into this tool with "Use named entities" checked, process it, and you'll get a version that's much more likely to render consistently across Gmail, Outlook, Apple Mail, and the other clients your recipients are using.
Common Mistakes When Escaping HTML
A few things trip people up that are worth knowing about:
- Double-escaping — Running already-escaped content through the encoder again. If < gets escaped, it becomes &lt;. The tool's "smart escape" approach checks for existing entities to prevent this, but watch for it if you're running content through multiple processing steps.
- Escaping in the wrong context — HTML entity encoding is for HTML contexts. In a JavaScript string inside a script tag, you need JavaScript escaping (backslashes), not HTML entities. In a URL parameter, you need percent-encoding. This tool is specifically for HTML contexts.
- Forgetting attribute values — The characters that need escaping inside an HTML attribute (especially quotes) are slightly different from those in body content. If you're escaping content that will go inside a quoted attribute value, make sure double quotes are in the escape set.
- Not escaping the ampersand first — Already covered above, but worth repeating. Escape order matters. & before < before everything else.
Frequently Asked Questions
What's the difference between HTML escaping and URL encoding?
HTML escaping converts characters that are special in HTML syntax into entity references (<, &, etc.) so the browser doesn't try to parse them as markup. URL encoding (percent-encoding) converts characters for safe transmission in URLs (%20 for a space, %26 for an ampersand). They're different encoding schemes for different contexts. You wouldn't HTML-escape a URL parameter, and you wouldn't URL-encode HTML body content. This tool handles HTML entity encoding/decoding only.
Does escaping HTML prevent all XSS vulnerabilities?
HTML output escaping is the most important defense against reflected and stored XSS, but it's not the whole picture. JavaScript contexts inside script tags require JavaScript-specific escaping. CSS contexts have their own rules. DOM-based XSS happens client-side and requires careful use of APIs like textContent instead of innerHTML. A proper defense includes output escaping, Content Security Policy headers, input validation, and using safe DOM APIs. Escaping is necessary but not alone sufficient for complete XSS protection.
When should I use ' versus " for quotes?
" encodes the double quote (") and is part of the original HTML specification. It's widely supported everywhere. ' encodes the single quote/apostrophe (') and was officially added in HTML5 — older browsers and some XML parsers don't recognize it. For maximum compatibility, use ' (numeric) instead of ' when encoding apostrophes, especially in HTML attributes or XML contexts.
How do I handle HTML escaping in JavaScript code?
In JavaScript running in the browser, use element.textContent instead of element.innerHTML when inserting text — this automatically treats the string as plain text without any escaping required. If you need to build HTML strings manually, write a simple function that replaces &, <, >, ", and ' with their entity equivalents. This tool is useful for testing what that output should look like before building the function.
Can I use this tool to decode HTML entities from API responses?
Yes, that's one of the most practical uses. Many APIs return HTML-encoded strings — especially older APIs, RSS feeds, and scraped content. Switch the tool to Unescape mode, paste the encoded string, and you'll get the clean readable text back. This is also useful when debugging content that's been double-encoded or when you receive data from a system that was over-zealous with its escaping and you need to strip it back to the original characters.
Does this tool process data server-side or stay in my browser?
Everything runs client-side in your browser. No text you paste into this tool is ever sent to any server. The JavaScript encoding and decoding logic runs entirely locally. This makes it safe to use with sensitive content — internal code snippets, database content, or anything you'd rather not transmit over the internet. It also means the tool works offline once the page is loaded.
Why does my escaped output look different from what my server-side language produces?
Different languages and frameworks make different default choices. PHP's htmlspecialchars() by default only escapes the five core HTML characters and uses " for double quotes. Python's html.escape() does a similar minimal set. Some frameworks escape every non-ASCII character as a numeric entity for maximum safety. This tool's options let you match the approach your language uses — toggle "Escape all special characters" and "Use named entities" to find the combination that produces output matching your server-side function.
Quick Reference — The Five Characters You Must Always Escape
Everything else is optional depending on context and security requirements, but these five are non-negotiable whenever you're outputting untrusted text into HTML:
- & (ampersand) → & — escape this one first, always
- < (less-than) → < — prevents tag injection
- > (greater-than) → > — closes the tag injection loop
- " (double quote) → " — protects attribute values
- ' (single quote) → ' — protects single-quoted attribute values
Get these five right consistently and you've addressed the vast majority of HTML injection risks. This tool makes it effortless — paste in any string and get back correctly escaped output in under a second, ready to drop directly into your code or template. Use it for quick checks, debugging, manual content preparation, or whenever you need to verify that your escaping logic is producing the right output.