Herramientas Guías
developer Gratis Sin registro

Codificador / Decodificador de URL

Codifique caracteres especiales a entidades HTML y decodifique entidades de vuelta a texto plano — admite entidades con nombre y numéricas.

Cargando la herramienta…

Acerca de esta herramienta

Convierta texto con caracteres especiales (&, <, >, ", ') a entidades HTML seguras para incrustar en páginas web, y decodifique cadenas de entidades HTML de vuelta a texto legible. Admite entidades con nombre (&amp;), decimal (&#38;) y hexadecimal (&#x26;) de codificación.

Cómo usar

  1. 1 Codificador / Decodificador Base64
  2. 2 Pegue su texto en el campo de entrada.
  3. 3 Seleccione el estilo de codificación: entidades con nombre, decimal o hexadecimal.
  4. 4 Haga clic en Copiar para copiar el resultado.

What HTML entities are and why they exist

HTML reserves a few characters to mean something structural. The browser reads < as the start of a tag, > as its end, and & as the beginning of an entity reference. If those characters appear literally inside your content, the browser tries to interpret them as markup, and your page breaks — or worse, an attacker can inject their own tags. An HTML entity is the safe stand-in: a coded sequence that the browser renders as the original character without treating it as markup. This tool converts text to entities (encoding) and turns entities back into readable characters (decoding).

The three ways to write the same character

Every character has more than one valid entity form, and this encoder supports all three:

FormExample for & (ampersand)How it is built
Named&amp;A human-readable name, available for common characters
Decimal numeric&#38;The character's Unicode code point in base 10
Hexadecimal numeric&#x26;The same code point in base 16

All three render identically in any browser — 38 in decimal is 26 in hexadecimal, and both point to the same Unicode character. Named entities like &copy; or &mdash; are easiest to read, but they only exist for a defined set of characters. Numeric forms work for any character, which is why they are the fallback when no name exists. The hex form is common in CSS and Unicode tables; the decimal form reads more naturally to most people.

How encoding decides what to touch

By default the encoder leaves ordinary text alone and only converts the characters that actually need it — the markup-significant ones (&, <, >, ", ') plus a set of common symbols like ©, , , , and arrows. Plain ASCII letters and digits pass through untouched, keeping the output readable. If you tick Encode all chars, every single character is converted to an entity, including normal letters. That maximal form is occasionally used to obscure an email address from naive scrapers or to guarantee a character set survives a fussy pipeline, but for everyday use the default selective encoding is what you want.

A worked example

Suppose a user types a comment: Tom & Jerry <3 "pizza" and you need to display it safely on a page. Paste it into the input with Named encoding selected and you get:

Tom &amp; Jerry &lt;3 &quot;pizza&quot;

The ampersand became &amp;, the less-than became &lt;, and the double quotes became &quot;. Dropped into your HTML, the browser renders the original text exactly as the user typed it — and crucially, the <3 can no longer be mistaken for the start of a tag. Switch the radio to Decimal and the same input yields &#38;, &#60;, and &#34; instead; the rendered result is identical.

Decoding: turning entities back into text

Click Decode and the tool runs the process in reverse. It recognises named entities, decimal references like &#169;, and hexadecimal references like &#x2122;, converting each back to its character. This is useful when you copy a snippet out of a web page's source, an API response, or an email's raw HTML and want the human-readable version. The Swap button moves the output back into the input, so you can encode something, swap, and decode it to confirm you get the original back — a quick way to sanity-check a round trip.

Why this prevents real security bugs

The most common web vulnerability, cross-site scripting (XSS), happens when user-supplied content is inserted into a page without encoding. If a visitor's "name" is <script>steal()</script> and you print it raw, the browser runs that script. Encode it first and the angle brackets become &lt; and &gt;, so the browser displays the text harmlessly instead of executing it. The five characters that matter most for this — &, <, >, ", and ' — are exactly the ones the default encoding always handles.

Tips and common mistakes

  • Always encode the ampersand first. When encoding by hand, convert & before the others; otherwise you can double-encode and turn &lt; into &amp;lt;. This tool handles ordering for you, but it is a classic manual error.
  • Encode for the right context. Entity encoding protects content placed in HTML text and attribute values. Data going into JavaScript, URLs, or CSS needs its own escaping — entities alone are not a universal sanitiser.
  • Prefer named entities for readability. Use names where they exist; reach for numeric forms only for characters without a named version, or when you specifically need hex.
  • Do not over-encode plain text. "Encode all chars" bloats your output and hurts readability; leave it off unless you have a specific reason.

Privacy

Encoding and decoding both run locally in your browser. Whatever you paste — including user data you are sanitising — is processed on your device and never uploaded or stored. The tool works fully offline.

Preguntas frecuentes

{# Alpine.js — self-hosted. (The previous jsdelivr CDN tag had a stale SRI integrity hash, so the browser refused to run it and window.Alpine was never defined — silently breaking every FAQ accordion and Alpine tool.) #}