HTML Escape Online — Free HTML Entity Encoder

Encode <, >, &, ", ' to HTML entities for safe display inside markup, attributes, and code listings — 100% in your browser.

Raw HTML / Text Input

Escaped Output (HTML Entities)

What is HTML Escaping?

HTML escaping (also called HTML encoding) replaces the five characters that have syntactic meaning to the HTML parser — <, >, &, ", ' — with their entity equivalents (<, >, &, ", '). It is the canonical defence against XSS and the reason your text renders as text instead of becoming markup.

When user-provided strings — comments, profile names, search queries — are dropped directly into HTML, an attacker can inject a <script> tag that runs in every visitor's browser. The OpenFormatter HTML escape tool runs entirely in JavaScript on your machine: paste, click, copy. No server, no upload, no rate limit.

How to escape HTML online — 4 steps

Paste your raw text. Drop any string into the Input panel — comments, code listings, profile bios, anything containing <, >, &, or quotes.
Click Escape. The encoder runs in your browser. The five HTML-sensitive characters are replaced with their entity references in a single pass.
Verify the entities. Every < becomes <, every & becomes &, and so on. Whitespace and Unicode are untouched.
Copy and paste safely. The escaped output is now safe to inject into a text node, a double- or single-quoted attribute, or a <pre><code> block.

Sample input and output

Raw input

<div class="alert">
  <p>Hello, "World" & welcome!</p>
  <a href='/path'>Click here</a>
</div>

Escaped output

&lt;div class=&quot;alert&quot;&gt;
  &lt;p&gt;Hello, &quot;World&quot; &amp; welcome!&lt;/p&gt;
  &lt;a href=&#39;/path&#39;&gt;Click here&lt;/a&gt;
&lt;/div&gt;

XSS Prevention

Encoding the five HTML-sensitive characters neutralises injected <script> tags, event handlers, and broken attributes — the OWASP-recommended baseline for output encoding.

Five-Character Set

Encodes & first, then < > " ' — the exact set every framework (React, Vue, Django, Rails) uses to render text safely into HTML.

Browser-Only

Encoding runs in JavaScript on your device. Strings containing tokens, secrets, or PII never leave the browser.

Common use cases

check_circleRendering user-submitted comments, reviews, and forum posts safely in HTML
check_circleEmbedding code samples inside <pre><code> blocks on a documentation site
check_circleEncoding subject lines and HTML-email bodies before sending transactional mail
check_circlePreparing dynamic values for double- and single-quoted HTML attributes
check_circleSanitising search-query echo on a results page to defeat reflected XSS
check_circleEscaping CMS or database text before injecting it into server-side templates
check_circleWriting JSX-like output from a non-React templating engine
check_circleProducing HTML reports from log lines that may contain angle brackets and ampersands

HTML escape vs URL encode vs JS escape

All three convert special characters, but each targets a different parser. HTML escape protects against the HTML parser interpreting < as a tag — output goes into HTML markup. URL encode percent-encodes characters with reserved meaning in URLs (?, &, =, space) — output goes into a URL. JavaScript escape neutralises characters that would break a JS string literal (', ", \, newline) — output goes into inline JavaScript. Using the wrong one in the wrong context is a classic source of XSS bugs: HTML-escaping a value before pasting it into a JavaScript string still leaves </script> as a literal sequence that breaks out of the script tag.

Need to reverse the operation?

Use the HTML Unescape tool to decode entities back to characters, or jump to the full set of escape and unescape utilities.

HTML Unescape All Escape Tools HTML Formatter

Frequently Asked Questions

Why escape `<` to `<`?

Browsers treat `<` as the start of an HTML tag. If user content contains a literal `<`, the parser may interpret it as markup and either break the page layout or, worse, run an injected `<script>` block. Encoding it as `<` makes the browser display the literal less-than character without trying to start a tag.

Is the output safe to inject into innerHTML?

Yes for plain text contexts inside element content. The five-character escape (& < > " ') covers text-node and double-quoted attribute injection. Do not, however, paste escaped output into JavaScript string contexts, URL contexts, or event handlers — those need their own encoding rules. For untrusted input the safest pattern is `el.textContent = userInput`, which performs the equivalent escaping automatically.

Does it escape Unicode?

No — and it should not. UTF-8 HTML pages handle every Unicode character natively, so encoding emoji or non-Latin scripts as numeric entities makes the source larger without improving safety. Only the five characters with special meaning to the HTML parser are escaped.

Why is the ampersand escaped first?

If `<` were escaped before `&`, the resulting `<` would itself contain an ampersand that the next pass would re-escape into `&lt;`. Escaping `&` first guarantees no double-encoding occurs in any character.

When should I escape the single quote (`') vs double quote?

Always escape both. If you are sure your attributes are double-quoted you only strictly need `"`, but escaping both lets the same encoded string be safely dropped into either single- or double-quoted attribute contexts. We use `'` for `'` because the named entity `'` is XML, not HTML4.

Will this break my emoji or Chinese characters?

No. Only the five ASCII characters with HTML meaning are touched. Emoji, Chinese, Arabic, Cyrillic, mathematical symbols — all pass through untouched and render correctly in any UTF-8 document.

Is this the same as `htmlspecialchars` in PHP or `escape` in Lodash?

It produces the same output as PHP `htmlspecialchars($s, ENT_QUOTES)` and Lodash `_.escape`. The five-character set (& < > " ') is the standard XSS-safe escape used by every mainstream framework — React, Angular, Django, Rails — when rendering text into HTML.

Should I escape on input or on output?

On output, every time, in the final encoding context. Escaping at input loses the original data, may double-escape if the same string is rendered into a different context (URL, JSON), and breaks search/edit features. Modern frameworks default to output-time escaping for this reason.