Encodeur & Décodeur URL

Convertissez vos URLs et paramètres avec le percent-encoding standard RFC 3986.

Texte original

Mode d'encodage

Actions

Résultat

Tableau de référence des encodages

espace%20
!%21
#%23
$%24
&%26
'%27
(%28
)%29
+%2B
,%2C
/%2F
:%3A
;%3B
=%3D
?%3F
@%40
é%C3%A9
à%C3%A0

Guide complet : Comprendre et maîtriser l'encodage URL (percent-encoding)

Pourquoi l'encodage URL est essentiel dans le développement web

En développant des applications web depuis des années, je rencontre quotidiennement des problèmes liés à l'encodage URL. Une recherche avec des accents qui échoue, un paramètre de redirection qui casse, un token OAuth qui ne passe pas... Ces bugs subtils viennent presque toujours d'un encodage URL mal géré.

Le standard URL (RFC 3986) définit un ensemble très restreint de caractères "sûrs" : A-Z a-z 0-9 - . _ ~. Tout le reste — espaces, accents, caractères spéciaux, caractères non-ASCII — doit être converti en séquences %XX (percent-encoding), où XX est la valeur hexadécimale de l'octet.

Comment fonctionne le percent-encoding

Le processus d'encodage URL suit ces étapes :

  1. Chaque caractère est d'abord converti en octets UTF-8 (le standard moderne)
  2. Chaque octet "non sûr" est remplacé par % suivi de sa valeur hexadécimale
  3. Les caractères sûrs (lettres, chiffres, -._~) restent inchangés

Exemple : é en UTF-8 = octets C3 A9 → encodé %C3%A9

Exemple : 中 (chinois) en UTF-8 = octets E4 B8 AD → encodé %E4%B8%AD

Les trois fonctions JavaScript expliquées en détail

🔒 encodeURIComponent() — Le choix sûr pour les valeurs

Encode tous les caractères sauf A-Za-z0-9-_.!~*'(). À utiliser pour encoder les valeurs de paramètres dans une query string. Encode même =, &, /, ? qui ont une signification spéciale dans les URLs.

Exemple : search=café & croissant → valeur caf%C3%A9%20%26%20croissant

🌐 encodeURI() — Pour les URLs complètes

Préserve les caractères structurels d'URL : ;,/?:@&=+$#. À utiliser pour encoder une URL complète sans casser sa structure. N'encode pas les séparateurs de chemin, query string, etc.

Exemple : https://example.com/café?q=test → https://example.com/caf%C3%A9?q=test

⚠️ escape() — Déprécié, à éviter

Ancienne fonction (pré-Unicode) qui ne gère pas correctement l'UTF-8. Encode les caractères > 255 en %uXXXX qui n'est pas standard. Conservé uniquement pour la compatibilité avec du code legacy très ancien.

Ne jamais utiliser pour de nouveaux développements.

Quand utiliser quelle fonction ?

  • Valeur d'un paramètre de query string : encodeURIComponent(). Exemple : ?name= + encodeURIComponent("Jean-François")
  • URL complète avec caractères non-ASCII : encodeURI(). Préserve ://, ?, &
  • Segment de chemin (path) : encodeURIComponent(), mais attention aux /
  • URL comme valeur d'un paramètre (redirect_uri) : encodeURIComponent() sur l'URL entière

Cas pratiques courants

  • Recherche avec accents : ?q= + encodeURIComponent("café crème") → ?q=caf%C3%A9%20cr%C3%A8me
  • OAuth redirect_uri : L'URL de callback doit être entièrement encodée : redirect_uri= + encodeURIComponent("https://myapp.com/callback?state=123")
  • JSON dans l'URL : ?data= + encodeURIComponent(JSON.stringify(obj)). Attention à la longueur !
  • Noms de fichiers : Les espaces et caractères spéciaux dans les noms de fichiers doivent être encodés
  • Ancres avec caractères spéciaux : #section-café peut nécessiter un encodage selon le contexte

Pièges courants et comment les éviter

  • Double encodage : Si %20 devient %2520, vous avez encodé deux fois. Décodez d'abord si les données viennent d'une source déjà encodée.
  • encodeURIComponent sur une URL complète : Casse la structure ! https:// devient https%3A%2F%2F qui ne fonctionnera plus.
  • Oublier d'encoder les paramètres : Peut causer des erreurs 400 ou pire, des vulnérabilités de sécurité (injection de paramètres).
  • Encoder côté client ET côté serveur : Risque de double encodage. Choisissez un seul côté.
  • Confondre + et %20 : + pour l'espace est spécifique à application/x-www-form-urlencoded. Dans les URLs pures (RFC 3986), c'est %20.

+ vs %20 : l'histoire compliquée des espaces

Il y a deux conventions pour encoder les espaces :

  • %20 : Standard RFC 3986 pour les URLs. Produit par encodeURIComponent().
  • + : Convention historique des formulaires HTML (application/x-www-form-urlencoded). Produit par les soumissions de formulaires natives et URLSearchParams.

La plupart des serveurs acceptent les deux. En cas de doute, %20 est plus universel et conforme au standard actuel.

Traitement 100% local : vos données restent privées

Cet outil utilise les fonctions JavaScript natives du navigateur. Aucune donnée n'est envoyée à nos serveurs — tout l'encodage et le décodage s'effectuent localement. Vous pouvez le vérifier dans l'onglet Réseau des DevTools. L'outil fonctionne même hors ligne une fois la page chargée.

