Que signifient « encoder » et « decoder » une URL ?
Encoder une URL (« url encode », « urlencode ») transforme chaque caractère interdit dans une adresse — espace, accent, esperluette, signe plus — en une séquence composée d'un pourcent suivi des deux chiffres hexadécimaux de son octet. Decoder une URL (« url decode », « decoder url ») lit ces séquences à l'envers : les octets sont reconstitués puis convertis en caractères selon l'encodage déclaré, le plus souvent l'UTF-8. C'est exactement cette paire que les gens cherchent quand ils tapent « encoder decoder url » ou « percent encoding online ».
Le percent-encoding n'est ni une compression ni un chiffrement : un mot accentué devient deux fois plus long, et n'importe qui peut le lire à l'œil. Son seul rôle est de faire passer n'importe quel octet dans une URL, qui par défaut n'autorise qu'un sous-ensemble d'ASCII. Inversement, le Base64 sert à transporter des octets dans des canaux entièrement textuels — les deux se ressemblent visuellement mais ne sont pas interchangeables.
Comment encoder une URL en percent-encoding
Étape 1 : le texte est converti en octets selon le jeu de caractères choisi, UTF-8 par défaut. Étape 2 : pour chaque octet, on regarde si le caractère correspondant appartient à la liste des caractères autorisés pour la portée sélectionnée. Étape 3 : s'il en fait partie, il est recopié tel quel ; sinon il devient %XX, avec XX les deux chiffres hexadécimaux de l'octet. Étape 4 : si l'option espace en + est active, l'octet 32 est remplacé par un signe plus au lieu de %20.
Exemple concret : « café & été » en portée composant donne caf%C3%A9%20%26%20%C3%A9t%C3%A9. Tapez simplement ce texte dans l'encodeur : le résultat, la taille d'entrée, la taille de sortie et le surcoût apparaissent avant même de relâcher la touche.
Les quatre portées d'encodage
La portée composant ne conserve que les lettres, chiffres et - _ . ! ~ * ' ( ) : c'est celle d'une valeur de paramètre, et elle correspond à encodeURIComponent. La chaîne de requête conserve en plus les esperluettes et les égalités, pour reconstruire une query string entière. Le segment de chemin autorise / : @ & = + $ , ; afin de ne pas casser les barres obliques. L'URL complète ajoute encore ?, #, [ et ] : presque rien n'est échappé, seuls les espaces et les caractères non ASCII partent en %XX.
Comment decoder une URL encodée
Le décodage scanne la chaîne de gauche à droite : un pourcent suivi de deux chiffres hexadécimaux donne un octet, tout autre caractère est recopié après conversion selon l'encodage choisi. Les octets sont ensuite regroupés et transformés en caractères — deux octets pour « é », trois pour « 日 », quatre pour un emoji. L'onglet « Décoder » affiche chaque séquence trouvée, sa position dans la chaîne, ses octets et le texte correspondant.
Si le pourcent n'est pas suivi de deux chiffres valides, l'erreur est explicite : séquence incomplète ou caractère hexadécimal invalide. Le bouton « Corriger les % » transforme les pourcentages isolés en %25, ce qui rend la chaîne décodable sans perdre d'information — l'option la plus sûre pour traiter une URL partiellement échappée.
Espace : %20 ou + — la règle des formulaires
%20 est l'espace en percent-encoding strict : il fonctionne dans le chemin, la requête, le fragment et les en-têtes. Le signe +, lui, n'est un espace que dans le format application/x-www-form-urlencoded utilisé par les formulaires HTML et historiquement par les query strings. Ailleurs il reste un signe plus littéral — et comme il est très facile de le confondre, il faut l'échapper en %2B dès qu'on encode une valeur.
En pratique : pour alimenter un champ de formulaire ou reproduire le comportement d'un <form>, cochez « Espace en + ». Pour une URL de redirection, une canonical ou un lien partagé, préférez toujours %20. Le décodeur, lui, traite + comme un espace par défaut et vous pouvez désactiver ce comportement d'un clic.
RFC 3986 : unreserved, sub-delims et gen-delims
La RFC 3986 divise les caractères ASCII en trois catégories. Les caractères non réservés — lettres, chiffres, - _ . ~ — sont toujours conservés tels quels. Les sous-délimiteurs ! $ & ' ( ) * + , ; = et les délimiteurs génériques : / ? # [ ] @ ont une signification structurelle : ils séparent l'autorité, le chemin, la requête et le fragment. Tout le reste — espace, guillemets, chevrons, accolades, pourcent — doit être encodé.
Ces catégories sont exactement celles que l'onglet « RFC 3986 & référence » affiche caractère par caractère : cliquez sur une tuile pour voir son code hexadécimal, sa catégorie et les portées qui le conservent. C'est la référence la plus rapide pour répondre à la question « est-ce que je dois échapper ce caractère ? ».
Caractères accentués, emojis et UTF-8
Une URL ne transporte que des octets ASCII sûrs, donc tout caractère au-delà d'U+007F doit être encodé. En UTF-8, « é » vaut C3 A9 et devient %C3%A9, « 日 » vaut trois octets et produit trois séquences, un emoji en occupe quatre et se décline en huit caractères encodés. Si le résultat vous paraît long, ce n'est pas un bug : c'est le prix de la compatibilité avec tous les protocoles. Attention enfin au jeu de caractères d'origine — décoder en UTF-8 une chaîne encodée en Latin-1 produit des caractères aberrants, d'où les quatre options proposées dans l'onglet « Décoder ».
Pourquoi encodeURIComponent ne suffit pas toujours
encodeURIComponent encode tout sauf A-Z a-z 0-9 - _ . ! ~ * ' ( ), ce qui convient pour une valeur de paramètre mais casse une URL complète puisqu'il échappe aussi les barres obliques, les deux-points et les esperluettes. encodeURI fait l'inverse : il préserve la structure de l'URL mais laisse passer les espaces et les accents, donc il échoue sur un texte brut. Les deux fonctionnages sont couverts ici — et bien plus, puisque la portée « Chaîne de requête » et la portée « Segment de chemin » comblent l'écart entre les deux.
Percent-encoding et Base64 : deux outils différents
Le percent-encoding remplace octet par octet et préserve la lisibilité du texte d'origine, au prix d'un allongement important. Le Base64 regroupe les octets par trois et les réécrit dans un alphabet de 64 caractères : compact mais totalement illisible, et inutilisable tel quel dans une URL sans variante URL-safe. L'onglet « Encodages croisés » présente les deux d'un même coup d'œil, avec en bonus les octets hexadécimaux, les entités HTML et la chaîne JSON échappée — de quoi choisir la bonne représentation avant de copier quoi que ce soit.
Erreurs fréquentes : double encodage et % isolé
L'erreur la plus courante est d'échapper deux fois la même chaîne : un espace devient %20, puis %2520, et le serveur récupère littéralement « %20 ». La seconde est d'oublier le pourcent lui-même, qui doit devenir %25 — sinon le décodeur le prend pour le début d'une séquence et plante ou tronque. Enfin, conserver un + non échappé dans un paramètre de formulaire revient à insérer un espace que vous n'aviez pas demandé. Le décodeur signale les séquences mal formées, et le bouton « Corriger les % » répare le second cas sans perte.
Où se cachent les URLs encodées
Dans les query strings de suivi UTM, dans les redirect_uri et les états OAuth, dans les webhooks dont l'URL cible contient des paramètres imbriqués, dans les URL de callback signées, dans les journaux serveur, dans les sitemaps et les canonical, dans les <a href> générés côté client, dans les JWT dont le payload est en Base64URL, dans les data: et les en-têtes Location, et dans tout formulaire HTML soumis en GET. Savoir encoder et decoder en une seconde évite d'ourir un terminal pour une seule chaîne.
Performances et bonnes pratiques
Dans le navigateur, l'encodage et le décodage sont linéaires et ne coûtent rien notablement, même sur plusieurs mégaoctets : chaque caractère est traité une seule fois, sans récursion ni allocation par caractère. Les seuls pièges sont le double encodage — vérifiez toujours le round-trip avant de stocker — et les URL de plusieurs kilooctets, souvent tronquées par les proxies au-delà de 2 000 caractères. Documentez la portée utilisée à côté de la chaîne produite : « composant » et « URL complète » ne donnent pas le même résultat sur le même texte.
Recommandé pour
Développeurs back-end et front-end (query strings, redirections, OAuth), intégrateurs et rédacteurs techniques (liens UTM, canonical, tracking), administrateur·es et DevOps (webhooks, URLs signées, journaux), test·euses et pentesteurs (fuzzing de paramètres, contournement de filtres), étudiants (comprendre l'UTF-8, l'ASCII et la RFC 3986), et toute personne qui a besoin d'un encodeur décodeur URL en ligne rapide, complet et confidentiel — avec pour complément l'encodeur décodeur Base64 et le formateur JSON.