HTML Encoder (Convert Text to HTML Entities)
Paste plain text or raw HTML below, special characters are instantly encoded into safe HTML entities.
How to Escape Special Characters for HTML
Quick Answer: The HTML Encoder converts special characters, brackets, quotes, and symbols into safe HTML entities to prevent XSS vulnerabilities and rendering glitches. Supports standard named entities, numeric entities, and full ASCII escaping.
Characters that carry special meaning in HTML, such as ampersands, opening and closing angle brackets, double quotes, and single quotes, get replaced with their named entity equivalents so the result can be dropped safely into markup or an attribute without breaking the page.
To escape your content, paste raw code or text into the input area. The tool automatically replaces characters like <, >, &, ", and ' with safe HTML entities. Turn on "Encode all non-ASCII characters" if you also need accented letters, emoji, and anything past code point 127 converted into numeric decimal entities, ideal for legacy environments or strict ASCII data streams.
Why Converting HTML Entities is Important for Security
The primary reason for escaping HTML is preventing Cross-Site Scripting (XSS) attacks and markup injection. When user input containing raw angle brackets is rendered on a webpage without escaping, the browser may interpret that input as executable HTML tags or JavaScript scripts. Converting these symbols into HTML entities ensures the web browser treats the data purely as plain visual text, neutralizing malicious payload execution.
The five characters this tool escapes by default (ampersands, angle brackets, double quotes, and single quotes) represent the standard minimal set recommended in web application security guidelines to prevent markup injection before untrusted text is placed into HTML content or attributes.
HTML Encoder vs. HTML Decoder Explained
An HTML Encoder converts human-readable or raw markup characters into their entity codes (such as turning < into <). This is necessary whenever you want code snippets, documentation examples, or unvetted inputs to be rendered visibly on a web page rather than interpreted by the browser engine.
Conversely, an HTML Decoder reverses this conversion, translating character entities back into plain characters and raw HTML markup. If you receive an encoded payload from an API or database and need to read the underlying text or source tags, you can paste the entities into our companion HTML Decoder tool to instantly restore the original markup.
Why the ampersand is replaced first, and why that order matters
The encoder runs sequential string replacements, and the very first one converts every literal ampersand into its entity form. That ordering is essential because every HTML entity inserted contains an ampersand character, encoding ampersands anywhere else would re-encode the entities the tool had just inserted a moment earlier, producing broken double-encoded output. Doing the ampersand pass before any other character avoids that defect entirely.
The apostrophe uses a numeric entity, not named apos
Single quotes are encoded as a numeric entity rather than the named entity apos. This is deliberate: apos is valid in XML and HTML5, but it was never part of the original HTML 4 named-entity table, so older parsers and legacy processors do not recognize it. The numeric form resolves to the identical apostrophe character across all HTML versions back to HTML 2, making it the safest default choice.
Non-ASCII encoding handles emoji correctly across full code points
When "Encode all non-ASCII characters" is on, the tool iterates text by full Unicode code points rather than raw UTF-16 code units. That distinction matters for characters outside the Basic Multilingual Plane, including modern emoji. A naive loop over string indices would split a four-byte emoji into two orphaned surrogate halves and encode each separately, producing two broken numeric entities. Iterating by code point ensures an emoji is read as a single unit and encoded into a single valid entity.
This covers the baseline character set security libraries treat as unsafe
The five characters this tool escapes by default (ampersands, angle brackets, double quotes, and single quotes) represent the standard minimal set recommended in web application security guidelines to prevent markup injection before untrusted text is placed into HTML content or attributes. While encoding stops text from being interpreted as executable tags, always ensure contextual validation in sensitive backend routines.
Both quote characters are escaped for attribute safety
Both double quotes and single quotes get replaced regardless of which quote delimiter wraps your HTML attributes. This ensures that whether an attribute is written with double or single quotes, the encoded value will not break attribute delimiters or introduce escaping errors.
Frequently Asked Questions
What does an HTML encoder do?
An HTML encoder converts special characters (like brackets and ampersands) into their corresponding safe HTML entities so that browsers display the code as text rather than executing it.
Why do I need to escape HTML characters?
Escaping HTML characters is crucial for security. It prevents Cross-Site Scripting (XSS) attacks by ensuring that user input is treated as plain text rather than executable browser code.
Why is the ampersand encoded before the other characters?
Because every entity this tool produces contains an ampersand itself. Encoding the ampersand first, before inserting any other entities, prevents those newly inserted entities from being encoded a second time into a broken, double-escaped result.
Why does the apostrophe become a numeric entity instead of named apos?
The named entity apos is valid in XML and HTML5 but was never part of the original HTML 4 named-entity table, so some older or stricter parsers do not recognize it. The numeric decimal reference resolves to the identical apostrophe character in every version of HTML, making it the more broadly compatible choice.
Does the non-ASCII option handle emoji correctly?
Yes. The tool iterates the text by full Unicode code point using Array.from() rather than by raw UTF-16 code unit, so multi-byte characters like emoji are read as a single unit and converted into one correct numeric entity, instead of being split into two broken surrogate halves the way a naive character loop would handle them.
Does encoding my text make it safe from XSS by itself?
Encoding the five core characters this tool targets is the standard baseline for making text safe to insert as HTML content or into an attribute, but the tool only performs the character substitution; it does not sanitize, validate, or automatically apply the result anywhere. You still need to use the encoded output in place of the raw text wherever it is rendered.
Can I reverse this process to recover raw HTML from entities?
Yes. You can paste the encoded entities into our companion HTML Decoder tool to instantly convert character entities back into plain characters and raw HTML markup.
Is my text sent to a server when I use this tool?
No. Encoding runs entirely in your browser with plain JavaScript string methods; nothing you type or paste is transmitted anywhere.
What is the difference between named entities and numeric entities?
Named entities use human-readable mnemonics like < for less-than, whereas numeric entities use decimal values like < or hex values like <. Both render identically in web browsers, but numeric entities offer universal compatibility across all XML and SGML specifications.
Should I encode text before saving it to a database or when rendering it?
Modern security best practices recommend storing raw unencoded text in your database and encoding it contextually at render time (output encoding). This prevents double-encoding bugs and ensures the same data can be safely rendered across HTML, JSON APIs, and mobile apps.