HTML Encoder
Convert special characters into safe HTML entities.
How to Use the HTML Encoder
Paste any text, including raw HTML tags, then click "Encode to HTML Entities." Every &, <, >, double quote, and single quote in the text is converted to its escaped entity (like < for <), making it safe to display as literal text inside an HTML page instead of being interpreted as markup. Use "Copy Text" to grab the encoded result to your clipboard.
Worked Example
The default text loaded in the box is the literal string <div class="box"> & 'quotes' </div>, 35 characters. Clicking "Encode to HTML Entities" converts it to <div class="box"> & 'quotes' </div>, 69 characters. Every angle bracket, double quote, ampersand, and apostrophe has been converted to its escaped entity, while the letters, spaces, and other regular characters pass through unchanged.
The Five Encoded Characters, Explained
& (ampersand) becomes &, since the ampersand starts every HTML entity, a literal & must itself be encoded first, otherwise the browser would try to interpret whatever follows it as the start of an entity reference.
< (less than) becomes < and > (greater than) becomes >, since these define the start and end of HTML tags, an unencoded < in ordinary text risks being interpreted as the opening of a tag.
" (double quote) becomes ", since inside an HTML attribute value delimited by double quotes, an unencoded double quote would prematurely close the attribute and break the tag's structure.
' (apostrophe) becomes ', the same problem as double quotes, but for attributes delimited by single quotes instead. Encoding it protects against both quoting styles.
Common Mistakes When Encoding HTML
The most common mistake is encoding the ampersand out of order, or not at all, when manually escaping text by hand. If & isn't the first character replaced, encoding < to < first and then encoding & second would incorrectly turn that < into <, a double-encoded mess. This tool handles the ordering correctly (ampersand first) automatically, but it's worth knowing if you're ever writing this logic yourself.
Another mistake is double-encoding already-encoded text. Running text that already contains < through this tool again produces &lt;, corrupting the intended output. Always check whether your source text is raw or already encoded before running it through this tool.
It's also worth knowing this tool encodes exactly five characters and no others. It won't encode accented letters, emoji, or non-Latin scripts into numeric character references, since those characters display correctly in HTML without any escaping, encoding them isn't necessary or expected for standard HTML/UTF-8 pages.
Why HTML Needs Character Encoding at All
HTML uses a handful of characters as structural syntax rather than literal content. Angle brackets mark where a tag begins and ends, the ampersand marks where an entity reference begins, and quote characters mark the boundaries of an attribute value. This design means the browser's parser can't tell the difference between "here is a less-than sign the author wants displayed" and "here begins a new tag" unless the author explicitly signals the difference. HTML entities are that signal: they let you write the literal character as text using a sequence the parser recognizes as "this is data, not markup," ensuring your content displays exactly as intended rather than being silently reinterpreted, truncated, or in the worst case, executed as unintended script.
How Browsers Decode Entities Back to Characters
Encoding is a one-way-looking operation from the human's perspective, but it's fully reversible: when a browser parses HTML and encounters <, >, &, ", or ', it decodes each one back to the original character (<, >, &, ", ') before displaying it as text content on the page. This is exactly why encoding is safe for display purposes, the reader sees the original characters exactly as intended, while the browser's parser never mistakes those characters for structural markup along the way. This site's HTML Decoder tool performs that reverse operation, useful for going from encoded entities back to plain readable text.
Real-World Use Cases
Displaying code snippets on a web page: escaping HTML/XML sample code so it shows up as visible text (like a tutorial's code block) instead of being rendered as live markup.
Sanitizing user-generated content: preparing user comments, form submissions, or any untrusted text for safe display inside an HTML page as a defense against markup injection.
Building HTML manually: encoding dynamic values before inserting them into hand-written HTML templates, especially useful when working outside a framework that does this automatically.
Debugging and testing: quickly checking what a piece of text looks like once encoded, to confirm an application's own encoding logic is behaving as expected.
Frequently Asked Questions
Which characters does this tool encode?
It encodes the five characters that have special meaning in HTML: & becomes &, < becomes <, > becomes >, a double quote becomes ", and an apostrophe becomes '.
Why would I need to encode text before putting it in HTML?
If user-supplied or raw text contains characters like < or & and gets inserted directly into an HTML page without encoding, browsers may interpret it as markup instead of visible text, which can break the page layout or introduce a security risk. Encoding first ensures it always displays as plain text.
Does HTML encoding prevent XSS (cross-site scripting) attacks?
Encoding the characters this tool handles (&, <, >, double quote, apostrophe) is one important layer of defense against XSS, since it stops raw text from being interpreted as HTML tags or attribute-breaking content. However, this browser-based tool is meant for one-off manual encoding, not as a substitute for a real application's server-side or framework-level output encoding, which needs to run automatically on every piece of user input, every time, in context-aware ways this static tool can't replicate.
Why does the apostrophe encode to ' instead of a named entity like '?
The named entity ' is valid in HTML5 and XML, but it wasn't part of the original HTML 4 specification and historically caused rendering issues in some older browsers. ' is the numeric character reference for the same apostrophe character and has universal support across every HTML version and browser, which is why it's the more commonly recommended and widely used encoding in practice.
Should I encode text before storing it in a database, or only when displaying it?
Best practice is to store raw, unencoded text in a database and encode it only at the point of output, when it's actually being inserted into an HTML page. Encoding before storage can cause double-encoding bugs (& becoming &amp; after being encoded twice) and makes the stored data harder to reuse in non-HTML contexts like an API response or a plain-text email. This tool is best used for one-off manual encoding tasks, testing, or preparing a code snippet, not as a step in an application's data storage pipeline.
What's the difference between HTML encoding and URL encoding?
They solve different problems. HTML encoding (this tool) makes text safe to place inside HTML markup, converting characters like < and & that would otherwise be interpreted as tags. URL encoding (percent-encoding) makes text safe to place inside a URL, converting characters like spaces and & that have special meaning in a URL's structure. Text that needs to go into both a URL and then into HTML (like a link's href attribute) sometimes needs both kinds of encoding applied, in the right order. This site's URL Encoder tool handles the percent-encoding case.