HTML entitás kódoló / dekódoló

Encode and decode HTML entities online

This HTML entities tool combines three jobs in one place: it encodes text into HTML entities, decodes entities back into readable text, and gives you a searchable HTML entities list you can copy from. Type or paste into the left pane and the converted result appears live on the right — switch between encode and decode, swap the two panes, and copy the output in a single click.

Everything runs locally in your browser, so the text you convert is never uploaded to any server. There's nothing to install, no account to create, and no usage limits. Reload the page while offline and it still works — because there's no server call happening at any point.

What HTML entities are and why they matter

An HTML entity is a short code that stands in for a character. It always begins with an ampersand and ends with a semicolon — for example & represents an ampersand and   represents a non-breaking space. Entities exist for two reasons. First, a few characters are reserved in HTML: a raw <, > or & can be read as markup and break your page, so they are written as <, > and & instead.

Second, entities let you include special characters — accents, currency signs, maths symbols and arrows — that may be hard to type or might not survive a change of text encoding. Escaping reserved characters is exactly what stops a stray < from breaking a layout or a snippet of user input from turning into an unwanted tag. This is fundamental to web security and the reason sanitizing user input always involves HTML entity encoding.

Named, decimal and hexadecimal entities

Every character can be written three ways. A named entity uses a readable keyword — © for the copyright sign ©. A decimal numeric entity uses the character's Unicode code point in base 10 — ©. A hexadecimal entity uses base 16 — ©. All three produce the same ©.

Named entities read best, but only around 2,200 characters have HTML5 names. HTML4 only defined about 255. The expanded HTML5 named character reference standard added hundreds more — mathematical operators, arrows, and typographic symbols that weren't available before. Numeric entities (decimal or hex) cover every Unicode character, including all emoji. When you encode, pick the output form that fits your context: named for readability in source code, decimal or hex when you need a guaranteed code for any character.

A searchable HTML entities list — arrows, symbols and more

Below the converter is a full, grouped HTML entities list covering punctuation, arrows, currency, maths and Greek letters. Search by name, symbol or number — type 'arrow' to find → (→), 'euro' for € (€) or '38' for the ampersand — then click any cell to copy the symbol, the named entity, the decimal code or the hex code.

It's the fastest way to grab the right HTML character codes without memorising them or hunting through a static reference page. The list covers the complete HTML5 named character reference standard — over 2,200 entries — significantly more than the roughly 255 entities on W3Schools or the HTML4-only partial tables on FreeFormatter. If you work regularly with mathematical notation, typographic symbols, or extended Latin characters, this list has them all.

How this compares to FreeFormatter, W3Schools, and MDN

Most HTML entity resources are static reference pages. W3Schools, MDN's character reference, and FreeFormatter.com all list entities you can look up manually. None of them let you paste a block of text and encode or decode the whole thing in one shot. FreeFormatter's entity encoder is the closest alternative, but it sends your text to their server for processing, requires a form submit and page reload, and only covers HTML4 entities.

This tool does everything in one page, instantly, client-side: encode a paragraph of text, switch to decode, then search the entity list — all in the same tab with no round-trips. It also covers the full HTML5 named character reference set rather than just HTML4, which matters when working with modern content that includes typographic symbols, arrows, or mathematical notation. And since everything runs locally, you can encode private content — internal docs, email templates, unreleased copy — without it ever reaching a third-party server.

Private, instant and free — works offline too

Every conversion — encoding, decoding or copying from the entity list — happens locally in your browser using JavaScript, so even confidential markup never leaves your device. There is no server, no login, and no rate limit. The tool works the same whether you have a fast connection, a slow connection, or no connection at all after the initial page load.

Compare that to tools like FreeFormatter.com or online HTML validators that require a network request for every conversion. For developers working on client projects or internal tooling, running the encoding locally means your markup never hits a third-party server. Bookmark this as your go-to HTML entity converter and reference — for escaping HTML, looking up character codes, or decoding encoded markup from a source file or database dump.

The history of HTML entities: from SGML to HTML5

HTML was originally derived from SGML (Standard Generalized Markup Language), a document meta-language standardised in ISO 8879:1986. SGML defined a character entity reference system from the outset, and HTML inherited it directly. The reason entities were necessary at all is rooted in a fundamental constraint of the early web: HTML source documents had to consist of printable ASCII characters. If an author needed to display a literal < character on a page, the HTML parser would read it as the start of a tag — so a stand-in code was required. Named entities like < and & solved that problem by giving authors a way to write a reserved character in source without triggering parser behaviour.

HTML entities fall into three categories. Named entities use a human-readable keyword between an ampersand and a semicolon — &, <, >, ", '. Decimal numeric references use the character's Unicode code point in base 10, such as < for <. Hexadecimal numeric references use base 16, such as < for the same character. All three resolve to the identical rendered output. Named entities are more readable but only exist for a subset of Unicode; numeric references cover every code point without exception, including all emoji and supplementary-plane characters.

The gap between XML and HTML entity handling is worth understanding. XML defines exactly five predefined entities — &, <, >, ", and ' — and any other named entity must be declared explicitly in a DTD before it can be used. HTML, by contrast, has hundreds of built-in named entities defined directly in the specification: HTML4 standardised around 255, and HTML5 expanded that to over 2,200 named character references, covering mathematical operators, arrows, typographic symbols, and extended Latin characters that weren't available in earlier versions of the standard.

Unicode, UTF-8, and which entities you still actually need

