¿Cuál es la diferencia entre encodeURI y encodeURIComponent?

encodeURI deja los caracteres reservados de URL (como / : ? &) sin cambios — úsalo en una URL completa. encodeURIComponent los codifica — úsalo en valores que insertas dentro de una URL.

¿Cuándo debo codificar una URL vs. un componente de URL?

Codifique la URL completa cuando conserve la estructura de una URL existente. Use la codificación de componentes al construir una URL con valores proporcionados por el usuario (p. ej., consultas de búsqueda, URLs de devolución de llamada).

¿Qué caracteres son siempre seguros en las URLs?

Los alfanuméricos (A-Z, a-z, 0-9) y - _ . ~ están reservados y nunca necesitan codificación.

Codificador / Decodificador de URL

Acerca de esta herramienta

Codifique cadenas para uso seguro en URLs (codificación porcentual) o decodifique cadenas codificadas en URL de vuelta a texto sin formato. Dos modos: URL completa y componente (encodeURIComponent).

Cómo usar

1 Pegue su URL o valor de parámetro de consulta en la entrada.
2 Elija el modo: URL completa (encodeURI) conserva la estructura de la URL; Componente (encodeURIComponent) codifica todo incluidos & y =.
3 El resultado codificado o decodificado aparece al instante.
4 Haga clic en Copiar para usar el resultado.

Why URLs need encoding at all

A URL is not free-form text. It is a structured string in which a small set of characters carry special meaning: / separates path segments, ? begins the query string, & separates query parameters, = binds a parameter name to its value, and # marks a fragment. The moment your data contains one of those characters — or a space, or an accented letter, or an emoji — you have a problem. If a search term is literally black & white, dropping it raw into ?q=black & white would make the browser think white is a second parameter and the space is a malformed break. Percent-encoding solves this by replacing any unsafe character with a % followed by its byte value in hexadecimal.

How percent-encoding works

Each character is first expressed in UTF-8 bytes, and each byte that is not "safe" becomes % plus two hex digits. A space (byte 0x20) becomes %20. An ampersand (0x26) becomes %26. Characters outside ASCII produce multiple bytes: the copyright sign © is two UTF-8 bytes, 0xC2 0xA9, so it encodes to %C2%A9. Decoding simply reverses this — it reads each %XX group back into a byte and reassembles the original text.

A fixed set of characters are never encoded because they are always safe. These unreserved characters are the letters A–Z and a–z, the digits 0–9, and the four marks - _ . ~. Everything else is fair game depending on which mode you use.

The two modes, and why the difference matters

This tool exposes the exact behaviour of the browser's two native functions, encodeURI and encodeURIComponent.

Mode	Function	Leaves alone	Use for
Full URL	`encodeURI`	`/ : ? & = # @ + $ , ;`	An entire, already-built URL
Component	`encodeURIComponent`	only unreserved chars	One value going inside a URL

The Full URL mode assumes the string is a complete address whose structural characters must survive, so it deliberately does not encode / or ?. The Component mode assumes the string is a single piece of data — a name, a search query, a redirect target — that must not be allowed to disrupt the surrounding URL, so it encodes the structural characters too.

A worked example

Suppose you are building a search link and the query is café & bar?. Choose the wrong mode and the URL breaks. In Component mode the value becomes caf%C3%A9%20%26%20bar%3F — the accented é turns into its two UTF-8 bytes %C3%A9, the space into %20, the ampersand into %26, and the question mark into %3F. You can safely paste that into https://example.com/search?q=caf%C3%A9%20%26%20bar%3F. In Full URL mode the same input keeps the ? and & literal, which would corrupt the parameter — proof that you must encode values with the Component mode, not the Full mode.

Common mistakes

Encoding a full URL with Component mode. This mangles https:// into https%3A%2F%2F and the link stops working. Component mode is for the value, not the address.
Double-encoding. Running already-encoded text through the encoder again turns %20 into %2520 (because the % itself gets encoded). If you see %25 where you expected a space, something encoded twice.
Forgetting the plus sign. In query strings some servers treat + as a space, a relic of HTML form encoding. Percent-encoding uses %20 for a space and leaves + as a literal plus. If a space round-trips into a +, you are looking at form encoding, not URL encoding.
Assuming spaces are always %20. They are in URL encoding, but in the application/x-www-form-urlencoded body of a POST request a space is often + instead.

Practical uses

You will reach for URL encoding whenever user input meets a URL: building search and filter links, passing a return-to address through an OAuth login (?redirect_uri=...), embedding a pre-filled email or tweet, constructing API request strings, or storing a value in a query parameter that might contain punctuation. Decoding is just as common — reading a redirect target out of a link, debugging why an analytics parameter looks like gibberish, or recovering the human-readable form of a logged URL.

Runs entirely in your browser

This tool calls the browser's built-in encodeURI, encodeURIComponent, decodeURI, and decodeURIComponent functions directly. Nothing you type is sent to a server — the conversion happens on your device as you type, which means it works offline and your URLs and query values stay private.