¿Y los fragmentos (#hash) y rutas de Single Page Application?

El fragmento se analiza y muestra por separado. Las Single Page Applications modernas históricamente usaban fragmentos para routing en cliente (p.ej., #/users/123) porque los fragmentos no disparan peticiones al servidor — el estado íntegro de la URL vive en cliente. La API History de HTML5 y ahora la API Navigation más moderna han desplazado las SPAs hacia routing basado en path, pero los fragmentos siguen siendo relevantes para rutas basadas en hash, deep-linking a secciones de página y tokens de flujo implícito OAuth. La herramienta extrae el fragmento exactamente como lo expondría el navegador vía `URL.hash` (incluyendo el `#` inicial).

¿Qué es URLPattern y cuándo lo usaría en vez de parseo de URL?

URLPattern (borrador WICG, urlpattern.spec.whatwg.org) es una API complementaria para hacer match de URLs contra strings de patrón — piénsalo como path-to-regexp integrado en el navegador. Llegó estable a Chromium 95 / Edge 95 (octubre 2021); Chrome 117 (agosto 2023) extendió la integración ServiceWorker Static Routing API; el soporte de Safari fue anunciado en WWDC 2025; Firefox está en desarrollo. Casos de uso: routing en service workers, matching de URL para compression-dictionary-transport y reemplazar routing regex personalizado en frameworks frontend. El parseo de URL (esta herramienta) extrae componentes de una sola URL; URLPattern hace match de una URL contra un patrón como `/users/:id/posts/:postId?` para extraer parámetros nombrados. Se complementan en vez de reemplazarse.

Analizador de URL Online Gratis

Q: RFC 3986 vs WHATWG URL Living Standard — ¿cuál usa la herramienta?

WHATWG URL Living Standard, porque es lo que implementa el constructor URL nativo del navegador. Las dos especificaciones difieren en formas sutiles pero importantes: RFC 3986 (Berners-Lee, Fielding y Masinter, enero 2005, Internet Standard STD 66) define la sintaxis genérica URI con reglas ABNF estrictas y trata la entrada malformada como error duro. WHATWG URL Living Standard (url.spec.whatwg.org, actualización continua) define un parser optimizado para compatibilidad real con la web — acepta entradas que violan RFC 3986 (caracteres sin codificar, barras redundantes, esquemas ausentes) y aplica reglas de normalización extraídas del comportamiento de navegadores. Para un parser que produce el mismo resultado que tu navegador, WHATWG es correcto; para validación estricta a nivel de protocolo (p.ej., generar URIs canónicos en cabeceras HTTP), RFC 3986 es más apropiado.

Q: ¿La herramienta decodifica caracteres percent-encoded e IRIs?

Sí. Los valores de parámetros se decodifican percent para mostrarse, así que lees el texto original — `name=Jos%C3%A9` se convierte en `name=José`. La URL íntegra se muestra sin cambios arriba para que veas la forma codificada. Para IRIs (Internationalized Resource Identifiers, RFC 3987 Duerst y Suignard, enero 2005), los caracteres Unicode en rutas y query strings se aceptan directamente; el parser WHATWG maneja el mapeo IRI-a-URI internamente. Para nombres de dominio internacionalizados (IDN — café.com), el host se muestra tanto en forma Unicode como Punycode (xn--caf-dma.com según RFC 5891 Klensin, agosto 2010, IDNA2008), ya que DNS resuelve solo formas ASCII-encoded.

Q: ¿La herramienta maneja URLs malformadas?

La herramienta usa el parser de URL nativo del navegador, que sigue la especificación WHATWG. WHATWG maneja explícitamente entradas malformadas comunes (esquemas ausentes anteponiendo http://, barras redundantes colapsadas, caracteres sin codificar codificados como percent) en vez de lanzar excepciones. Para entradas que el parser realmente no puede manejar (p.ej., cadenas vacías, tipos no-string, sintaxis de esquema fundamentalmente inválida), lanza un TypeError con mensaje claro identificando qué componente falló. Pegar un fragmento de texto libre puede producir resultados inesperados porque WHATWG interpreta agresivamente entradas ambiguas como URLs — para validación más estricta usa herramientas ABNF de RFC 3986.

Analizador URL — WHATWG Living Standard, IRI, Punycode y URLPattern

El parseo de URL tiene dos especificaciones de referencia: RFC 3986 (Berners-Lee, Fielding y Masinter, enero 2005, Internet Standard STD 66) define la sintaxis genérica URI con reglas ABNF estrictas — esquema, autoridad, ruta, query, fragmento — tratando la entrada malformada como error duro. El WHATWG URL Living Standard (url.spec.whatwg.org, actualización continua) define un parser optimizado para compatibilidad con navegadores — acepta entradas que violan RFC 3986 y aplica reglas de normalización extraídas del comportamiento real de la web. Los navegadores implementan WHATWG, no RFC 3986. La internacionalización añade dos capas más: RFC 3987 (Duerst y Suignard, enero 2005) define IRIs (Internationalized Resource Identifiers), permitiendo Unicode en componentes URI; RFC 5890–5891 (Klensin, agosto 2010, IDNA2008) definen cómo los nombres de dominio internacionalizados mapean a Punycode (prefijo xn--) para resolución DNS. Esta herramienta usa el constructor URL nativo del navegador (alineado con WHATWG), descompone cualquier URL en sus componentes, decodifica valores percent-encoded para visualización, y muestra hostnames IDN en formas Unicode y Punycode.

Cómo usar el parser de URL

Pega cualquier URL en el campo de entrada — URLs completas con query strings, fragmentos, puertos, caracteres IRI Unicode y hostnames IDN funcionan.
La herramienta descompone la URL vía el constructor URL del navegador (alineado con WHATWG) en protocolo, host, puerto, path, parámetros de query y fragmento.
Revisa cada componente en su campo. Los parámetros de query se listan individualmente con valores decodificados percent; los hostnames IDN muestran formas Unicode (café.com) y Punycode (xn--caf-dma.com).
Copia la parte que necesites — útil para depurar redirecciones, construir llamadas API, auditar parámetros de tracking o extraer Punycode para consultas DNS.

Casos de uso comunes

Depurar una cadena de redirección donde cada salto añade o modifica parámetros de query — ve exactamente qué parámetros utm_* persisten a través de los saltos.
Extraer la forma Punycode (xn--...) de un dominio internacionalizado para alimentar herramientas DNS o WHOIS que requieren entrada ASCII.
Auditar valores de query percent-encoded para revisión de seguridad — decodificando tokens, parámetros state OAuth y payloads firmados.
Sacar el host y puerto exactos de una URL no-HTTP (ssh://, ftp://, ws://, esquemas personalizados) para alimentar otra herramienta que necesita entrada estructurada.

Preguntas frecuentes

RFC 3986 vs WHATWG URL Living Standard — ¿cuál usa esta herramienta?

WHATWG (el constructor URL nativo del navegador). RFC 3986 (enero 2005, STD 66) define sintaxis ABNF estricta y trata la entrada malformada como error; WHATWG (url.spec.whatwg.org) maneja entradas reales de web con gracia — colapsa barras redundantes, codifica como percent caracteres sin codificar, pasa esquema/host a minúsculas. Mismo resultado que tu navegador.

¿La herramienta decodifica caracteres percent-encoded e IRIs?

Sí. Los valores de query se decodifican como percent — `name=Jos%C3%A9` se vuelve `name=José`. Los IRIs (RFC 3987 Duerst y Suignard, enero 2005) con Unicode en paths/queries se manejan vía codificación percent UTF-8. Los hostnames IDN (café.com) se muestran en formas Unicode y Punycode (xn--caf-dma.com según RFC 5891 IDNA2008).

¿Y los fragmentos (#hash) y rutas SPA?

Fragmento analizado y mostrado por separado. Las SPAs históricamente usaban fragmentos (#/users/123) para routing en cliente porque los fragmentos no disparan peticiones al servidor. Las SPAs modernas usan API History de HTML5 + routing path; los fragmentos siguen siendo relevantes para rutas hash, deep-linking a secciones y tokens de flujo implícito OAuth.

¿La herramienta maneja URLs malformadas?

WHATWG maneja explícitamente entradas malformadas comunes (colapsa barras redundantes, codifica caracteres como percent) en vez de lanzar excepciones. Para entradas que el parser realmente no puede manejar (cadenas vacías, sintaxis de esquema inválida), se lanza TypeError con mensaje claro identificando el componente que falló. El texto libre puede interpretarse agresivamente como URL — usa herramientas ABNF de RFC 3986 para validación más estricta.

¿Qué es URLPattern y cuándo lo usaría?

URLPattern (borrador WICG) es una API complementaria para hacer match de URLs contra patrones — path-to-regexp integrado en el navegador. Llegó estable a Chromium 95 / Edge 95 (octubre 2021); Chrome 117 (agosto 2023) extendió la integración ServiceWorker Static Routing API; soporte Safari anunciado en WWDC 2025; Firefox en desarrollo. Casos de uso: routing en service workers, reemplazo de routers de framework, compression-dictionary-transport. Match `/users/:id/posts/:postId?` contra URLs para extraer parámetros nombrados.

RFC 3986 vs WHATWG — y por qué el parser de tu navegador puede sorprenderte

RFC 3986 (enero 2005) es el Internet Standard del IETF para la sintaxis URI genérica. Usa gramática ABNF formal para definir cómo se ve un URI válido: esquema `://` autoridad `/` ruta `?` query `#` fragmento. Las entradas que violan la gramática son errores — RFC 3986 no intenta recuperar, las rechaza. WHATWG URL Living Standard toma el enfoque opuesto: las URLs del mundo real en atributos HTML, JavaScript y cabeceras HTTP no siempre siguen RFC 3986, así que el parser WHATWG fue diseñado para manejarlas con gracia. Comportamientos comunes WHATWG que divergen de RFC 3986: los esquemas ausentes no se anteponen automáticamente (la entrada debe ya contener un esquema para ser una URL válida); las barras redundantes en rutas se colapsan; los caracteres sin codificar en query strings se codifican como percent automáticamente; el esquema y host en mayúsculas se convierten a minúsculas. Para internacionalización, RFC 3987 (IRI) extiende los URIs para incluir caracteres Unicode directamente — los IRIs mapean a URIs codificando como percent los bytes UTF-8. Los nombres de dominio internacionalizados usan un mecanismo separado: RFC 5891 (IDNA2008) define el protocolo de lookup que convierte hostnames Unicode (café.com) a Punycode ASCII (xn--caf-dma.com) según RFC 3492 — DNS solo resuelve ASCII. URLPattern (borrador WICG, urlpattern.spec.whatwg.org) es una API complementaria que llegó estable a Chromium 95 / Edge 95 (octubre 2021) para hacer match de URLs contra strings de patrón; Chrome 117 (agosto 2023) extendió la integración con la ServiceWorker Static Routing API — útil para routing en service workers y reemplazar bibliotecas path-to-regexp.

Descomposición protocolo, hostname, puerto, path, query, fragmento (alineado con WHATWG)
Decodificación percent de valores de parámetros de query para visualización
Visualización de hostname IDN en Unicode + Punycode (RFC 5891 IDNA2008)
Soporte IRI según RFC 3987 (Unicode en componentes URI)
Parámetros de query listados individualmente con pares clave/valor
Construido sobre la API URL nativa del navegador — sin dependencias externas, sin viaje al servidor

Gratis. Sin registro. Las tools de navegador (subred, JWT, fuerza de contraseña) corren localmente; las de consulta usan APIs públicas (Cloudflare DoH, RDAP, registros de certs). Detalle por herramienta en /es/methodology/.

Fuentes (7)

Berners-Lee, T., Fielding, R., & Masinter, L. (2005). Uniform Resource Identifier (URI): Generic Syntax. RFC 3986, IETF (January 2005 — Internet Standard STD 66; scheme/authority/path/query/fragment).
Duerst, M., & Suignard, M. (2005). Internationalized Resource Identifiers (IRIs). RFC 3987, IETF (January 2005 — Unicode/ISO 10646 in URIs; complement to RFC 3986).
Klensin, J. (2010). Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework. RFC 5890, IETF (August 2010 — IDNA2008 base definitions).
Klensin, J. (2010). Internationalized Domain Names in Applications (IDNA): Protocol. RFC 5891, IETF (August 2010 — IDNA2008 lookup/registration; Punycode xn-- prefix; updates and replaces RFC 3490 IDNA2003).
Costello, A. (2003). Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA). RFC 3492, IETF (March 2003 — encoding scheme used by IDNA2008 to map Unicode hostnames to ASCII xn-- form).
WHATWG (live). URL Living Standard. url.spec.whatwg.org — browser-aligned parser; differs from RFC 3986 in error handling and percent-encoding.
WICG / W3C Web Performance WG (2024). URLPattern. WICG draft (urlpattern.spec.whatwg.org); shipped stable in Chromium 95 / Edge 95 (October 2021); Chrome 117 (August 2023) extended ServiceWorker Static Routing API integration; Safari support announced WWDC 2025; Firefox in development.

Son los RFCs del IETF, las publicaciones del NIST y los estándares del W3C que la herramienta implementa o consulta. Localízalos en el IETF Datatracker (datatracker.ietf.org) o en el organismo correspondiente.

Por Marco B. · Última verificación junio 2026 — corre en tu navegador