Questions fréquentes sur l'encodage URL

Pourquoi l'espace devient-il parfois + et parfois %20 ?

Ce sont deux conventions différentes issues de l'histoire du web :

  • + : Convention des formulaires HTML (application/x-www-form-urlencoded), définie avant le standard URL moderne. Les soumissions de formulaires natives et URLSearchParams l'utilisent.
  • %20 : Standard RFC 3986 pour les URLs. encodeURIComponent() produit ce format.

En pratique : la plupart des serveurs acceptent les deux. Si vous construisez manuellement une URL (pas via un formulaire), préférez %20 pour la conformité au standard.

Fun fact : + est un caractère sûr dans les URLs, donc a+b est différent de a%20b techniquement, mais la plupart des serveurs interprètent + comme espace dans les query strings.

Comment éviter le double encodage ?

Le double encodage se produit quand vous encodez des données déjà encodées. %20 devient %2520 (le % est encodé en %25).

Symptômes : URLs qui ne fonctionnent pas, paramètres affichés avec des %25, erreurs étranges côté serveur.

Solutions :

  1. Décodez d'abord si la source est incertaine : encodeURIComponent(decodeURIComponent(value))
  2. Encodez à un seul endroit : soit côté client, soit côté serveur, jamais les deux
  3. Connaissez vos sources : les valeurs de location.search sont déjà décodées par le navigateur

Les caractères chinois, japonais, arabes peuvent-ils être dans une URL ?

Oui, mais ils doivent être percent-encodés. Le processus :

  1. Le caractère est converti en octets UTF-8
  2. Chaque octet devient une séquence %XX

Exemples :

  • 中 (chinois) = UTF-8 E4 B8 AD → %E4%B8%AD
  • あ (japonais) = UTF-8 E3 81 82 → %E3%81%82
  • ع (arabe) = UTF-8 D8 B9 → %D8%B9

Les navigateurs modernes affichent les caractères décodés dans la barre d'adresse pour la lisibilité (IDN pour les noms de domaine, punycode techniquement), mais transmettent la version encodée au serveur.

Quelle est la longueur maximale d'une URL ?

Le standard HTTP ne définit pas de limite, mais en pratique :

  • Navigateurs : Chrome ~2 Mo, Firefox ~65 Ko, Safari ~80 Ko. Internet Explorer avait la limite la plus stricte : 2083 caractères.
  • Serveurs : Apache 8 Ko par défaut, Nginx 8 Ko, IIS 16 Ko. Configurable.
  • CDNs et proxies : Peuvent avoir leurs propres limites.

Recommandation pratique : Restez sous 2000 caractères pour la compatibilité universelle. Au-delà, utilisez POST avec les données dans le body.

Note : l'encodage URL augmente la taille (un caractère UTF-8 peut devenir 3-9 caractères encodés), planifiez en conséquence.

Comment gérer l'encodage URL en PHP, Python, Java et Node.js ?

Chaque langage a ses fonctions dédiées :

  • PHP : rawurlencode() (RFC 3986, %20) vs urlencode() (formulaires, +). Préférez rawurlencode().
  • Python 3 : urllib.parse.quote() (%20) vs quote_plus() (+). urlencode() pour les dicts.
  • Java : URLEncoder.encode(str, "UTF-8"). Attention : produit + pour les espaces !
  • Node.js : encodeURIComponent() (natif) ou querystring.escape().
  • Go : url.QueryEscape() ou url.PathEscape().

Conseil : Vérifiez toujours si la fonction produit + ou %20 pour les espaces, et si elle encode correctement l'UTF-8.

Pourquoi mon URL décodée affiche-t-elle des caractères bizarres ?

C'est presque toujours un problème d'encodage de caractères (charset mismatch) :

  • L'URL a été encodée avec Latin-1 (ISO-8859-1) mais décodée comme UTF-8
  • Ou inversément : encodée en UTF-8, décodée en Latin-1

Exemple : é en Latin-1 = octet E9 → encodé %E9. Si décodé comme UTF-8, E9 seul est invalide et produit �.

Solution : Assurez-vous que l'encodeur et le décodeur utilisent le même charset. En 2024, UTF-8 devrait être le standard partout. Si vous travaillez avec d'anciens systèmes, identifiez leur charset.

Comment passer une URL complète comme paramètre d'une autre URL ?

C'est le cas classique de redirect_uri en OAuth ou des liens de partage. L'URL entière doit être encodée avec encodeURIComponent() :

https://auth.example.com/login?redirect_uri= + encodeURIComponent("https://myapp.com/callback?state=abc&user=123")

Résultat : https://auth.example.com/login?redirect_uri=https%3A%2F%2Fmyapp.com%2Fcallback%3Fstate%3Dabc%26user%3D123

Les ://, ?, & et = de l'URL interne sont encodés pour ne pas être interprétés comme faisant partie de l'URL externe.

N'utilisez PAS encodeURI() ici ! Elle ne coderait pas les ? et &.

Mes données sont-elles sécurisées avec cet outil ?

Oui, totalement. Cet outil utilise les fonctions JavaScript natives du navigateur :

  • encodeURIComponent() / decodeURIComponent()
  • encodeURI() / decodeURI()
  • escape() / unescape() (pour legacy)

Aucune donnée n'est envoyée à nos serveurs — vérifiez dans l'onglet Réseau des DevTools. L'outil fonctionne même hors ligne une fois la page chargée.