प्रतिशत एनकोडिंग के साथ URL और क्वेरी स्ट्रिंग्स को एनकोड और डिकोड करें। कंपोनेंट, फुल-URI या फॉर्म-डेटा मोड चुनें, और जैसे ही आप टाइप करें दोनों दिशाओं में बदलें।
URL के लिए टेक्स्ट को प्रतिशत-एनकोड करें, या इसे वापस डिकोड करें। किसी भी बॉक्स में टाइप करें और दूसरा तुरंत अपडेट हो जाता है। वह मोड चुनें जो उस स्थान से मेल खाता हो जहाँ मान का उपयोग होगा: एकल क्वेरी पैरामीटर, पूरा URL, या एक HTML फॉर्म सबमिशन।
एक URL मुक्त-रूप टेक्स्ट नहीं है। ?, #, &, / और = जैसे वर्ण रिज़र्व्ड होते हैं: वे संरचनात्मक अर्थ लिए होते हैं, जो यह चिह्नित करते हैं कि पथ कहाँ समाप्त होता है और क्वेरी कहाँ शुरू, या एक पैरामीटर को अगले से अलग करते हैं। यदि आपका भेजा जाने वाला मान इनमें से किसी वर्ण को शामिल करता है, तो दूसरे छोर का पार्सर आपके URL को गलत पढ़ेगा। प्रतिशत एनकोडिंग इसे हल करती है: दोषी बाइट को % और उसके दो-अंकीय हेक्साडेसिमल मान से बदल देती है, ताकि मान के अंदर की & %26 के रूप में यात्रा करे और कभी भी सेपरेटर के रूप में गलत न समझी जाए।
RFC 3986 वर्ण स्थान को तीन समूहों में बाँटता है।
A-Z a-z 0-9 - . _ ~। इन्हें एनकोडिंग की कभी ज़रूरत नहीं होती और इन्हें वैसे ही छोड़ना चाहिए। फिर भी इन्हें एनकोड करना वैध है पर इससे भद्दे URL बनते हैं और साधारण स्ट्रिंग तुलनाएँ टूट सकती हैं।: / ? # [ ] @ ! $ & ' ( ) * + , ; =। ये केवल वहीं सुरक्षित हैं जहाँ ये संरचनात्मक हों। किसी मान के अंदर इन्हें एनकोड किया जाना चाहिए।प्रतिशत एनकोडिंग बाइट्स पर काम करती है, वर्णों पर नहीं, इसलिए टेक्स्ट को पहले बाइट्स में बदलना होता है। आधुनिक उत्तर हमेशा UTF-8 है। € चिह्न UTF-8 में तीन बाइट्स (E2 82 AC) का होता है, इसलिए यह %E2%82%AC में एनकोड होता है। पुरानी प्रणालियाँ कभी-कभी पेज की अपनी चारसेट का उपयोग करती थीं, जिस कारण आप कभी-कभी अभी भी Latin-1 या GBK में एनकोड किए गए mojibake URL मिलते हैं। यह उपकरण शुरू से अंत तक UTF-8 का उपयोग करता है, जो ब्राउज़र्स और हर वर्तमान सर्वर फ्रेमवर्क की अपेक्षा से मेल खाता है।
encodeURIComponent सुरक्षित डिफ़ॉल्ट है और सभी रिज़र्व्ड वर्णों को एस्केप करता है। इसका उपयोग तब करें जब आप किसी URL के अंदर मान डाल रहे हों। encodeURI जानबूझकर रिज़र्व्ड वर्णों को सुरक्षित रखता है ताकि पूरा URL बरकरार रहे — इसका उपयोग केवल किसी पहले से बने URL को साफ करने के लिए करें, कभी किसी व्यक्तिगत पैरामीटर पर नहीं, क्योंकि यह आपके मान में & को वैसे ही छोड़ देगा और क्वेरी स्ट्रिंग को खराब कर देगा।
फॉर्म मोड अजीब है। application/x-www-form-urlencoded सीरियलाइज़ेशन, जो आधुनिक URL विनिर्देशों से पुराना है, रिक्त स्थान को %20 के बजाय + के रूप में एनकोड करता है। दोनों क्वेरी स्ट्रिंग में सही हैं, और सर्वर दोनों को स्वीकार करते हैं, पर यदि आप हाथ से किसी POST अनुरोध का बॉडी बना रहे हैं तो आपको फॉर्म परंपरा से मेल खाना चाहिए।
+ की अस्पष्टताचूँकि फॉर्म एनकोडिंग + को विशेष अर्थ देती है, इसलिए फॉर्म मान में साक्षर प्लस चिह्न को स्वयं %2B के रूप में एनकोड किया जाना चाहिए। यह वास्तविक दुनिया में सबसे आम एनकोडिंग बग है: base64 स्ट्रिंग या अंतरराष्ट्रीय प्रारूप में फोन नंबर वैसे ही भेज दिया जाता है, और प्राप्त करने वाला पक्ष हर + को रिक्त स्थान में बदल देता है। यदि आपके डेटा में प्लस चिह्न हो सकते हैं, तो या तो उन्हें स्पष्ट रूप से एनकोड करें या फॉर्म मोड से बचें।
किसी पहले से एनकोडेड स्ट्रिंग को एनकोड करने से हर % %25 में बदल जाता है, इसलिए %20 %2520 बन जाता है। यह आमतौर पर एक बग है — यह तब होता है जब कोई मान एप्लिकेशन कोड द्वारा एनकोड किया जाता है और फिर किसी फ्रेमवर्क या प्रॉक्सी द्वारा। यदि आप किसी URL में %25 देखें जहाँ आपने कोई शाब्दिक प्रतिशत चिह्न इरादा नहीं किया था, तो आप एक डबल-एनकोडेड मान देख रहे हैं। दो बार डिकोड करने से मूल प्राप्त हो जाता है, पर असली सुधार एनकोडिंग चरणों में से एक को हटाना है।