Codes de Statut HTTP Gratuit en Ligne
Référence complète de tous les codes de statut HTTP avec des descriptions.
Who uses the Codes de Statut HTTP?
- Développeurs backend choisissant le code de statut correct pour les réponses d'API REST.
- Développeurs frontend recherchant un code de statut inconnu vu dans l'onglet réseau lors du débogage.
- Étudiants apprenant les fondamentaux du web et le cycle requête/réponse HTTP.
How the Codes de Statut HTTP works
Parcourez la liste — les codes sont groupés par catégorie (1xx–5xx) avec des en-têtes codés par couleur au fil du défilement.
Utilisez la barre de recherche pour filtrer par numéro de code ou mot-clé (ex. « 404 » ou « not found ») — la liste se réduit instantanément.
La description de chaque code est toujours visible ; pas besoin de cliquer pour la développer.
Ajoutez cette page à vos favoris pour une référence rapide lors de la création ou du débogage d'API.
Tips & tricks
- Ceci est une liste de référence statique, pas un vérificateur en direct — pour voir le code de statut réel qu'une URL renvoie, utilisez le HTTP Header Checker ou le Website Speed Test de ce site.
- La recherche filtre simultanément le numéro de code, le nom et le texte de description, donc rechercher « webdav » fait apparaître tous les codes spécifiques à WebDAV.
- Le code couleur (indigo/vert/ambre/rouge/rouge foncé) correspond à la catégorie 1xx-5xx en un coup d'œil, même après avoir défilé au-delà de l'en-tête de catégorie.
- 418 « I'm a Teapot » est réel (RFC 2324) mais c'est une blague du poisson d'avril sans utilité pratique — ne construisez pas de logique réelle dessus.
Frequently Asked Questions
Quelle est la différence entre les redirections 301 et 302 ?
301 Moved Permanently indique aux moteurs de recherche et navigateurs que la ressource a été déplacée définitivement — ils mettent à jour leur index et mettent en cache la nouvelle URL. 302 Found est une redirection temporaire — les moteurs de recherche gardent l'URL originale indexée. Utilisez 301 pour des changements d'URL permanents.
Qu'est-ce qui cause un 502 Bad Gateway par rapport à un 503 Service Unavailable ?
502 signifie que le serveur a reçu une réponse invalide d'un serveur en amont (courant dans les configurations de proxy inverse). 503 signifie que le serveur est temporairement incapable de traiter les requêtes (surchargé ou en maintenance). Les deux indiquent des problèmes côté serveur.
Quand dois-je utiliser 400 plutôt que 422 pour les erreurs de validation d'API ?
400 Bad Request est pour les requêtes malformées (JSON invalide, en-têtes requis manquants). 422 Unprocessable Entity est pour les requêtes syntaxiquement valides qui échouent à la validation de logique métier (ex. l'e-mail existe déjà). Beaucoup d'API REST utilisent 400 pour les deux cas.
Quelle est la différence entre 401 Unauthorized et 403 Forbidden ?
401 signifie que l'utilisateur n'est pas authentifié — il doit se connecter ou fournir des identifiants. 403 signifie que l'utilisateur EST authentifié mais n'a pas la permission d'accéder à la ressource. Renvoyer 403 révèle que la ressource existe ; renvoyer 404 le cache.
Que signifie HTTP 418 « I'm a Teapot » ?
HTTP 418 est une blague du poisson d'avril issue de la RFC 2324 (1998) — toute tentative de préparer du café avec une théière renvoie 418. C'est un vrai code de statut que certains frameworks implémentent comme easter egg. Il n'a aucune utilité pratique.
Is my data safe when using the Codes de Statut HTTP?
Completely safe. The Codes de Statut HTTP processes everything locally in your browser. No input data, results, or usage information is ever transmitted to or stored on any server.
How current is the data returned by the Codes de Statut HTTP?
The Codes de Statut HTTP fetches live data in real time each time you run it. Results reflect the current state of the server or domain at the moment of the request.
Why does the Codes de Statut HTTP sometimes return different results than other tools?
Results depend on the real-time state of the target server and DNS propagation, which can vary by geographic region and caching TTL. If you see inconsistencies, wait a few minutes and re-test — DNS changes can take up to 48 hours to propagate fully worldwide.