HTML Encode and Decode

This tool encodes text into HTML character references and decodes them back, entirely in your browser. Named entities like & and < cover the everyday escapes; numeric forms like A and A reach any Unicode character. Strict decode mode reports unknown entities instead of passing them through.

100 % local

L’interface de cet outil est en anglais.

Input0 charsOutput

Entity styleDecode strictness

Le guide ci-dessous n’est disponible qu’en anglais.

HTML gives two characters structural jobs: & begins a character reference, < begins a tag. When those characters appear as text they need escaping, and the mechanism is the character reference: a short, unambiguous spelling such as & that every parser decodes back to the original character.

The standard's list of named references is finite and closed — more than 2,200 spellings — and five carry nearly all the work: & < > " and '. For anything the list does not cover, a numeric reference writes the code point directly: A and A are both the letter A, and the same trick reaches every character Unicode has.

The panel below does both directions: one toggle encodes text into entities, the other decodes them back. Switches pick named or numeric output, and strict or forgiving decode. Like everything on this site, it runs entirely in this tab.

Building links that carry user data is where the two escaping grammars meet, and the URL encoder and decoder handles the percent-encoding half.

Entity escaping is one member of a family of character and byte encodings; the site's encoding tools hub collects the rest, from Base64 to binary.

The five named entities that do almost all the work

Which characters must be escaped depends on context. In text, two are mandatory: a literal & must be written &, because an ampersand followed by letters and a semicolon is how references begin, and a literal < must be written <, because it otherwise opens a tag. The other three are contextual; escaping all five unconditionally costs nothing.

Entity	Writes	Required when
&	&	Always in text — the escape the spec insists on
<	<	In text, before it opens a tag
>	>	Rarely required in text; escaped by habit
"	"	Inside double-quoted attribute values
'	'	Inside single-quoted attribute values

Named versus numeric: two spellings of one character

A numeric reference writes the code point itself: A is decimal for A, A hexadecimal for the same letter — semicolon required in HTML5, x and hex digits case-insensitive. Because the number names the code point directly, the numeric form covers every character Unicode defines, emoji included.

The trade-off is source readability: é tells a human what will render, é does not. The named mode here follows the usual policy: common characters get names ( , —, é as é), the long tail gets numbers. Downstream the distinction disappears — both spellings decode to the same character.

Decode mode, and what strict mode reports

The direction toggle flips the pipeline: paste escaped markup, get plain characters. All three spellings decode — named, decimal and hexadecimal — and the named lookup forgives case, because real-world markup does not agree with itself.

Unknown entities get honest treatment. The converter does not recognise &npsp; — the classic typo of   — and by default leaves it untouched, because text may legitimately contain ampersands. Strict mode exists for markup that claims to be fully escaped: there an unknown entity is a bug, and strict decode reports each one above the output instead of letting a typo survive.

Escaping is the security boundary, not decoration

The reason this conversion matters beyond typography is injection. User-supplied text that lands in a page unescaped is not displayed as text: a literal <script> inside it executes, and an unescaped quote in an attribute value breaks out of the attribute. Escaping turns those bytes into inert characters — <script> renders as readable text and does nothing else.

It is a different job from URL escaping: percent-encoding has its own reserved set and grammar, and the two are not interchangeable — which is why they get separate tools.

Frequently asked questions

Does the encoder send my text to a server?

No. Both directions are string transformations run by JavaScript that loaded with the page; nothing is transmitted. The site's Content-Security-Policy sets connect-src 'self', so the browser itself would refuse an outbound request. Verify either way: DevTools' Network panel stays silent, and the tool keeps working offline.

Which characters actually have to be escaped in HTML?

In text content, two are mandatory: & as & and < as <. A bare > in text is tolerated but escaped by habit, and the quote marks matter only inside attribute values delimited by the same quote. This tool escapes all five unconditionally, so its output is safe everywhere.

What is the difference between named and numeric entities?

A named entity is a label from the standard's closed list — &, ©, é. A numeric reference writes the code point directly, decimal as A or hexadecimal as A. Both decode to the identical character; numeric covers every Unicode code point, named reads better. The difference is for source readers only.

What does strict decode mode catch?

Unknown names and impossible numbers. Strict decode reports entities such as &npsp; — the classic typo of   — and numeric references whose value is not a valid character code. Lenient mode leaves unknown entities untouched.

Do entities affect SEO or screen readers?

No. Entities are decoded during HTML parsing, before the search index or a screen reader ever sees them. The DOM holds the literal character either way, so é and é rank identically and are announced identically. Choose a spelling for the humans reading the source, not for machines consuming the page.

Why does my apostrophe become '?

Because HTML5 defines ' — it was XML-only for years, which is why older references call it risky — and an apostrophe inside a single-quoted attribute is exactly where escaping it is required. For pre-HTML5 consumers, the numeric ' is the form every parser has always accepted.

ToolsByUs team · How we check our tools