পার্সেন্ট এনকোডিংয়ের মাধ্যমে 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-তে এনকোড করা মুজিবেক URL-এর দেখা মেলে। এই টুল জুড়ে UTF-8 ব্যবহৃত হয়, যা ব্রাউজার এবং বর্তমান প্রতিটি সার্ভার ফ্রেমওয়ার্ক প্রত্যাশা করে।
encodeURIComponent নিরাপদ ডিফল্ট এবং সব রিজার্ভড ক্যারেক্টার এস্কেপ করে। যখনই আপনি একটি URL-এর ভেতরে মান ঢোকাচ্ছেন তখনই এটি ব্যবহার করুন। encodeURI ইচ্ছাকৃতভাবে রিজার্ভড ক্যারেক্টার সংরক্ষণ করে যাতে একটি সম্পূর্ণ URL অক্ষত থাকে — এটি শুধুমাত্র ইতিমধ্যে তৈরি একটি URL পরিপাটি করতে ব্যবহার করুন, কখনো পৃথক প্যারামিটারে নয়, কারণ এটি আপনার মানের ভেতরে & রেখে দিতে পারে এবং কোয়েরি স্ট্রিং নষ্ট করতে পারে।
ফর্ম মোডটি আলাদা। application/x-www-form-urlencoded সিরিয়ালাইজেশন, যা আধুনিক URL স্পেসিফিকেশনের আগের, একটি স্পেসকে %20-এর বদলে + হিসেবে এনকোড করে। উভয়ই কোয়েরি স্ট্রিংয়ে সঠিক এবং সার্ভার দুটোই গ্রহণ করে, তবে আপনি যদি হাতে একটি POST অনুরোধের বডি তৈরি করেন তবে ফর্ম কনভেনশন মেনে চলা উচিত।
+-এর অস্পষ্টতাফর্ম এনকোডিং +-কে বিশেষ অর্থ দেয় বলে, একটি ফর্ম মানের আক্ষরিক প্লাস চিহ্নকে নিজেই %2B হিসেবে এনকোড করতে হয়। এটি বাস্তব জগতে সবচেয়ে সাধারণ এনকোডিং বাগ: একটি base64 স্ট্রিং বা আন্তর্জাতিক ফরম্যাটের ফোন নম্বর যেমন আছে তেমনই পাঠানো হয়, এবং গ্রহণকারী পক্ষ প্রতিটি +-কে স্পেসে পরিণত করে। আপনার ডেটাতে প্লাস চিহ্ন থাকতে পারে এমন হলে, সেগুলো স্পষ্টভাবে এনকোড করুন অথবা ফর্ম মোড এড়িয়ে চলুন।
ইতিমধ্যে এনকোড করা একটি স্ট্রিং এনকোড করলে প্রতিটি % %25 হয়ে যায়, তাই %20 হয়ে যায় %2520। এটি সাধারণত একটি বাগ — অ্যাপ্লিকেশন কোড একটি মান এনকোড করার পর কোনো ফ্রেমওয়ার্ক বা প্রক্সি আবার এনকোড করলে এমন হয়। এমন URL-এ %25 দেখলে যেখানে আপনি আক্ষরিক পার্সেন্ট চিহ্ন চাননি, সেখানে আপনি একটি ডাবল-এনকোডেড মান দেখছেন। দুবার ডিকোড করলে আসল মান ফিরে পাওয়া যায়, কিন্তু আসল সমাধান হলো এনকোডিং ধাপগুলোর একটি সরিয়ে ফেলা।