Skip to content

Encodeur et Décodeur URL avec Analyseur de Structure Intégré

Collez une URL pour la décoder ou l'encoder instantanément. Analyseur intégré décomposant protocole, hôte, chemin et paramètres en champs éditables. Modes encodeURI et encodeURIComponent. 100 % navigateur — aucune donnée envoyée.

Sans pistage Fonctionne dans le navigateur Gratuit
Décodé
Encodé
Vérifié pour la conformité RFC 3986, la correction encodeURI/encodeURIComponent et l'exactitude de l'encodage UTF-8 — Équipe d'ingénierie Go Tools · 7 avr. 2026

Qu'est-ce que l'encodage URL (encodage en pourcentage) ?

L'encodage URL, formellement appelé encodage en pourcentage, est un mécanisme défini dans la RFC 3986 pour représenter les caractères dans un Identifiant Uniforme de Ressource (URI) qui ne sont pas autorisés ou qui ont une signification spéciale. Il convertit chaque octet non sûr en un signe pourcentage (%) suivi de deux chiffres hexadécimaux — par exemple, un espace devient %20, une esperluette devient %26 et le caractère chinois 中 devient %E4%B8%AD (ses trois octets UTF-8, chacun encodé en pourcentage).

Les URLs ne peuvent contenir qu'un ensemble limité de caractères du jeu ASCII. Les lettres, chiffres et quelques symboles (- _ . ~) sont considérés comme « non réservés » et peuvent apparaître tels quels. Tous les autres caractères — y compris les espaces, la ponctuation et l'ensemble de l'Unicode — doivent être encodés en pourcentage pour être transmis en toute sécurité dans une URL. Les caractères réservés comme ?, &, = et # servent de délimiteurs structurels dans la syntaxe URL, ils doivent donc aussi être encodés lorsqu'ils sont utilisés comme données littérales plutôt que comme délimiteurs.

L'encodage en pourcentage est essentiel sur tout le web : les navigateurs encodent les soumissions de formulaires, les APIs requièrent des paramètres de requête encodés, les flux OAuth dépendent d'URIs de redirection correctement encodés, et les noms de domaine internationalisés reposent sur l'encodage des caractères non-ASCII. Une erreur d'encodage entraîne des liens cassés, des vulnérabilités de sécurité (comme les attaques de redirection ouverte) et la corruption de données.

Cet outil propose les modes encodeURI et encodeURIComponent, un analyseur de structure URL intégré, une conversion en temps réel et la détection du double encodage — le tout fonctionnant en privé dans votre navigateur.

L'encodage URL est souvent utilisé aux côtés d'autres outils de développement web. Vous pourriez avoir besoin d'encoder une URL en Base64 pour l'intégrer dans un jeton JWT ou un payload API, ou de formater des données JSON contenant des chaînes URL pour inspecter leur structure.

// Encode a query parameter value
const param = encodeURIComponent('hello world & goodbye');
console.log(param); // → 'hello%20world%20%26%20goodbye'

// Encode a full URL (preserves structure)
const url = encodeURI('https://example.com/path name?q=hello world');
console.log(url); // → 'https://example.com/path%20name?q=hello%20world'

// Decode a percent-encoded string
const decoded = decodeURIComponent('hello%20world%20%26%20goodbye');
console.log(decoded); // → 'hello world & goodbye'

// Build a URL with encoded parameters
const base = 'https://api.example.com/search';
const query = `?q=${encodeURIComponent('你好')}&lang=zh`;
console.log(base + query); // → 'https://api.example.com/search?q=%E4%BD%A0%E5%A5%BD&lang=zh'

Fonctionnalités clés

Double mode d'encodage

Basculez entre encodeURI (préserve la structure URL) et encodeURIComponent (encode tout pour les valeurs de paramètres) selon votre cas d'utilisation exact.

Analyseur d'URL intégré

Décompose automatiquement toute URL en protocole, hôte, port, chemin, paramètres de requête et fragment — chaque champ est éditable et peut être reconstruit en une nouvelle URL.

Conversion en temps réel

Encodez et décodez instantanément pendant la saisie — aucun bouton à cliquer, les résultats apparaissent immédiatement dans l'autre zone à chaque frappe.

