Free HTML Encoder & Decoder – HTML Entity Converter Online

What HTML Entity Encoding Does and How It Works

Five characters cause almost all HTML trouble: the less-than sign, the greater-than sign, the ampersand, the double quote and the apostrophe. A browser reads them as instructions rather than content, so a less-than sign starts a tag and an ampersand starts an entity reference. Encoding replaces each one with its safe equivalent, turning the less-than sign into the entity lt, the greater-than sign into gt, the ampersand into amp, the double quote into quot and the apostrophe into the numeric form 39. Decoding walks it back. Developers displaying code samples, anyone handling user-submitted text, and people cleaning scraped or email-template content all need one direction or the other several times a week. The rule is order-sensitive, and that detail catches people out. Encoding must replace the ampersand first, then the angle brackets and quotes, because if you convert the less-than sign to the entity lt before handling ampersands, the ampersand you just introduced gets encoded again and you end up with amp;lt; instead of lt;. That double-encoded output is the classic symptom of a naive implementation and shows up on live sites as visible entity text on the page. Decoding runs in the reverse order for the same reason. Beyond the five core characters, HTML supports named entities such as copy for the copyright symbol and nbsp for a non-breaking space, plus numeric entities that reference any Unicode code point directly, and both forms produce identical output in the browser. Take the string a developer wants to show in a tutorial: an anchor tag whose href is a hash, whose class attribute is btn, with the words Click me between the tags. Pasted raw into a page, the browser creates an actual clickable link and the reader sees only the words Click me rather than the code. Encoded, every angle bracket becomes lt or gt and each double quote becomes quot, so the page displays the tag source exactly as typed. Now try the reverse with something dangerous: a script tag containing an alert call. Encoded, it renders as harmless visible text on the page. Decoded and inserted into the document, it executes. Same characters, completely different outcome, which is the whole point of the exercise. Where this matters in practice. A documentation author encodes every markup example so the published docs show tags as text rather than rendering them into real elements. A backend developer encodes a user-supplied display name before writing it into a profile page, which closes the most common cross-site scripting hole in the application. A support engineer decodes an email template full of entities to read what the message actually says before editing it. Someone importing scraped product descriptions decodes the entities once so the database holds clean readable text and the display layer handles escaping instead. A QA tester pastes a suspicious payload here to see exactly which characters a form is failing to escape. The pitfall worth stating plainly: encoding is context-specific and people mix contexts up. HTML encoding is correct for text going into a page body or an attribute. It is wrong for a value going into a URL, where you need percent-encoding, and wrong for a value going into a JavaScript string literal, where quotes and backslashes need escaping instead. Applying HTML encoding to a query parameter produces a broken link, not a secure one. Also remember that decoding untrusted content and then inserting it into a page undoes your protection entirely, so decode only when you need plain text for reading or storage. Encoding is one layer, not a whole security strategy; pair it with validation and a content security policy. All processing runs in your browser and nothing is uploaded.

Learn More — HTML Encoder / Decoder Guide

🔥 Trending Tools