When the HTML entity system was designed, ASCII was the dominant encoding. To include a character outside the 128-character ASCII range — a copyright sign, a Euro symbol, a Greek letter — you either needed a named entity or a numeric reference, because the underlying bytes had no reliable interpretation across different systems and locales. The introduction of Unicode and, critically, the near-universal adoption of UTF-8 as the web's encoding, changed the calculation entirely. UTF-8 can represent every one of the 1.1 million Unicode code points as a byte sequence, and virtually every modern web server, browser, database, and text editor handles it natively.

On a UTF-8 page — declared with <meta charset="UTF-8"> in the document head — you can embed any Unicode character directly in the HTML source. The copyright symbol ©, the trade mark sign ™, the Euro sign €, the infinity symbol ∞, and the greater-than-or-equal-to sign ≥ can all appear as literal characters without any encoding. The browser reads the charset declaration, uses it to interpret the bytes it receives, and renders the characters correctly. This means that the vast majority of entities people reach for — ©, ™, €, ∞ — are entirely optional on a modern UTF-8 page; the literal character is preferred for readability and easier maintenance.

Only five characters genuinely require encoding in HTML, and only in specific contexts: the ampersand & (as &) in text and attribute values, the less-than sign < (as <) in text content, the greater-than sign > (as >) in text content, the double quote " (as ") inside double-quoted attribute values, and the single quote ' (as ' or ') inside single-quoted attribute values. Everything else is optional. A page dense with   and named entities for every accented character is harder to read and edit than one with literal UTF-8 — the maintenance burden of over-encoded HTML is real, and modern tooling gives no advantage to it.

HTML escaping and XSS: why correct encoding is a security requirement

Cross-Site Scripting (XSS) consistently ranks in the OWASP Top 10 most critical web application vulnerabilities. An XSS attack occurs when user-supplied input is rendered as HTML without proper escaping. A classic injection payload looks like <script>alert(document.cookie)</script>. If that string is stored in a database and later emitted directly into an HTML page without escaping, the browser executes it as a script — potentially stealing session cookies, redirecting the user, or performing actions on their behalf. The defence is correct HTML entity encoding at the point of output: the same < that breaks a layout if unencoded becomes the harmless literal text < once escaped, and the browser never interprets it as markup.

The critical nuance is that different rendering contexts require different escaping strategies. In an HTML text context (between tags), encode <, >, and &. In an HTML attribute value context, also encode the surrounding quote character — " or ' — otherwise an attacker can close the attribute and inject new attributes such as onmouseover. In a JavaScript string context (inside a <script> block), HTML entity encoding is not sufficient — you need JavaScript string escaping (\uXXXX sequences) or JSON.stringify, because the JavaScript engine processes the string before the HTML parser does. In a URL context (inside an href or src), the correct escaping is percent-encoding (%20 for a space), not HTML entities — confusing the two is a common source of broken links and unfixed injection points.

The OWASP XSS Prevention Cheat Sheet is the authoritative reference for these context-specific rules. The practical takeaway for most developers is to rely on a framework or template engine that auto-escapes by default — Django's template language converts {{ variable }} to HTML-safe output automatically and requires an explicit {{ variable|safe }} to pass raw HTML through; Jinja2 behaves the same way; React's JSX escapes all string values before rendering them to the DOM. Understanding what your framework does by default, and when it does not escape, is the single most important thing you can know about XSS prevention. Manual entity encoding with a tool like this one is valuable when you're working outside a framework — writing raw HTML templates, generating markup in a build script, or constructing HTML strings in JavaScript.

HTML entities in email, template engines, and XML feeds

HTML email is the context where entity encoding remains most important even in 2024. Email clients use a wide range of rendering engines — Gmail strips and re-renders HTML through its own sanitiser, Outlook on Windows uses Word's rendering engine (not a browser), Apple Mail uses WebKit — and their UTF-8 support and character handling vary considerably. Writing — instead of a literal em dash, or © instead of ©, ensures the character renders correctly across clients that may misinterpret or strip high-code-point bytes. Outlook's rendering engine in particular has known issues with certain Unicode characters and is far more tolerant of named entities, which is why professionally produced email HTML tends to use entity-heavy markup that would be considered unnecessary on a web page.

Rich text editors such as CKEditor and TinyMCE often produce entity-heavy HTML output by default, encoding characters that would render fine as literal UTF-8 in a modern browser. This is a legacy behaviour inherited from an era when encoding assumptions couldn't be trusted. Some content management systems store this entity-encoded HTML in the database and later emit it through a template layer that also auto-escapes — resulting in double-encoding, where a user types an ampersand, the editor writes &, the CMS stores that, and the template engine then escapes it again to &, which is what the user sees on the page. Recognising double-encoding is straightforward: paste the visible output into the Decode pane here and decode once — if the result still contains entity codes instead of plain characters, decode again. The fix is to mark the value as pre-escaped at the template layer, not to decode it at read time.

When HTML is embedded inside XML documents — RSS and Atom feeds, SVG files, XHTML served as application/xhtml+xml — the XML parser applies stricter rules than an HTML parser. XML only recognises five predefined entities and treats any unknown named entity as a fatal parse error. If your Atom feed contains — without a DTD declaration, a conformant XML parser will reject the entire document. The correct approach is either to use numeric entities (— for an em dash) which XML parsers accept universally, or to include the literal UTF-8 character directly, since XML requires UTF-8 or UTF-16 and both handle the full Unicode range. This distinction matters most when generating feed XML programmatically: string-replacing characters with named HTML entities is a common mistake that breaks feed validators and aggregators.