HTML Encoder & Decoder

A Quick Gut-Check on the Settings

• Leave Entity Style on Named for anything a person will read later — — is instantly recognizable, — isn't.
• Only turn on Encode Non-ASCII Characters for legacy or unknown-encoding targets — for anything modern it just makes readable output harder to scan for no real benefit.
• Remember this handles text-node escaping specifically, not attribute values, not JavaScript strings, not URLs — each of those needs its own escaping approach.
• Search the reference table by description, not just by symbol, if you know what you want ("em dash", "copyright") but not its exact entity name.

Features

Five Characters Do Almost All the Work

HTML has exactly one character that always needs escaping in ordinary text content: <, because it's the only one a browser's parser treats as the start of something structural rather than literal text. Everything else this tool touches by default — >, &, and (when the switch is on) quotes — is escaped by convention rather than strict requirement, for symmetry and as a safety margin against contexts where it does matter, like inside an attribute value. That distinction is worth understanding rather than memorizing: it's why turning Encode Quotes off doesn't produce broken output for plain text-node content, but would for text about to be dropped into an unquoted HTML attribute.

It's also worth being precise about what "encoding" means here versus in other tools with similar-sounding names. This is character substitution — every unsafe character is replaced with a longer, safe textual stand-in, and the result is still plain text, just longer and uglier to read directly. That's a different operation from Base64 encoding, which represents arbitrary binary data as text for transport, or from compression, which shrinks data. All three get called "encoding" in casual conversation, and confusing them is an easy mistake when skimming documentation quickly.

Decoding Doesn't Guess — It Asks the Browser

A hand-written lookup table, however large, only ever covers the entities someone remembered to include. Decoding here takes a different approach entirely: the encoded text is assigned to a detached <textarea> element's innerHTML, and the browser's own HTML parser — the same one rendering every page you visit — resolves whatever entities are present, correctly, because that's literally its job. That covers all 2,000-plus named character references HTML5 defines, every decimal numeric form, every hex numeric form, with no maintenance required to stay accurate as the spec evolves. The element is never attached to the visible page, so nothing renders and nothing executes — only the resolved text comes back out.

That reliability matters most when the input didn't come from this tool in the first place. A CMS export, a scraped page, or a document pasted from an unfamiliar source can contain any mix of named and numeric entities, sometimes both in the same string, sometimes using an obscure named entity most people have never encountered. A curated table has no way to handle that gracefully; asking the actual parser to do it does, every time.

Encoding Is a Smaller, More Deliberate List

Going the other direction is a different problem. Named-entity encoding only makes sense for entities a person would actually recognize — © is worth using instead of ©, but there's little value in maintaining named forms for characters nobody has memorized anyway. This tool encodes against a curated set of roughly 80 well-known entities — currency symbols, typographic punctuation, common accented Latin letters, a handful of math and arrow symbols — every one of which was individually verified to decode back to the exact original character through the same browser parser described above. Anything outside that set still encodes correctly; it just falls back to a numeric entity, which is exactly as valid and decodes exactly as reliably as a named one.

If it matters exactly which characters ended up encoded and which didn't — checking a template change didn't accidentally alter escaping behavior, say — encode both versions and compare them in the Text Diff Checker rather than eyeballing two long strings of entities side by side.

What This Actually Protects Against

HTML entity encoding is a genuine, necessary defense against cross-site scripting — but only for one specific job: neutralizing markup inserted into an HTML text node, so <script> in a comment field displays as text instead of executing. It is not a universal escaping mechanism. Text inserted unquoted into an attribute, into a <script> block, into a URL, or into a CSS value each has its own injection risks and its own correct escaping method — HTML entity encoding doesn't cover any of those. Knowing which context a piece of text is headed into, and escaping for that specific context rather than assuming one method covers everything, is the actual skill; this tool handles the text-node case correctly and completely, which is real and important, without pretending to be the whole answer.

A Comment Field Is the Everyday Case

User-submitted text — a comment, a review, a bio field — is the most common place this actually matters: someone types an ampersand, a quote mark, or literal angle brackets while describing an HTML tag, and without encoding, that input either breaks the page's layout or, worse, gets interpreted as real markup. The fix is the same one this tool applies by default — encode before display, decode only when you specifically need the raw text back, such as pre-filling an edit form with content that was previously encoded for display. Multi-line submissions add one more wrinkle: a raw newline has no visual effect in rendered HTML, which is exactly the gap Convert Line Breaks to <br> closes, turning a paragraph break the user typed into one the browser actually shows. If the source content mixes in raw HTML that needs cleaning up structurally rather than escaping — closing an accidentally-left-open tag, fixing indentation — that's a job for the HTML Beautifier instead, applied before or after entity encoding depending on which the input actually needs. And if the same value is ever going to travel through a URL as well as display on a page, the URL Encoder & Decoder handles that separate, unrelated layer of escaping — the two are not interchangeable, and applying the wrong one in the wrong place is a fast way to end up with doubly-broken output that neither tool alone can fix.

Frequently Asked Questions