¿Por Qué las URL No Pueden Contener Cualquier Carácter?

Una URL es, por diseño, una secuencia restringida de caracteres ASCII seguros. Los motivos son históricos y prácticos a la vez: los primeros protocolos de red interpretaban ciertos bytes como instrucciones de control, y hasta hoy caracteres como ?, &, =, # y / tienen funciones estructurales dentro de una URL. Si tu dato contiene esos caracteres, debe codificarse para no confundirse con la estructura.

Ese mecanismo se llama percent encoding (codificación porcentual): cada carácter problemático se sustituye por un % seguido de su valor hexadecimal. Un espacio se convierte en %20; una ñ en UTF-8 son dos bytes (C3 B1) que se representan como %C3%B1.

Anatomía de una URL: Dónde Codificar Importa

No todas las partes de una URL admiten los mismos caracteres:

• Esquema y dominio (https://ejemplo.com): reglas estrictas propias; casi nunca manipulas estos manualmente.
• Ruta (/buscar/productos): admite / como separador pero otros especiales deben codificarse. Los slugs limpios evitan el problema de raíz.
• Query string (?q=café&orden=precio): aquí ocurre el 95% del encoding real. Cada valor de parámetro debe codificarse completo; fíjate que el & separador jamás se codifica, pero un & dentro de un valor siempre.
• Fragmento (#seccion): viaja solo del lado del cliente; los navegadores suelen manejarlo solos.

%20 vs +: La Confusión Eterna

Ambos representan un espacio... en contextos distintos. El percent encoding oficial dice %20. Pero los formularios HTML clásicos (content-type application/x-www-form-urlencoded) codifican espacios como +. Por eso:

• https://buscador.com?q=caf%C3%A9+con+leche — típico de formularios GET; el servidor interpreta + como espacio.
• https://api.com/items?nombre=caf%C3%A9%20con%20leche — típico de APIs REST modernas donde + podría interpretarse literalmente como signo más.

Bug clásico: enviar valores con + a una API que espera percent encoding puro. La API recibe literalmente "café+con+leche" con los símbolos incluidos. Cuando construyas URLs programáticamente, usa las funciones estándar de tu lenguaje y este tipo de bug desaparece.

encodeURIComponent vs encodeURI en JavaScript

JavaScript ofrece dos funciones que confunden a todos al inicio:

• encodeURIComponent(valor): codifica TODO lo especial incluyendo / ? & = #. Es la correcta para valores individuales de parámetros: ?url=" + encodeURIComponent(miUrl).
• encodeURI(urlCompleta): preserva los caracteres estructurales de la URL (/ ? # &) y solo codifica lo demás. Sirve para sanear una URL completa que ya tiene estructura válida, no para codificar valores.

Regla mnemotécnica: si estás codificando algo que va dentro de un parámetro, encodeURIComponent. Si codificas una URL entera para usarla como valor de otro parámetro (parámetro redirect, por ejemplo), ¡necesitas encodeURIComponent doble!: primero codifica la URL interna y esa cadena resultante vuelve a codificarse como parte del query string externo.

Depurar URLs Codificadas Sin Sufrir

Los webhooks de pasarelas de pago, los links de email marketing y los logs de servidores están llenos de URLs ilegibles tipo ?data=%7B%22pedido%22%3A%2212345%22%7D. Decodificarlas revela el JSON original: {"pedido":"12345"}.

El flujo rápido con nuestro URL Encoder/Decoder online: pega la cadena codificada, selecciona Decode, y lee el resultado legible al instante. Todo local en tu navegador, relevante cuando las URLs contienen tokens de sesión o datos de clientes que no deberían pegarse en sitios de terceros.

Cuando decodifiques, ojo con el doble encoding: si ves %2520, eso es %20 codificado otra vez (%25 = %). Deberás decodificar dos veces. Es el síntoma típico de aplicar encodeURIComponent sobre algo ya codificado.

Checklist Final

1. ¿Codificas cada valor de parámetro individualmente? (nunca la URL completa con sus separadores)
2. ¿Usas encodeURIComponent para valores y reservas encodeURI para URLs completas preexistentes?
3. ¿Tu servidor distingue + de %20 según el contexto del cliente?
4. ¿Verificas los webhooks decodificándolos antes de parsear a ciegas?

Si alguna respuesta fue "no", ahora sabes exactamente dónde mirar. Y para verificaciones rápidas, el URL Encoder/Decoder te da el resultado en un clic.