100 % dans le navigateur

Tout le traitement se fait localement dans votre navigateur avec les APIs JavaScript natives. Vos données ne quittent jamais votre appareil — aucun envoi serveur, aucun suivi.

Support UTF-8 complet

Gère correctement le chinois, le japonais, le coréen, l'arabe, les émojis et tout texte Unicode grâce à un encodage et décodage UTF-8 approprié.

Détection du double encodage

Détecte et signale automatiquement les problèmes de double encodage comme %2520 (un %20 encodé en pourcentage), vous aidant à éviter l'une des erreurs d'encodage URL les plus courantes.

Exemples

Décoder une URL illisible

https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Dhello%20world%26lang%3Den
https://example.com/search?q=hello world&lang=en

Une URL entièrement encodée en pourcentage est décodée sous forme lisible, révélant les paramètres et la structure d'origine

Caractères chinois

https://example.com/search?q=你好世界
https://example.com/search?q=%E4%BD%A0%E5%A5%BD%E4%B8%96%E7%95%8C

Les caractères chinois sont convertis en séquences d'octets UTF-8 puis encodés en pourcentage

Paramètres de requête

https://example.com/api?name=John Doe&role=admin&lang=en&sort=date desc
https://example.com/api?name=John%20Doe&role=admin&lang=en&sort=date%20desc

Les espaces et caractères spéciaux dans les valeurs des paramètres de requête sont encodés en pourcentage tout en préservant la structure de l'URL

URL complète

https://user:pass@example.com:8080/path/to/page?key=value&arr[]=1#section-2
https://user:pass@example.com:8080/path/to/page?key=value&arr%5B%5D=1#section-2

Une URL complète avec identifiants, port, chemin, paramètres de requête avec crochets et identifiant de fragment

URI de redirection OAuth

https://auth.example.com/authorize?redirect_uri=https://myapp.com/callback?code=abc&state=xyz
https://auth.example.com/authorize?redirect_uri=https%3A%2F%2Fmyapp.com%2Fcallback%3Fcode%3Dabc%26state%3Dxyz

La valeur redirect_uri contient elle-même une URL complète qui doit être encodée pour que ses caractères spéciaux ne soient pas interprétés comme faisant partie de l'URL externe

Comment utiliser

  1. 1

    Saisissez une URL ou une chaîne encodée

    Collez une URL dans la zone décodée pour l'encoder, ou collez une chaîne encodée en pourcentage dans la zone encodée pour la décoder. Sélectionnez le mode encodeURI ou encodeURIComponent selon votre cas d'utilisation.

  2. 2

    Consultez les résultats et la structure analysée

    L'autre zone se met à jour instantanément pendant que vous tapez. L'analyseur d'URL décompose l'URL en protocole, hôte, port, chemin, paramètres de requête et fragment — tous éditables.

  3. 3

    Copiez ou reconstruisez

    Cliquez sur Copier pour copier le résultat encodé ou décodé. Modifiez les composants individuels de l'URL et cliquez sur Reconstruire pour construire une nouvelle URL à partir des parties modifiées.

Erreurs courantes

Double encodage (%2520 au lieu de %20)

Le double encodage se produit quand une URL déjà encodée est encodée à nouveau. Le % dans %20 est encodé en %25, transformant %20 en %2520. Cela casse l'URL car le serveur voit une chaîne littérale %20 au lieu d'un espace.

✗ Incorrect 
https://example.com/path%2520with%2520spaces
✓ Correct 
https://example.com/path%20with%20spaces

Espace encodé comme + dans les segments de chemin

Le caractère + ne représente un espace que dans le format application/x-www-form-urlencoded (chaînes de requête de formulaires HTML). Dans les segments de chemin URL, + est interprété comme un signe plus littéral, pas un espace. Utilisez toujours %20 pour les espaces dans les segments de chemin.

✗ Incorrect 
https://example.com/my+file+name.pdf
✓ Correct 
https://example.com/my%20file%20name.pdf

Utilisation d'encodeURI sur les valeurs de paramètres de requête

