JSON : URL Encode

Encodez vos données JSON pour une utilisation sûre dans les URLs.

JSON Source

Encodage

Options

Minifier avant encodage Valider JSON

Résultat

URL Encodé

Guide complet de l'encodage JSON URL : maîtriser le percent-encoding

Pourquoi j'encode systématiquement mon JSON pour les URLs

Chaque fois que je dois passer des données structurées via une URL — filtres de recherche avancée, état d'application, configurations dynamiques — je me heurte au même problème : JSON utilise des caractères ({, }, ", :, [, ]) qui ont des significations spéciales dans les URLs ou sont tout simplement interdits. Sans encodage, le serveur reçoit des données corrompues, les query strings sont mal parsées, et l'application plante mystérieusement. Le percent-encoding transforme chaque caractère problématique en une séquence %XX sûre pour le transport URL.

Comprendre les deux types d'encodage

🌐 encodeURI() — Pour les URLs complètes

Encode les caractères non-ASCII et les espaces, mais préserve la structure URL : / : ? & = # ne sont PAS encodés. Utilisez-le quand vous avez une URL entière à rendre sûre, pas pour des valeurs de paramètres.

🔒 encodeURIComponent() — Pour les valeurs

Encode TOUT sauf les lettres, chiffres, et quelques caractères sûrs (- _ . ~). C'est le bon choix pour encoder du JSON destiné à un paramètre ?data=... car il encode aussi : / ? & =

📦 Minification préalable

Chaque espace devient %20 (3 caractères), chaque retour ligne %0A. Un JSON formaté peut tripler de taille après encodage ! Minifier d'abord supprime ces caractères inutiles, réduisant drastiquement la taille de l'URL finale.

⚠️ Piège du double encodage

Si votre JSON contient déjà des % (rare mais possible), ils seront encodés en %25. Si vous encodez deux fois par erreur, %7B devient %257B. Toujours encoder une seule fois, le plus tard possible dans la chaîne.

Comment utiliser cet outil

Collez votre JSON — Dans l'éditeur de gauche, avec ou sans formatage
Choisissez vos options — « Minifier avant encodage » est recommandé pour réduire la taille
Sélectionnez le type d'encodage — « Encoder Composant » (encodeURIComponent) pour les valeurs de paramètres, « Encoder URL » (encodeURI) pour une URL complète
Copiez le résultat — Prêt à être intégré dans votre URL

Référence des encodages JSON courants

Espace → %20
" (guillemet) → %22
{ → %7B et } → %7D
[ → %5B et ] → %5D
: → %3A (avec encodeURIComponent)
, → %2C
/ → %2F (avec encodeURIComponent)
? → %3F (avec encodeURIComponent)
& → %26 (avec encodeURIComponent)
= → %3D (avec encodeURIComponent)

Cas d'usage concrets

J'utilise cet outil quotidiennement pour construire des URLs de partage avec état (filtres de recherche pré-remplis), passer des configurations complexes à des widgets embedés, créer des deep links pour applications mobiles, et déboguer des URLs générées par d'autres systèmes. Tout traitement se fait localement dans votre navigateur — aucune donnée n'est transmise.

Questions fréquentes

Quelle est la vraie différence entre encodeURI et encodeURIComponent ?

La différence est cruciale et source de nombreux bugs :

encodeURI() — Préserve les caractères structurels d'URL : ; / ? : @ & = + $ , #. Utilisé pour rendre une URL complète valide (ex: espaces dans un chemin)
encodeURIComponent() — Encode TOUS ces caractères, ne laissant que lettres, chiffres et - _ . ~. Utilisé pour les valeurs de paramètres

Pour du JSON dans ?data=..., utilisez TOUJOURS encodeURIComponent(). Sinon, les : et , de votre JSON casseront la structure de l'URL.

Pourquoi est-il si important de minifier avant d'encoder ?

