Parseur d'URL
Décomposez n'importe quelle URL en ses parties — schéma, hôte, chemin, paramètres de requête, fragment.
Qu'est-ce qu'un analyseur d'URL ?
Un analyseur d'URL décompose un Uniform Resource Locator en éléments étiquetés définis par la RFC 3986 : schéma, userinfo facultatif, hôte (avec port facultatif), chemin, requête et fragment. Chaque navigateur, serveur, proxy, CDN et vérificateur de liens doit effectuer cette opération en interne avant de pouvoir router ou réécrire une requête. Voir cette décomposition explicitement permet de repérer facilement les bogues d'encodage, les barres obliques mal placées, les identifiants accidentels dans les URL et les attaques par homographe IDN.
Comment utiliser cet analyseur
Collez une URL dans la case. Le panneau des composants se met à jour instantanément. Regardez la ligne hôte pour voir si le punycode est en jeu (un hôte commençant par xn-- est encodé en IDN), vérifiez la ligne port pour confirmer si l'URL utilise le port par défaut du protocole, et parcourez le tableau des paramètres de requête pour voir exactement quelles clés et valeurs arriveraient au serveur. La ligne URL normalisée montre à quoi ressemble l'URL après que l'analyseur du navigateur l'a nettoyée — schéma en majuscules mis en minuscules, port par défaut supprimé, encodage pour cent rangé.
Pourquoi les fragments n'atteignent pas le serveur
Le fragment — la partie après # — est réservé à l'agent utilisateur. Les navigateurs le suppriment avant d'envoyer la requête HTTP, c'est pourquoi le serveur (ainsi que vos journaux d'accès et les données brutes de page de destination de vos outils d'analyse) ne peut pas le voir. Les applications monopage en abusent volontairement pour rendre la navigation instantanée : les changements de route mettent à jour le fragment au lieu de déclencher une véritable requête réseau. Si vous avez besoin qu'une valeur atteigne le serveur, mettez-la dans la chaîne de requête, pas dans le fragment.
Anatomie d'une URL
| Partie | Exemple | Rôle |
|---|---|---|
protocol | https: | Indique au client quel protocole utiliser. |
host | shop.example.com | Le serveur auquel se connecter. Peut être un nom de domaine ou une IP littérale. |
port | 8443 | Port TCP. Par défaut 80 pour http, 443 pour https. |
path | /cart/checkout | Chemin de la ressource sur le serveur. Commence toujours par /. |
query | ?id=42&ref=hp | Paires clé/valeur facultatives après le ?. |
fragment | #payment | Ancre côté client après le #. Jamais envoyée au serveur. |
Questions fréquentes
Cet outil envoie-t-il mes URL quelque part ?
URL intégré au navigateur ; rien n'est téléversé. Ouvrez les DevTools > Réseau et vous verrez qu'aucune requête n'est déclenchée pendant que vous tapez.Qu'est-ce que le punycode ?
xn--mnchen-3ya.de. L'analyseur affiche les deux formes pour que vous puissiez repérer les attaques par homographe où un hôte malveillant se fait passer pour une marque familière.Pourquoi l'analyseur affiche-t-il le userinfo si je colle une URL avec des identifiants ?
Les clés de requête répétées sont-elles préservées ?
?tag=a&tag=b affiche les deux lignes. La façon dont un serveur interprète les doublons dépend du framework — PHP conserve la dernière valeur par défaut, URLSearchParams de Node.js renvoie un tableau. L'analyseur ne déduplique pas ; il montre ce qui est réellement dans l'URL.Qu'est-ce qui est décodé en pour cent ?
Puis-je analyser des URL mailto: ou tel: ?
URL du navigateur accepte. Pour mailto:, l'adresse se trouve dans le chemin, les en-têtes comme ?subject= apparaissent comme paramètres de requête. Pour une construction mailto plus avancée, consultez notre générateur de liens mailto dédié.