HTML Escape / Unescape Tool

HTML escaping replaces characters with special meaning in HTML with their matching entities. The main ones are <, >, &, ", and '. Raw < becomes <, raw & becomes &. This is also called html entity encoding, and the tool itself gets called an html entity encoder just as often. Without escaping, a stray < or & in user text can break page layout.

HTML unescaping reverses the process, turning entities back into their original characters. < becomes <, & becomes &. People also call this html entity decoding, the reverse job an html entity decoder performs. You'll typically unescape html entities when reading content pulled from an API, RSS feed, or CMS export. That covers anywhere text was encoded before you received it.

Some documentation writes this as HTML escape / unescape, treating both directions as one combined operation. Whether you call it HTML entity encoding and decoding or just escaping and unescaping, this tool covers both directions.

HTML escaping works character by character, not byte by byte like binary encodings. Each reserved character maps directly to one HTML entity, either a named one like & or a numeric one like &. Named entities are easier to read; numeric ones work for any character, even ones without a defined name. The order of replacement matters, & must be escaped first, or later replacements double-encode it.

Here's a real walkthrough: escaping the string 5 < 10 & true. Each reserved character gets replaced in a single left-to-right pass, and everything else stays untouched.

Every reserved character becomes exactly one entity, there's no length inflation like Base64's 33% overhead. HTML escaping only touches five characters, so most text passes through unchanged. Rules for entity names come from the HTML5/WHATWG specification, which defines over 2,000 named entities in total.

Result:5 < 10 & true→5 < 10 & true

Need to html escape online without installing anything? Whether you search escape html online or html escape characters online, the workflow here is the same. This tool is built for speed, no account, no install. A mode toggle switches between Escape and Unescape, and an entity-format toggle picks Named or Numeric output. Everything processes locally in your browser, so pasted text never touches a server.

Escaped output always reads as safe entities plus your original text. Decoding back to plain text, sometimes called html to text conversion, works the same way: paste, click Unescape, and copy. If the output looks unchanged, your input had no escapable characters to begin with.

A single word does not show how HTML escaping and unescaping behave with real content. The table below walks through five common scenarios, from a plain sentence to a full HTML snippet. Every example uses UTF-8 input and named entities, this tool's default output format.

Notice the comparison-text example escapes both < and & in the same pass, in the correct order. Escaping & first prevents < and > from being mangled into < and >. That ordering detail is the most common source of double-escaping bugs.

Only five characters need escaping in most HTML contexts, though a few more are useful to know. The table below covers the common set, every character this tool escapes by default, plus a few typographic extras. For the complete list of all 2,000+ named entities, see our full HTML Entities Reference.

Named entities like © are easier to read in source code. Numeric entities like © work even when a character has no defined name, which matters most for uncommon Unicode symbols.

A third form, hexadecimal, works the same way: & represents the same ampersand as &. This tool's Numeric option outputs decimal by default, but Unescape mode decodes hex references automatically too.

Beyond the reserved five, HTML also defines named entities for accented letters and symbols, like é for e with acute and ñ for n with tilde. These matter whenever you cannot guarantee UTF-8 encoding downstream, such as older email clients or legacy CMS exports.

Search engines see this list under different names too. Common variants include html escape quotes, html escape apostrophe, and html escape ampersand. For the two quote characters specifically, you'll also see html escape single quote and html escape double quote. For the angle brackets, that's html escape less than and html escape greater than. You'll also see this framed as escape character html, or the entities themselves called html escape codes, same table, different names.

HTML escaping only works where the browser is parsing HTML text content. Two common spots break that assumption: <script>/<style> elements, and HTML attributes that actually hold JavaScript or CSS.

Inside <script> and <style> tags, the browser doesn't parse entities at all, it treats the content as raw JavaScript or CSS. Escaping & inside a <script> block doesn't protect anything; it just prints a literal & into your code, which is usually wrong. Dynamic values need proper JS or CSS string escaping instead, not HTML entities.

The same applies to attributes like onclick and style. <p onclick="NOT-HERE"> and <p style="NOT-HERE"> hold JavaScript and CSS respectively. HTML escaping alone doesn't make untrusted content safe inside them. Match the escaping to the actual context, not just to "it's inside an HTML tag."

Most developers do not just need a one-off conversion; they need the same logic inside their own app. The snippets below cover three common languages for escaping and unescaping HTML. Each example escapes and unescapes the string Tom & Jerry, matching what this tool produces.

Javascript escape html and js escape html both point to the same problem: there's no single built-in string-escaping function. The DOM-based textContent approach above is the safest option for display. For server-side string escaping without a DOM, Node's escape-html npm package is a common lightweight choice. For escaping text inside a JavaScript string literal instead of HTML, use a JavaScript String Escape Tool.

Python html escape and php html escape are simpler, both ship a dedicated function in their standard library. No extra install is needed for either one.

// Escape (safe display)
const el = document.createElement("div");
el.textContent = "Tom & Jerry";
const escaped = el.innerHTML;
console.log(escaped); // Tom & Jerry

// Unescape
const parser = new DOMParser();
const decoded = parser.parseFromString(escaped, "text/html").body.textContent;
console.log(decoded); // Tom & Jerry

import html

escaped = html.escape("Tom & Jerry")
print(escaped)  # Tom & Jerry

decoded = html.unescape(escaped)
print(decoded)  # Tom & Jerry

<?php
$escaped = htmlspecialchars("Tom & Jerry");
echo $escaped; // Tom &amp; Jerry

$decoded = htmlspecialchars_decode($escaped);
echo $decoded; // Tom & Jerry

HTML escaping reduces XSS risk, but it isn't complete protection on its own. Escaping makes user text render as visible characters instead of markup, genuinely useful, and necessary. Full protection needs context-aware escaping: HTML body, attribute, JavaScript, and URL contexts each have their own rules.

On the privacy side, this tool runs entirely client-side in your browser. Pasted text and HTML never get uploaded to a server. Sensitive strings, draft comments, internal templates, API responses you're debugging, stay on your machine the entire time.

Treat this tool as a way to correctly escape or decode HTML entities for display, not a standalone security control. Sanitize any HTML you intentionally allow, rich text, Markdown output, with a dedicated sanitizer library. Validate untrusted input server-side too, not just at display time. For URL-context escaping, our URL Encoder/Decoder handles percent-encoding for query strings and paths.

Most HTML escaping and unescaping problems come down to one of three issues. Recognizing the pattern saves you from re-checking your entire input.

If your text still looks double-escaped after one Unescape pass, run it through a second time. That usually means the original encoding happened more than once somewhere upstream.

HTML escaping is not the only text-safety scheme, and picking the right one depends on where the output is headed. The table below compares HTML escaping against the encodings developers most often confuse it with.

Using the wrong encoding for the context leaves the underlying problem open. Html escape characters won't protect a URL, and percent-encoding won't protect HTML body text either. For query strings, our URL Encoder/Decoder handles percent-encoding correctly. For binary data like files and images, our Base64 Encoder/Decoder covers Base64 encoding and decoding. For string literals inside JavaScript, a JavaScript String Escape Tool applies the right escape sequences.