L'impact sur la taille est dramatique. Voici un exemple concret :

JSON formaté : {"name": "test", "value": 123} avec indentation = ~50 caractères
Après encodage des espaces/sauts de ligne : ~150 caractères (x3 !)
JSON minifié puis encodé : ~80 caractères

Les navigateurs limitent les URLs à ~2000-8000 caractères. Avec un JSON complexe, la minification peut faire la différence entre une URL fonctionnelle et une URL tronquée.

Mon JSON encodé dépasse la limite d'URL — quelles alternatives ?

Plusieurs stratégies quand le JSON est trop volumineux :

POST au lieu de GET — Le body HTTP n'a pas de limite pratique. Changez votre endpoint si possible
Stockage côté serveur — Sauvegardez le JSON, retournez un ID court. L'URL devient ?state=abc123
Compression — Utilisez LZ-string ou pako (zlib) pour compresser, puis Base64URL. Réduction de 50-80% typique
Fragment (#) — Le hash n'est pas envoyé au serveur mais peut stocker des données lues en JavaScript
localStorage + référence — Stockez localement, passez juste un identifiant

L'encodage est-il parfaitement réversible ? Aucune perte de données ?

Oui, le percent-encoding est 100% réversible. decodeURIComponent() reconstruit exactement la chaîne originale.

Nuances :

Si vous avez minifié, le formatage (indentation, espaces) est perdu — mais les DONNÉES sont intactes
Les types JSON (nombres, booléens, null) sont préservés car le JSON est d'abord sérialisé en texte
Les caractères Unicode (accents, emojis) sont correctement encodés en UTF-8 puis percent-encoded

Utilisez notre outil JSON URL Decode pour le décodage inverse.

Comment éviter le piège du double encodage ?

Le double encodage arrive quand vous encodez une chaîne déjà encodée. Résultat : %7B devient %257B (%25 = %).

Pour l'éviter :

Encodez une seule fois — Le plus tard possible, juste avant de construire l'URL
Vérifiez l'input — Si votre JSON contient déjà des %XX, c'est suspect
Testez avec décodage — decodeURIComponent(encoded) doit retourner exactement votre JSON original

Certains frameworks (ASP.NET, certaines configs Java) encodent automatiquement les query strings. Si vous pré-encodez, vous aurez un double encodage. Connaissez votre stack !

Dois-je encoder le JSON si je l'envoie en body POST ?

Non ! L'encodage URL est spécifique aux URLs (query strings, fragments). Pour un body POST :

Content-Type: application/json — Envoyez le JSON brut tel quel, pas d'encodage
Content-Type: application/x-www-form-urlencoded — Là oui, encodage nécessaire (mais pas le format idéal pour du JSON)

En résumé : utilisez application/json en POST et n'encodez rien. L'encodage URL n'est utile que pour passer des données DANS l'URL elle-même.

Le + est-il une alternative valide à %20 pour les espaces ?

Ça dépend du contexte — c'est une source de confusion fréquente :

application/x-www-form-urlencoded (formulaires HTML) — + représente un espace, c'est la convention historique
RFC 3986 (URLs modernes) — + est un caractère littéral, seul %20 représente un espace

encodeURIComponent() produit %20, pas +. C'est le comportement correct pour les query strings modernes. Si vous voyez des +, c'est probablement du form-urlencoded legacy.

Mes données sont-elles sécurisées lors de l'encodage ?

Oui, tout le traitement se fait localement :

L'encodage est effectué en JavaScript dans votre navigateur
Aucune donnée n'est transmise à un serveur
Aucun log, aucune analytics sur votre JSON
Vérifiable dans les DevTools (onglet Network)

Attention : l'encodage URL n'est PAS du chiffrement. Le JSON encodé reste lisible (juste transformé). Ne mettez pas de secrets dans des URLs, même encodés — ils apparaissent dans les logs serveur, l'historique du navigateur, etc.