encodeURI() n'encode pas &, = ni les autres caractères réservés, donc l'utiliser sur une valeur de paramètre contenant ces caractères corrompt la structure de la chaîne de requête.

✗ Incorrect 
encodeURI('key=value&more')  → 'key=value&more' (& not encoded!)
✓ Correct 
encodeURIComponent('key=value&more')  → 'key%3Dvalue%26more'

Supposition d'encodage non-UTF-8

Certains systèmes legacy utilisent des encodages comme Latin-1 ou Shift-JIS pour les paramètres URL. Les standards modernes exigent UTF-8. Décoder un paramètre encodé en Shift-JIS avec un décodeur UTF-8 produit du texte corrompu.

✗ Incorrect 
Decoding %82%B1%82%F1 as UTF-8 (this is Shift-JIS for こん)
✓ Correct 
Using UTF-8: %E3%81%93%E3%82%93 correctly decodes to こん

Encodage de chemins relatifs sans contexte

Encoder un chemin relatif comme ../images/photo.jpg avec encodeURIComponent transforme les barres obliques et les points en séquences encodées en pourcentage, cassant la structure du chemin. Utilisez encodeURI() ou n'encodez que les segments de chemin individuels.

✗ Incorrect 
encodeURIComponent('../images/photo.jpg')  → '..%2Fimages%2Fphoto.jpg'
✓ Correct 
Encode each segment: '../images/' + encodeURIComponent('my photo.jpg')

Cas d'utilisation courants

Débogage d'URLs illisibles
Décodez les URLs encodées en pourcentage provenant des journaux serveur, des messages d'erreur ou des outils de développement du navigateur pour lire le texte original lisible.
Développement d'APIs
Encodez les valeurs de paramètres de requête pour les appels API REST, en vous assurant que les caractères spéciaux comme &, = et les espaces ne cassent pas l'URL de requête.
Configuration de flux OAuth
Encodez correctement redirect_uri et les autres paramètres URL dans les URLs d'autorisation OAuth pour prévenir les échecs d'authentification.
URLs internationalisées
Encodez et décodez les URLs contenant des caractères chinois, japonais, coréens, arabes ou autres caractères non-ASCII pour les applications web internationalisées.
Analyse de liens marketing
Décodez les URLs de suivi des campagnes email et des plateformes publicitaires pour comprendre les paramètres UTM intégrés et les chaînes de redirection.
Inspection de structure URL
Analysez des URLs complexes en leurs composants — protocole, hôte, port, chemin, paramètres de requête et fragment — pour l'analyse et la modification.

Détails techniques

