¿Por qué un espacio se convierte en %20 o +?

%20 es la codificación estándar por porcentaje para un espacio. La convención "+" viene de un estándar de codificación de formularios más viejo (application/x-www-form-urlencoded) y solo es válida en ese contexto específico, no en URLs generales.

¿Debería codificar una URL entera de una vez?

No — codifique solo valores de parámetros individuales, no la URL completa, o va a codificar por accidente caracteres estructurales como "://" y "?" que necesitan quedar tal cual.

URL Encoder / Decoder

Input

Output

How to use this URL encoder/decoder

Paste text, a URL, or a query string into the input box.
Choose "Encode" to percent-encode special characters, or "Decode" to reverse it.
The result updates instantly on the right.

What is URL encoding?

URL (percent) encoding replaces unsafe or reserved characters — spaces, ampersands, question marks — with a "%" followed by their hex code, so they can be safely included in a URL's query string without breaking its structure.

Why does a space become %20 or +?

%20 is the standard percent-encoding for a space. The "+" convention comes from an older form-encoding standard (application/x-www-form-urlencoded) and is only valid in that specific context, not general URLs.

Should I encode an entire URL at once?

No — encode only individual parameter values, not the full URL, or you'll accidentally encode structural characters like "://" and "?" that need to stay as-is.

Reserved versus unreserved characters, per RFC 3986

The URI specification, RFC 3986, formally divides characters into two categories that explain exactly why encoding is necessary at all. Unreserved characters — letters, digits, and a handful of symbols like -, _, ., and ~ — are always safe to use literally anywhere in a URL, since they carry no structural meaning. Reserved characters — like /, ?, #, &, =, and : — do carry structural meaning: they're what separate a URL's path from its query string, one query parameter from another, or a fragment from the rest of the URL. When a reserved character needs to appear as literal data rather than as a structural delimiter — an ampersand inside a search query, for instance — it must be percent-encoded so the URL parser doesn't mistake it for a delimiter it isn't meant to be.

encodeURIComponent versus encodeURI — a distinction that causes real bugs

JavaScript actually provides two different built-in encoding functions, and mixing them up is a genuinely common source of broken URLs. encodeURIComponent encodes aggressively, escaping every reserved character including /, ?, &, and = — making it the correct choice specifically for encoding one individual value that will be inserted into a URL, like a single query parameter's value. encodeURI encodes far less, deliberately leaving structural characters like /, ?, and & untouched, because it's meant for encoding an entire, already-structured URL, where those characters need to remain functional as delimiters. Using encodeURI on a single parameter value fails to escape characters that need escaping there, and using encodeURIComponent on a whole URL mangles its own structure — the two functions are not interchangeable despite their similar names.

The double-encoding trap

Double encoding happens when already-percent-encoded text gets encoded a second time, and it's a surprisingly common, hard-to-spot bug. If "%20" (an encoded space) is encoded again, the "%" character itself gets encoded into "%2520" — because the encoder has no way to know that "%20" was already meant to represent something, and simply treats the literal "%" character as data needing its own escaping. This typically happens when a value is encoded once by application code and then encoded again by a framework, library, or browser that automatically encodes form or URL data, without anyone realizing encoding is happening twice in the pipeline. The telltale sign of double encoding is spotting a literal "%25" in a decoded value — that's a "%" that has itself been percent-encoded, revealing the value was encoded more than once.

Why percent-encoding operates on bytes, not characters

A detail that surprises people working with non-ASCII text: percent-encoding fundamentally encodes bytes, not characters directly, which matters a great deal once Unicode text is involved. A single accented or non-Latin character is typically represented as multiple bytes in UTF-8 encoding, and each of those individual bytes gets its own separate "%XX" escape sequence — so one visible character in your original text can expand into two, three, or even four consecutive percent-encoded triplets in the output. This is exactly why encoded non-English text looks considerably longer and more cryptic than encoded plain ASCII text of similar visible length — it isn't inefficiency in the encoding, it's a direct, faithful reflection of how many actual bytes that character occupies in UTF-8.

Limitations of this tool

This tool uses standard percent-encoding (via JavaScript's built-in encodeURIComponent/decodeURIComponent), matching modern URL and query-string conventions — it does not apply the older application/x-www-form-urlencoded convention where spaces become "+" rather than "%20", which is specific to HTML form submissions rather than general URLs. It encodes and decodes the text you provide as a single unit rather than intelligently parsing a full URL into its separate components (protocol, host, path, individual query parameters) — for encoding a complete URL correctly, encode each parameter value separately before assembling the full URL, as covered above.