🏷️ HTML Encoder / Decoder
Encode special characters to HTML entities or decode them back. Runs entirely in your browser.
<h1 class="title">Hello "World" & 'Friends'!</h1>
Common HTML Entities Reference
Which characters must be encoded in HTML?
Five characters have special meaning in HTML and must be escaped: < (becomes <) to prevent browsers from interpreting it as a tag opening. > (becomes >) closes tags. & (becomes &) starts entities — an unescaped & that is not part of a valid entity may cause rendering issues. " (becomes ") inside attribute values wrapped in double quotes. ' (becomes ' or ') inside attribute values wrapped in single quotes. In practice, always escape all five when inserting user-generated content into HTML. Only < and & are strictly required in HTML body content, but escaping all five is safer.
How does HTML encoding prevent XSS (Cross-Site Scripting) attacks?
XSS attacks inject malicious JavaScript into a page by inserting HTML that the browser executes. If a user submits <script>alert('hacked')</script> as their name and you display it unescaped, the browser executes the script. After HTML encoding, the same input displays as <script>alert('hacked')</script> — the browser shows it as literal text without executing anything. This encoding must happen at the point of rendering, not at the point of storage. Store the raw input; encode when displaying. Context matters: HTML encoding is correct for HTML body; URL encoding is needed for href attributes; JavaScript encoding for inline JS.
What is the difference between named and numeric HTML entities?
Named entities use a descriptive name: & < © € —. Numeric entities use the Unicode code point in decimal (— for em dash) or hexadecimal (— for em dash). Named entities are only available for characters that have been given names in the HTML specification — common symbols are named, but most Unicode characters are not. Numeric entities work for any Unicode character. For the required < > & " characters, use the named entities (< > & ") for readability. For obscure symbols, use numeric entities.
When should I use (non-breaking space)?
(non-breaking space, character U+00A0) prevents a line break between two words: "50 kg" ensures 50 and kg always appear on the same line. Use it for: unit values (50 kg, 25 mph), titles with initials (J. K. Rowling), phone numbers with country code (+1 555), and any pair of words that should never be separated at a line break. Do not use for visual spacing — use CSS margin, padding, or a proper layout system. Consecutive entities for indentation is an anti-pattern that breaks accessibility and is unmaintainable.
Should I encode HTML entities in JavaScript strings?
HTML entities are parsed by the HTML parser — they have no meaning in JavaScript context. If you are building an HTML string in JavaScript (template literals, innerHTML), encode the HTML characters. If you are setting textContent instead of innerHTML, the browser automatically treats the value as plain text and no encoding is needed: element.textContent = userInput is always XSS-safe. element.innerHTML = userInput is dangerous unless userInput is HTML-encoded. For React and most modern frameworks, JSX automatically escapes values in JSX expressions — {userInput} is safe, dangerouslySetInnerHTML is not.
What is the HTML character encoding declaration and is it still needed?
The <meta charset='UTF-8'> tag in the HTML <head> tells the browser which character encoding to use. Without it, the browser may guess wrong — older browsers defaulted to Latin-1 (ISO-8859-1), which causes mojibake (garbled text) for non-ASCII characters. Always include <meta charset='UTF-8'> as the first element in <head> (before any content, especially before any content that might reference external resources). In UTF-8 HTML5, you can safely use actual Unicode characters directly (é, ü, 中文, 🚀) without encoding them as entities.
What other encoding tools are on this site?
The URL Encoder handles percent-encoding for URL-safe transmission. The Base64 Encoder encodes binary data for HTTP and data URIs. The Character Encoder looks up Unicode code points and entity references for any character. The HTML Entity Reference tool is a searchable complete list of all named HTML entities. The HTML Validator checks that your HTML is structurally correct after encoding. All are in the Dev Tools section.
📊 Key Data Points
5 mandatory
Characters that must always be HTML-encoded: & < > double-quote single-quote
XSS number 1
Cross-site scripting is the most common web vulnerability — caused by missing HTML encoding
OWASP A03
Injection attacks including XSS rank number 3 in the OWASP Top 10 2021
HTML Encoder / Decoder -- Complete USA Guide 2026
Inserting user-provided text into HTML without encoding it first is the root cause of XSS vulnerabilities — the most common security issue on the web. Five characters require mandatory escaping before any text can be safely rendered in HTML.
This encoder runs entirely in your browser. Paste raw text to get HTML-safe entities, or paste encoded HTML to restore readable text.
**Long-tail searches answered here:** how to escape HTML special characters online, convert < > & to HTML entities free, XSS prevention HTML encoding tool browser-based.
After encoding, validate your HTML structure with the HTML Validator.
🔬 How This Calculator Works
The encoder performs the five mandatory HTML substitutions: & to &, < to <, > to >, double-quote to ", single-quote to '. These five are mandatory because they have structural meaning in HTML.
The decoder reverses named entities (&, <, >, ", ', ) and numeric entities back to their literal characters.
✅ What You Can Calculate
XSS-safe HTML escaping
Encode user-submitted names, comments, or search terms before rendering in HTML. Prevents script injection by ensuring < becomes < and & becomes & before hitting the DOM.
Attribute value escaping
Values inside HTML attributes need quotes encoded too. This tool encodes both double and single quotes so attribute values cannot be broken out of.
Decode garbled HTML emails
Email clients sometimes double-encode text, leaving &amp; instead of &. Decode once or twice here to read the actual content.
Template literal safety
When building HTML strings in JavaScript, encode dynamic values before interpolation. Prevents accidental tag injection even when you control the template.
🎯 Real Scenarios & Use Cases
Sanitizing user input for display
A user submitted a comment containing a script tag. Without HTML encoding, that script executes. Run the input through this encoder before any DOM insertion.
Debugging email template encoding
Your email template shows &quot; instead of a double quote. Decode the HTML here to find where the double-encoding is happening in your email pipeline.
Writing HTML documentation
Writing code examples in HTML and need to show actual < and > characters rather than having them parsed as tags. Encode your code snippets here first.
CMS and rich text editors
Legacy CMS platforms output raw HTML entities as text. Decode the exported content here before processing it programmatically.
💡 Pro Tips for Accurate Results
Encode at the output, not the input. A common mistake is encoding HTML entities at input time and storing the encoded version in your database. This causes double-encoding when you later encode on output. Store raw text; encode at render time.
Context matters. HTML encoding is correct for element content and attribute values. For JavaScript strings, URL context, or JSON, each has its own escaping rules.
Ampersand must come first. When encoding manually, always encode & before the other characters to avoid double-encoding.
Test with a script tag. After encoding user input, try inputting a script tag and verify the output shows the literal text not an executing script.
🔗 Use These Together
🏁 Bottom Line
HTML encoding is non-negotiable for any application that renders user-provided content. The five mandatory characters are the entry points for XSS attacks when left unescaped. Pair this with the HTML Validator and the HTML Entity Reference.