Caractères réservés et non réservés RFC 3986
La RFC 3986 définit les caractères non réservés (A-Z, a-z, 0-9, -, ., _, ~) qui n'ont jamais besoin d'encodage, et les caractères réservés (:, /, ?, #, [, ], @, !, $, &, ', (, ), *, +, ,, ;, =) qui servent de délimiteurs URI et doivent être encodés en pourcentage lorsqu'ils sont utilisés comme données.
Flux d'encodage des octets UTF-8
Les caractères non-ASCII sont d'abord convertis en leur point de code Unicode, puis encodés en octets UTF-8 (1 à 4 octets selon la plage du point de code), et enfin chaque octet est encodé en pourcentage comme %XX. Par exemple : é (U+00E9) → octets UTF-8 C3 A9 → %C3%A9. L'émoji 🎉 (U+1F389) → octets UTF-8 F0 9F 8E 89 → %F0%9F%8E%89.
Terminologie URL vs URI
Un URI (Identifiant Uniforme de Ressource) est le terme général pour toute chaîne d'identification. Une URL (Localisateur Uniforme de Ressource) est un URI qui spécifie aussi le mécanisme d'accès (comme https://). Les règles d'encodage de la RFC 3986 s'appliquent à tous les URIs. L'API JavaScript utilise la terminologie URI (encodeURI, decodeURI), tandis que l'usage courant préfère URL.

Bonnes pratiques

Utilisez le bon mode pour chaque tâche
Utilisez encodeURIComponent() pour les clés et valeurs de paramètres de requête individuels. N'utilisez encodeURI() que lorsque vous avez une URL complète et voulez encoder les caractères non sûrs sans casser sa structure. N'utilisez jamais encodeURI() sur des valeurs de paramètres pouvant contenir &, = ou d'autres caractères réservés.
Évitez le double encodage
Avant d'encoder une chaîne, vérifiez si elle est déjà encodée. Recherchez les séquences % existantes. Encoder une chaîne déjà encodée transforme %20 en %2520, %3D en %253D, etc. En cas de doute, décodez d'abord, puis encodez une fois.
Décodez côté serveur
La plupart des frameworks web décodent automatiquement les paramètres URL avant que votre code applicatif ne les voie. Évitez de décoder manuellement des paramètres que votre framework a déjà décodés — cela peut causer des problèmes si la valeur originale contenait des séquences de pourcentage littérales.
Encodez les valeurs pour OAuth et la signature API
Les chaînes de base de signature OAuth 1.0 et de nombreux algorithmes de signature API nécessitent un encodage en pourcentage strict RFC 3986. Utilisez encodeURIComponent() puis remplacez les caractères restants qu'il n'encode pas (comme !, ', (, ), *) par leurs équivalents encodés en pourcentage si la spécification l'exige.

Questions fréquentes

Qu'est-ce que l'encodage URL et pourquoi est-il nécessaire ?
L'encodage URL, également appelé encodage en pourcentage, est un mécanisme défini dans la RFC 3986 pour représenter les caractères qui ne sont pas autorisés dans un URI. Les URLs ne peuvent contenir qu'un ensemble limité de caractères du jeu ASCII — les lettres (A-Z, a-z), les chiffres (0-9) et quelques caractères spéciaux comme les tirets, traits de soulignement, points et tildes. Tout caractère en dehors de cet ensemble sûr doit être encodé sous forme d'un signe pourcentage (%) suivi de deux chiffres hexadécimaux représentant la valeur d'octet du caractère. Par exemple, un espace devient %20, une barre oblique devient %2F et une esperluette devient %26. Cet encodage est nécessaire car des caractères comme &, =, ? et # ont une signification structurelle spéciale dans les URLs — ils délimitent les paramètres de requête, les fragments et d'autres composants. Sans encodage, un & littéral dans une valeur de paramètre serait interprété comme un séparateur de paramètres, cassant complètement la structure de l'URL. L'encodage URL garantit que les données passent intactes à travers l'infrastructure HTTP, quel que soit leur contenu.
Quelle est la différence entre encodeURI et encodeURIComponent ?
Ces deux fonctions JavaScript servent des objectifs différents et encodent des ensembles de caractères différents. Comprendre quand utiliser chacune est essentiel pour éviter les URLs cassées. encodeURI() est conçu pour encoder un URI complet. Il préserve les caractères qui ont une signification structurelle dans une URL — deux-points (:), barres obliques (/), points d'interrogation (?), signes dièse (#), esperluettes (&) et signes égal (=) — car ces délimiteurs sont nécessaires au fonctionnement de l'URL. Utilisez encodeURI() quand vous avez une chaîne d'URL complète et que vous voulez simplement vous assurer que les caractères non sûrs (comme les espaces ou le texte non-ASCII) sont encodés, sans altérer sa structure. Par exemple, encodeURI('https://example.com/path name') produit 'https://example.com/path%20name', préservant le :// et le /. encodeURIComponent() est beaucoup plus agressif. Il encode presque tous les caractères non alphanumériques, y compris :, /, ?, #, & et =. Cela en fait le choix correct pour encoder des valeurs individuelles qui seront placées à l'intérieur d'une URL — le plus souvent des valeurs de paramètres de requête. Si vous utilisiez encodeURI() sur une valeur de paramètre contenant une esperluette, le & passerait non encodé et serait interprété comme un séparateur de paramètres. encodeURIComponent() l'encoderait correctement en %26. La règle d'or : utilisez encodeURIComponent() pour les clés et valeurs de paramètres, et encodeURI() uniquement pour encoder une URL complète où les délimiteurs structurels doivent rester intacts.
L'encodage URL est-il identique à l'encodage HTML ?
Non, ce sont des schémas d'encodage complètement différents conçus pour des objectifs différents. L'encodage URL (encodage en pourcentage) convertit les caractères en séquences hexadécimales %XX pour une utilisation sûre dans les URLs, tel que défini dans la RFC 3986. L'encodage HTML (aussi appelé encodage d'entités HTML) convertit les caractères en références d'entités comme & pour &, < pour < et " pour les guillemets, tel que défini dans la spécification HTML. L'encodage URL est pour le transport de données dans les URLs, tandis que l'encodage HTML est pour l'affichage sûr de contenu dans les documents HTML. Une erreur courante est d'appliquer l'encodage HTML aux paramètres URL ou vice versa. Par exemple, encoder un espace comme   dans une URL ne fonctionnerait pas — il doit être %20 ou +.
Pourquoi mon URL casse-t-elle dans une commande curl ?
Quand vous collez une URL contenant des caractères spéciaux dans une commande shell comme curl, le shell interprète les caractères comme &, ?, (, ) et # avant que curl ne les voie. L'esperluette (&) dit au shell d'exécuter la commande précédente en arrière-plan. Le point d'interrogation (?) déclenche le globbing de noms de fichiers. Le dièse (#) commence un commentaire, causant l'ignorance de tout ce qui suit. Pour corriger cela, entourez toujours votre URL de guillemets simples dans le shell : curl 'https://example.com/api?key=value&page=2#section'. Les guillemets simples empêchent le shell d'interpréter les caractères spéciaux. Vous pouvez aussi échapper les caractères individuels avec des barres obliques inversées, mais mettre l'URL entière entre guillemets est plus simple et moins sujet aux erreurs.
Pourquoi les caractères chinois deviennent-ils des chaînes comme %E4%B8%AD dans les URLs ?
Les caractères chinois (et tous les caractères non-ASCII) sont d'abord convertis en leur représentation en octets UTF-8, puis chaque octet est encodé en pourcentage. Par exemple, le caractère 中 a le point de code Unicode U+4E2D. En UTF-8, il est représenté par trois octets : 0xE4, 0xB8, 0xAD. Chaque octet est écrit comme un signe pourcentage suivi de deux chiffres hexadécimaux, produisant %E4%B8%AD. Ce processus en trois étapes — caractère vers point de code Unicode, point de code vers octets UTF-8, octets vers hexadécimal encodé en pourcentage — explique pourquoi un seul caractère chinois peut s'étendre à 9 caractères (%XX%XX%XX) dans une URL. Le même principe s'applique aux émojis, qui nécessitent souvent 4 octets UTF-8 et deviennent donc 12 caractères une fois encodés en pourcentage.
Faut-il encoder le paramètre redirect_uri dans OAuth ?
Oui, absolument. Le redirect_uri dans les flux OAuth est une URL complète qui est intégrée comme valeur de paramètre de requête dans une autre URL. Si vous ne l'encodez pas, les caractères spéciaux dans l'URI de redirection — notamment ?, & et = — seront interprétés comme faisant partie de la structure de l'URL externe plutôt que comme des caractères littéraux dans la valeur du paramètre. Par exemple, redirect_uri=https://myapp.com/callback?code=abc&state=xyz sans encodage ferait que le serveur d'autorisation verrait redirect_uri comme seulement https://myapp.com/callback?code=abc, tandis que state=xyz serait analysé comme un paramètre séparé de l'URL externe. La version correctement encodée est redirect_uri=https%3A%2F%2Fmyapp.com%2Fcallback%3Fcode%3Dabc%26state%3Dxyz. Utilisez toujours encodeURIComponent() sur toute la valeur de l'URI de redirection.
Quelle est la différence entre querystring et URLSearchParams dans Node.js ?
Node.js offre deux APIs pour gérer les chaînes de requête : le module legacy querystring et la classe plus récente URLSearchParams (partie du standard URL WHATWG). Le module querystring utilise sa propre logique d'encodage — notamment, il encode les espaces en %20 par défaut et a quelques particularités dans la gestion des tableaux (key=1&key=2 devient { key: ['1', '2'] }). URLSearchParams suit le standard du navigateur : il encode les espaces en + dans le format application/x-www-form-urlencoded, gère automatiquement les clés répétées via getAll(), et fournit une interface itérable avec les méthodes entries(), keys() et values(). Pour les nouveaux projets, URLSearchParams est recommandé car il correspond au comportement du navigateur, est conforme aux standards et fonctionne de manière identique dans Node.js et les navigateurs.
Comment encoder une URL en Python, JavaScript et Java ?
En JavaScript, utilisez encodeURIComponent() pour les valeurs de paramètres et encodeURI() pour les URLs complètes. Exemple : const encoded = encodeURIComponent('hello world'); produit 'hello%20world'. En Python 3, utilisez urllib.parse.quote() pour les segments de chemin et urllib.parse.urlencode() pour les paramètres de requête. Exemple : from urllib.parse import quote; quote('hello world') produit 'hello%20world'. Pour les chaînes de requête complètes : from urllib.parse import urlencode; urlencode({'q': 'hello world'}) produit 'q=hello+world'. En Java, utilisez URLEncoder.encode(value, StandardCharsets.UTF_8) pour les valeurs de paramètres. Notez que le URLEncoder de Java encode les espaces en + (encodage de formulaire), remplacez + par %20 si vous avez besoin de l'encodage RFC 3986.
Quels caractères ne sont pas encodés par l'encodage URL ?
La RFC 3986 définit un ensemble de « caractères non réservés » qui n'ont pas besoin d'encodage : les lettres majuscules A-Z, les lettres minuscules a-z, les chiffres 0-9, le tiret (-), le point (.), le trait de soulignement (_) et le tilde (~). Ces 66 caractères peuvent apparaître littéralement dans n'importe quelle partie d'une URL. De plus, les « caractères réservés » — :, /, ?, #, [, ], @, !, $, &, ', (, ), *, +, ; et = — sont autorisés dans leurs rôles structurels désignés mais doivent être encodés en pourcentage lorsqu'ils sont utilisés comme données littérales. La fonction encodeURIComponent() en JavaScript encode tout sauf A-Z a-z 0-9 - _ . ~ et ! ' ( ) *, tandis que encodeURI() préserve en plus les caractères réservés qui servent de délimiteurs URL.
Quelle est la différence entre + et %20 pour l'encodage des espaces ?
+ et %20 représentent tous deux un espace, mais ils proviennent de spécifications différentes. La convention + provient du format application/x-www-form-urlencoded défini dans la spécification HTML, utilisé quand les navigateurs soumettent des formulaires HTML. Dans ce format, les espaces sont encodés en + et le caractère + lui-même devient %2B. L'encodage %20 provient de la RFC 3986 (syntaxe URI), où chaque caractère non réservé est encodé comme un signe pourcentage suivi de deux chiffres hexadécimaux. En pratique moderne, %20 est le choix universellement sûr — il fonctionne dans toutes les parties d'une URL (chemin, requête, fragment). L'encodage + pour les espaces n'est valide que dans la chaîne de requête avec l'encodage de formulaire. Utiliser + dans un segment de chemin URL serait interprété comme un signe plus littéral, pas un espace. En cas de doute, utilisez %20.
Comment l'encodage URL gère-t-il les émojis ?
Les émojis sont encodés via le même processus d'encodage en pourcentage UTF-8 que tout autre caractère Unicode, mais ils nécessitent plus d'octets. La plupart des émojis utilisent des points de code dans la plage U+1F000 à U+1FFFF (ou supérieure), nécessitant 4 octets en encodage UTF-8. Chaque octet est ensuite encodé en pourcentage, donc un seul caractère émoji s'étend typiquement à 12 caractères dans une URL. Par exemple, l'émoji fusée (🚀, U+1F680) est encodé en UTF-8 comme les octets F0 9F 9A 80, ce qui devient %F0%9F%9A%80 dans une URL. Certains émojis avec des modificateurs de teinte de peau ou des séquences ZWJ peuvent consister en plusieurs points de code et s'étendre à plus de 30 caractères une fois encodés.
L'encodage URL peut-il être utilisé pour le chiffrement ou la sécurité ?
Non. L'encodage URL n'est pas du chiffrement et ne fournit aucune sécurité. C'est une transformation purement mécanique, déterministe et entièrement réversible — n'importe qui peut décoder une chaîne encodée en pourcentage instantanément sans aucune clé ou secret. L'encodage URL existe uniquement pour rendre les données arbitraires sûres pour le transport dans les URLs en échappant les caractères qui auraient autrement une signification structurelle. Traiter l'encodage URL comme une forme d'obfuscation ou de sécurité est une idée fausse dangereuse. Les données sensibles comme les mots de passe, jetons ou informations personnelles dans les URLs doivent être protégées par HTTPS (chiffrement TLS de l'ensemble de la requête), pas par l'encodage URL.
Quelle est la longueur maximale d'une URL ?
Les spécifications HTTP (RFC 7230) ne définissent pas de longueur maximale d'URL, mais des limites pratiques existent à chaque couche. La plupart des navigateurs modernes supportent des URLs jusqu'à environ 2 048 caractères (la limite historique d'Internet Explorer), bien que Chrome et Firefox puissent gérer des URLs dépassant 100 000 caractères. Les serveurs web imposent leurs propres limites : Apache par défaut 8 190 octets, Nginx 8 192 octets et IIS 16 384 octets pour la chaîne de requête. Les CDN et proxies peuvent avoir des limites encore plus strictes. Quand l'encodage URL étend les caractères — surtout le texte non-ASCII — une URL apparemment courte peut rapidement approcher ces limites. En bonne pratique, gardez les URLs sous 2 000 caractères pour une compatibilité maximale.
Quelle est la différence entre une URL et un URI ?
Un URI (Identifiant Uniforme de Ressource) est le concept le plus large — c'est toute chaîne qui identifie une ressource. Une URL (Localisateur Uniforme de Ressource) est un type spécifique d'URI qui fournit aussi les moyens de localiser la ressource en décrivant son mécanisme d'accès (protocole) et son emplacement réseau. Par exemple, https://example.com/page est à la fois un URI et une URL car il identifie une ressource et vous dit comment y accéder (via HTTPS sur example.com). Un URN (Nom Uniforme de Ressource) comme urn:isbn:0451450523 est un URI mais pas une URL — il identifie un livre par ISBN mais ne vous dit pas où le trouver. En développement web quotidien, les termes URL et URI sont souvent utilisés de façon interchangeable, et les règles d'encodage définies dans la RFC 3986 s'appliquent aux deux.

Outils connexes

Voir tous les outils →

Décodeur et Encodeur Base64

Encodage et formatage

Décodez et encodez en Base64 en ligne gratuitement. Conversion en temps réel, support UTF-8 et émojis. 100 % privé — dans votre navigateur. Sans inscription.

Formateur et Validateur JSON

Encodage et formatage

Formatez, validez et embellissez vos JSON dans le navigateur. Outil gratuit avec validation syntaxique, detection d'erreurs, minification et copie. 100 % prive.

Convertisseur de Base — Binaire, Hex, Décimal & Octal

Outils de conversion

Convertissez des nombres entre binaire, hexadécimal, décimal, octal et toute base personnalisée (2-36) instantanément. Gratuit, privé, sans inscription — tout se passe dans votre navigateur.

Compressez vos Images JPEG, PNG & WebP en Ligne

Outils de conversion

Compressez vos images JPEG, PNG & WebP gratuitement dans le navigateur — aucun envoi serveur. Lots de 20 images, qualité réglable, comparaison avant/après. 100% privé, sans inscription.

Convertisseur de Longueur — Mètres, Pieds, Pouces

Outils de conversion

1 pouce = 2,54 cm, 1 pied = 0,3048 m, 1 mile = 1,609 km. Convertissez entre 16 unités de longueur instantanément — métriques, impériales et astronomiques. Gratuit et privé.

Générateur de Hash MD5 en Ligne et Vérificateur de Checksum

Outils de sécurité

Générez des hashes MD5, SHA-256, SHA-1 et SHA-512 gratuitement — 100% dans votre navigateur, sans inscription. Hachez texte ou fichiers, vérifiez les checksums et comparez les hashes en un clic. Vos données restent privées.