BrowserTools
Publicidad
Inicio / Redes / Analizador de URL

Analizador de URL

Descompón cualquier URL en su esquema, host, puerto, ruta, parámetros de consulta y hash, analizado localmente en tu navegador.

Cargando Analizador de URL… Si no ocurre nada, activa JavaScript.

Una URL (Uniform Resource Locator) parece una sola cadena, pero en realidad es un registro estructurado compuesto de varios componentes distintos, cada uno con su propio significado. Una URL completa como https://user:pass@example.com:8443/path/page?q=hello&lang=en#section reúne un esquema, credenciales opcionales, un host, un puerto opcional, una ruta, una query string y un fragmento. Leer esas partes a ojo es fácil de equivocar, sobre todo cuando la query string es larga, contiene caracteres codificados en porcentaje o repite la misma clave más de una vez. Un analizador divide la URL con precisión según las reglas definidas en el WHATWG URL Standard, las mismas reglas que sigue todo navegador moderno.

Preguntas frecuentes

¿La URL que pego se envía a un servidor?
No. El análisis ocurre enteramente en tu navegador usando las API integradas URL y URLSearchParams. La URL que introduces, incluidos los tokens o las credenciales que contenga, nunca se transmite, almacena ni registra en ningún sitio. La herramienta funciona totalmente sin conexión una vez cargada la página.
¿Cuáles son las partes de una URL?
Una URL tiene hasta siete partes: el esquema (como https), userinfo opcional (nombre de usuario y contraseña), el host (un dominio o una dirección IP), un puerto opcional, la ruta, una query string opcional (la parte tras el signo de interrogación) y un fragmento opcional (la parte tras el hash). Para https://example.com:8443/a/b?x=1#top, el esquema es https, el host es example.com, el puerto es 8443, la ruta es /a/b, la consulta es x=1 y el fragmento es top.
¿Por qué el puerto se muestra como predeterminado en algunas URL?
Cuando una URL usa el puerto estándar de su esquema (443 para https, 80 para http), el navegador deja vacío el campo del puerto porque está implícito. Esta herramienta etiqueta ese caso como predeterminado. Si incluyes explícitamente un puerto no estándar como :8443, se muestra exactamente como está escrito.
¿Cuál es la diferencia entre host y hostname?
El hostname es solo el dominio o la dirección IP, por ejemplo example.com. El host incluye el hostname más el puerto cuando hay un puerto no predeterminado presente, por ejemplo example.com:8443. Si no hay un puerto explícito en la URL, host y hostname son idénticos.
¿Cómo se manejan los parámetros de consulta repetidos?
URLSearchParams conserva cada aparición de una clave en orden, así que una query string como a=1&a=2 produce dos filas separadas en la tabla en lugar de fusionarlas. Esto coincide con cómo los servidores y los frameworks suelen recibir los datos, donde las claves repetidas son comunes para filtros de selección múltiple y parámetros tipo array.
¿Decodifica los caracteres codificados en porcentaje en los valores de consulta?
Sí. URLSearchParams decodifica automáticamente en porcentaje tanto las claves como los valores, así que %20 aparece como un espacio y %40 aparece como @ en la tabla. Si necesitas codificar o decodificar un valor para volver a ponerlo en una URL, la herramienta URL Encoder se encarga de esa dirección.
¿Por qué obtengo un error de URL no válida?
El analizador URL nativo requiere una URL absoluta con un esquema, como https://example.com. Las entradas escuetas como example.com/page o las rutas relativas como /page se rechazan porque no hay una base contra la que resolverlas. Añade un esquema como https:// al principio y la URL se analizará correctamente.
¿Puede analizar esquemas no web como mailto o ftp?
Sí, siempre que la entrada sea una URL absoluta válida. Esquemas como ftp, ws, wss, file y mailto se analizan todos, aunque algunos componentes (como el host o el puerto) pueden estar vacíos en los esquemas que no los usan. Los campos mostrados reflejan lo que el estándar URL extrae para ese esquema.

Acerca de Analizador de URL

Esta herramienta usa las API nativas URL y URLSearchParams integradas en tu navegador, así que los resultados coinciden exactamente con cómo un navegador, una llamada fetch o un framework de servidor interpretarían la dirección. Muestra el esquema y el protocolo completo, cualquier nombre de usuario y contraseña incrustados en la autoridad, el host y el hostname, el puerto (o una nota de que se aplica el predeterminado del esquema), el pathname, el origin calculado y el fragmento hash. La query string se desglosa en una tabla limpia de pares de clave y valor, con cada valor copiable individualmente, lo que es mucho más rápido que buscar entre un muro de ampersands y signos de igual.

Todo se ejecuta localmente en tu navegador. La URL que pegas nunca se sube, registra ni envía a ningún servidor, así que es seguro inspeccionar enlaces que contengan tokens de acceso, identificadores de sesión, parámetros firmados u otros valores de consulta sensibles. Los desarrolladores recurren a un analizador de URL al depurar redirecciones, URL de retorno de OAuth, la sopa de parámetros de seguimiento de las campañas de marketing, endpoints de API con muchas opciones de consulta o enlaces profundos en apps móviles. Si la entrada no es una URL absoluta válida, la herramienta muestra un error claro en lugar de adivinar.

El estándar de URL en el que nadie se puso de acuerdo durante décadas

Las URL fueron formalizadas por primera vez por Tim Berners-Lee en el RFC 1738 allá por 1994, pero durante años después cada navegador, biblioteca y lenguaje las analizaba de forma ligeramente diferente. Los casos límite como las barras invertidas, los espacios al principio y al final, los dos puntos colocados de forma extraña y la codificación en porcentaje en el host causaban auténticos fallos de seguridad, porque un analizador en el servidor y un analizador en el navegador podían discrepar sobre a qué host apuntaba realmente una URL. Los atacantes explotaban esas discrepancias para colarse más allá de las listas de permitidos de URL y desencadenar falsificaciones de solicitud del lado del servidor.

Para acabar con el caos, el WHATWG publicó el URL Standard, una especificación viva que define el análisis como una máquina de estados precisa y no como una gramática laxa. Es crucial que la especificación se escribiera para describir lo que los navegadores hacen realmente, incluidas sus rarezas, de modo que el algoritmo sea interoperable por construcción. Las clases URL y URLSearchParams expuestas a JavaScript implementan este mismo algoritmo, que es por lo que la salida de esta herramienta coincide con lo que ven la barra de direcciones de tu navegador y las llamadas fetch.

Un detalle sutil que el estándar fija con claridad es la diferencia entre los esquemas especiales (http, https, ws, wss, ftp, file) y todo lo demás. Los esquemas especiales reciben una normalización adicional, como poner el host en minúsculas y resolver el puerto predeterminado, mientras que los esquemas no especiales se tratan de forma más literal. Esa distinción explica por qué una URL https y una URL personalizada myapp con el mismo texto tras los dos puntos pueden analizarse en valores de componentes bastante diferentes.

Publicidad
Publicidad
Publicidad