Developer Tools New Tool

Free Online HTML Entity Encoder and Decoder

Turn text into HTML entities or turn entities back into text, both directions on one page. Encode only the five characters that matter, use named entities where they exist, or write everything non-ASCII as decimal or hex references. Decoding reads named, decimal and hex forms, and the legacy ones missing a semicolon.

Free Forever Nothing Uploaded No innerHTML decoding Runs in your browser

Free Online HTML Entity Encoder and Decoder

Advertisement Slot (Top Banner) Google AdSense Unit • Responsive Banner

HTML Entity Encoder & Decoder Everything happens in this tab. Nothing you paste is sent anywhere.

Your text

Result

Direction This page should Encode Write the apostrophe as '

0 characters in 0 out 0 replaced

Reference Search Click a row to put it in the input box.

Character	Name	Decimal	Hex	What it is

Buy Us A Coffee

Enjoying WizTools123? Help keep our server infrastructure 100% free and open for everyone.

Buy Us A Coffee

Sponsored Content (Below Tool) Google AdSense Placement

Why This Page Does Not Decode With innerHTML

The one-line trick that turns a decoder into a hole.

There is a well known shortcut for decoding entities in a browser: make an element, set its innerHTML to the text, and read back textContent. It is three lines and it handles every entity the browser knows, which is all of them. It is also an XSS hole the moment the text is not yours.

The reason is that innerHTML does not decode a string, it parses HTML. Give it <img src=x onerror=alert(1)> and the browser builds an image element, tries to load x, fails, and runs the handler. Script tags inserted that way do not run, which is what makes people think the trick is safe, but event handlers on other elements do, and so do a dozen other constructions. On a page where the input is pasted by the person using it the damage is limited to themselves; in a shared component, or anywhere the text arrived from a URL, a database or another user, it is a real vulnerability.

So the decoding here is done the long way: a table of names to code points, written into the page, and a scan that replaces one reference at a time. It costs a few hundred lines and it cannot run anything, because nothing is ever handed to the HTML parser. Use DOMParser with text/html if you need the browser's own table in your own code, and never innerHTML on text you did not write.

How to Encode and Decode HTML Entities

A few steps, and nothing is uploaded.

Pick a direction Encode text into entities, or decode entities back into text. The page runs as you type, with no button to press.

Choose how much to encode Only the five that matter is right for almost all HTML. Named entities are friendlier to read. Full numeric output is for places where the encoding of the file itself is in doubt.

Or paste entities in Decoding handles named references, decimal such as ©, hex such as ©, and the legacy forms that are missing their semicolon.

Use the table Search the entities people actually look up, by name, by number or by description, and click a row to drop it into the input box.

What to Know About HTML Entities

Including why decoding with innerHTML is a bad idea.

Decoding here is done from a table, not by setting innerHTML. The usual three-line trick, assigning text to an element's innerHTML and reading textContent, hands untrusted text to the HTML parser. <img src=x onerror=...> runs code that way, which is how a decoder becomes an XSS hole. Nothing on this page is ever parsed as HTML.

' is safe in HTML5 and was not defined in HTML4, while ' always works. HTML4 defined no name for the apostrophe, so ' failed in older documents and still fails in XHTML served as XML in some parsers. The numeric reference ' has always worked everywhere. That is why the numeric form is the default here and the named one is a switch.

The named set here is the classic 252, not all 2,231 names HTML5 defines. The HTML5 entity list is mostly mathematical aliases, and shipping it would add a large table to the page for names almost nobody types. Encoding uses the HTML4 set, which covers Latin-1, Greek, arrows, common maths and punctuation, and falls back to a numeric reference for anything else. Decoding accepts the same set of names, plus any decimal or hex reference at all.

Encoding cannot make unsafe markup safe on its own. Escaping the five characters is the right defence for text placed in element content or in a quoted attribute. It does nothing for text put into a URL, into a script block, into a style block or into an unquoted attribute, where the rules are different and escaping the wrong five characters gives you false confidence. Encode for the context you are writing into.

Key Features & Capabilities

What this tool does, and what it deliberately does not.

Four encoding modes The five essentials, named entities, or all non-ASCII as decimal or hex.

Decodes all three forms Named, decimal and hex references, with or without the semicolon.

No innerHTML anywhere Decoding runs off a table in the page, so nothing can execute.

A reference you can search The entities people look up, with character, name, decimal and hex.

As you type No run button. The result and the counts update while you edit.

Runs in your browser Nothing is uploaded. The page works with the network off.

About the HTML Entity Tool

Entities exist because a few characters mean something to the HTML parser and cannot be written literally in text. In practice there are five of them, and everything else is either an old habit from the days of uncertain file encodings or a way of typing a character your keyboard does not have. Both directions of the conversion are needed constantly: escaping text on the way into a page, and cleaning up text that has been escaped twice on the way out of one.

This page does both, with the amount of encoding under your control. The five-character mode is what a template engine does and what you almost always want. The named mode is for hand-written HTML where a reader may open the source. The numeric modes exist for files whose encoding is not certain, where every non-ASCII character becomes a pure ASCII reference and the file survives any transport.

The decoding is the part that took care, and not because entities are hard. The obvious way to decode them in a browser is to let the browser do it through innerHTML, and that is a genuine security hole on untrusted text, so this page builds its own table instead and scans the string by hand. It costs more code, it is limited to the names in that table, and it cannot execute anything, which is the trade worth making.

Frequently Asked Questions

The five that matter, apostrophes, numeric forms and missing semicolons.

In element content, the ampersand and the less-than sign. In a quoted attribute value, also the quote character you used. Most guidance says five, adding the greater-than sign and the apostrophe, which is harmless and gives one rule that is safe in both places. Encoding more than that is a style choice, not a security measure.

Because it was encoded twice. Something escaped the ampersand of a real entity, turning into  , so the browser now shows the text of the entity rather than acting on it. Decode it once here and you get back; decode again and you get the space. Double encoding almost always means two layers both trying to be safe, such as a template that escapes output and a database field that was already escaped when it was stored.

Use ' unless you know the document is HTML5. HTML4 never defined the name apos, so old documents and some XML parsers do not understand it, while the numeric reference has always been universal. This page writes the numeric form by default and offers the named one as a switch for that reason.

Yes, for the older names, which is the same thing browsers do. © without a semicolon decodes, because that name is part of the legacy set every parser still accepts. A newer name such as &hellip requires its semicolon, and so does any numeric reference in strict mode. You can turn the loose behaviour off if you want to see exactly what a strict parser would refuse.

No. The encoding and decoding both happen in your browser, from a table written into the page, and no request is made. That also means nothing is parsed as HTML at any point, which is the reason this decoder cannot be used against you. You can confirm it in the Network tab, or by turning your wifi off and using the page anyway.