URL

Rapport de validation

Qu'est-ce que le Validateur d'URL ?

Tu colles une URL et tu reçois un rapport structuré : est-elle bien formée, à quoi ressemble chaque composant, sur quoi faut-il faire attention. Le validateur passe l'URL par le constructeur URL natif du navigateur — qui implémente le standard WHATWG URL — puis ajoute des contrôles par composant par-dessus.

Une "URL valide" n'est pas juste une URL qui se parse. Une URL comme http://10.0.0.5/admin?token=abc123 se parse très bien, mais elle a trois choses qu'il vaut mieux signaler : http:// au lieu de https://, une IP littérale comme hôte et un token dans la query string. Le validateur fait remonter les trois en avertissements, séparés du verdict pass/fail. Les règles de syntaxe sous-jacentes viennent du RFC 3986 ; les considérations sur les noms d'hôtes viennent du RFC 1034 et de l'expérience opérationnelle.

La sortie est en JSON, donc tu peux la pipeliner dans un script CI ou un log de debug. Tout tourne dans ton navigateur — l'URL ne quitte jamais ta machine. Si tu veux décomposer l'URL en composants sans la couche de validation, utilise plutôt l'URL Parser. Les noms de domaine internationalisés sont gérés selon les règles IDNA.

Comment utiliser le Validateur d'URL

Trois étapes. Chacune correspond à un bouton sur cette page.

Colle une URL ou charge l'exemple

Pose une URL dans le panneau de gauche. Clique sur Exemple pour charger une URL propre, bien formée, avec des paramètres encodés en pourcentage :

https://api.shop.example.com/v1/orders?customer=Ava%20Chen&status=active

Le validateur se met à jour pendant que tu tapes. Essaie des cas limites : URLs http://, hôtes en IP littérale, URLs avec identifiants, hôtes mono-label (sans TLD), domaines Punycode. Chacun fait remonter un avertissement différent.

Lis le rapport

Le panneau de droite affiche un rapport JSON avec trois champs principaux : isValid (l'URL s'est parsée), checks (statut par composant — protocole, hostname, port, pathname) et warnings (signalements informatifs qui ne sont pas des erreurs de syntaxe mais qui t'intéressent probablement).

Copie ou télécharge

Clique sur Copier pour envoyer le rapport JSON dans le presse-papiers, ou sur Télécharger pour le sauvegarder en .json. Minifier compacte le rapport sur une seule ligne si tu en as besoin pour une entrée de log.

Quand tu t'en sers vraiment

Auditer un fichier de config avant un déploiement

La config de ton service contient 40 URLs — endpoints de webhook, callbacks OAuth, intégrations tierces. L'une a un mot de passe intégré laissé par un test oublié, deux pointent encore sur des hôtes http:// de staging. Les passer une par une dans le validateur attrape les trois avant qu'elles ne partent en prod. Les exigences de format d'URL apparaissent aussi dans la spec OAuth 2.0 pour les redirect URIs.

Vérifier des URLs soumises par les utilisateurs dans un formulaire

Un utilisateur soumet un champ "site web" qui se révèle être example — pas de protocole, pas de TLD, juste un mot. Ou https://192.168.1.5 — ça a l'air valide, ça se parse valide, mais tu ne veux quasiment jamais afficher ça comme lien de profil. Le validateur sort les deux : avertissement TLD-manquant pour le premier, avertissement IP-littérale pour le second.

Diagnostiquer pourquoi un redirect échoue

Ton callback OAuth renvoie 400 avec "invalid redirect_uri." L'URL a l'air OK dans le navigateur. Tu la colles dans le validateur et tu repères le problème : le path contient un espace littéral, et ton fournisseur d'auth compare les chaînes octet par octet après canonicalisation. L'avertissement ("le chemin contient un espace non encodé") était la réponse.

Repérer un décalage Punycode vs Unicode

Tu attendais münchen.example.com dans le rapport et tu as vu xn--mnchen-3ya.example.com. C'est la forme Punycode — celle qui passe sur le réseau — et le validateur la signale pour que tu saches que l'entrée d'origine contenait des caractères non-ASCII. Pratique quand l'utilisateur d'un bug report a copié-collé une URL d'un domaine IDN.

Questions fréquentes

Que veut dire "valide" exactement ici ?

Deux couches. isValid: true signifie que le constructeur URL du navigateur accepte l'entrée — donc que la syntaxe est bien formée selon le standard WHATWG URL. warnings est séparé : ce sont des choses syntaxiquement valides mais probablement pas ce que tu veux (protocole non sécurisé, IP littérale, identifiants intégrés, TLD manquant, etc.). Une URL peut être valide et avoir quand même des avertissements.

Vérifie-t-il si l'URL pointe réellement sur quelque chose ?

Non — ça nécessiterait une requête réseau, et cet outil tourne entièrement dans ton navigateur sans aucun appel sortant. Le validateur ne contrôle que la syntaxe et des heuristiques de surface. Pour vérifier l'accessibilité, utilise curl -I ou un outil d'uptime dédié.

Pourquoi http://example.com est-il signalé en avertissement ?

Parce qu'en 2026 une URL en clair est presque toujours une erreur — les navigateurs modernes préviennent les utilisateurs avant de soumettre des formulaires sur http://, l'article "why HTTPS matters" de Google couvre la version longue, et les domaines en preload HSTS refusent purement de charger en HTTP. L'avertissement est informatif ; si tu veux vraiment du http:// (intranet legacy, dev local), ignore-le.

Et les URLs relatives type /api/orders ?

Le constructeur URL a besoin d'une URL absolue — sans base, il ne peut déterminer ni le protocole ni l'hôte. Le validateur renvoie isValid: false avec une erreur claire dans ce cas. Pour valider une URL relative, préfixe-la d'abord par une base comme https://example.com.

Les identifiants dans les URLs, c'est toujours une mauvaise idée ?

Quasiment toujours. La RFC 3986 §3.2.1 note que les identifiants dans les URLs sont dépréciés pour des raisons de sécurité. Ils finissent dans l'historique du navigateur, dans les logs d'accès du serveur et dans les caches de proxy. Les navigateurs modernes les retirent silencieusement à la copie depuis le presse-papiers. Le validateur les signale pour que tu en aies une trace explicite avant qu'ils ne fuitent quelque part où ils ne devraient pas.

Tient-il compte des domaines IDN ?

Oui — le validateur indique si le hostname est en forme Punycode (xn--...) ou en ASCII pur. Les navigateurs peuvent afficher la forme Unicode aux utilisateurs tout en transmettant la forme Punycode sur le réseau, ce qui est à l'origine des attaques homographiques IDN. Faire ressortir le Punycode est un signal modeste mais utile.

Autres outils URL et JSON

La validation, c'est une opération. Voici ce qui se marie naturellement avec :