टाइप करते ही Base64, Base64URL, URL परसेंट-एन्कोडिंग, HTML एंटिटी और हेक्स को एन्कोड या डिकोड करें, पूर्ण UTF-8 समर्थन के साथ।
आप जो भी दर्ज करते हैं वह संग्रहीत नहीं होता - उसी अनुरोध में बदलकर लौटा दिया जाता है।
लॉग में कोई टोकन, रीडायरेक्ट में क्वेरी स्ट्रिंग, & से भरा ईमेल: काम में एन्कोड किया गया टेक्स्ट हर जगह मिलता है। उसे यहाँ पेस्ट करें, फ़ॉर्मेट चुनें और टाइप करते ही एन्कोड या डिकोड किया गया नतीजा देखें।
JSON Web Token डॉट से जुड़े तीन Base64URL हिस्से होते हैं: हेडर, पेलोड और सिग्नेचर। बीच वाला हिस्सा पेस्ट करें, Base64URL चुनें और डिकोड करें, तो आपको JSON क्लेम दिखेंगे, जैसे यूज़र id और exp समाप्ति समय (एक Unix टाइमस्टैम्प जिसे Unix टाइमस्टैम्प कन्वर्टर से पढ़ सकते हैं)। डिकोड करना सत्यापन नहीं है: JWT का पेलोड कोई भी पढ़ सकता है, और सर्वर पर सिग्नेचर की जाँच ही साबित करती है कि उसे बदला नहीं गया।
पैडिंग हटाया हुआ Base64, जो कुछ सिस्टम जगह बचाने के लिए करते हैं, सख़्त डिकोडर में फेल होता है; यह टूल छूटे = चिह्न जोड़ता है और आपको बताता है। कई सर्वर क्वेरी स्ट्रिंग में + को स्पेस मानते हैं, इसलिए लिंक में बिना एन्कोड किए पेस्ट किया गया Base64 मान बिगड़कर पहुँचता है; उसे URL कंपोनेंट की तरह एन्कोड करें या Base64URL इस्तेमाल करें। दो बार एन्कोड किया गया टेक्स्ट %2520 या & जैसा दिखता है और उसे दो बार डिकोड करना पड़ता है।
Base64 डिकोडिंग स्पेस और लाइन ब्रेक को अनदेखा करती है, इसलिए ईमेल की तरह कई पंक्तियों में टूटा मान जैसा पेस्ट किया गया वैसा ही डिकोड होता है। Base64URL डिकोडिंग + और / भी स्वीकार करती है, पर सामान्य Base64 - और _ को अस्वीकार करता है, इसलिए JWT के हिस्से के लिए Base64URL विकल्प चुनें। Hex डिकोडिंग स्पेस, कोलन, कॉमा, डैश और 0x प्रीफ़िक्स छोड़ देती है, इसलिए 48:65:6c:6c:6f और 0x48 0x65 दोनों चलते हैं। URL डिकोडिंग + को स्पेस में बदलती है, इसलिए असली प्लस चिह्न %2B के रूप में आना चाहिए। HTML एन्कोडिंग पाँच अक्षरों & < > " और ' को एस्केप करती है; HTML डिकोडिंग और … जैसी हर HTML5 नामित एंटिटी और रुपये के चिह्न के लिए ₹ जैसी संख्यात्मक एंटिटी समझती है।
यहाँ URL एन्कोडिंग एक ही वैल्यू को एन्कोड करती है, जैसे एक क्वेरी पैरामीटर, इसलिए हर आरक्षित अक्षर एस्केप होता है: https://example.com/a b?x=1&y=2 बन जाता है https%3A%2F%2Fexample.com%2Fa%20b%3Fx%3D1%26y%3D2. लिंक में डाली जाने वाली वैल्यू को ही एन्कोड करें, पूरे लिंक को कभी नहीं. ASCII के बाहर का टेक्स्ट अपने UTF-8 बाइट्स के रूप में एन्कोड होता है: café ₹ बन जाता है caf%C3%A9%20%E2%82%B9, और हेक्स वही बाइट्स दिखाता है, é को c3 a9 और ₹ को e2 82 b9. user:pass का Base64 dXNlcjpwYXNz है, यही वैल्यू HTTP Basic Authorization हेडर में जाती है (RFC 7617), इसलिए जो भी वह हेडर देखे वह पासवर्ड पढ़ सकता है.
बाइट UTF-8 थे, लेकिन एन्कोड होने से पहले कहीं उन्हें Latin-1 या Windows-1252 के रूप में पढ़ा गया। यहाँ डिकोडिंग बाइट को जैसे हैं वैसे दिखाती है; सुधार उस सिस्टम में होना चाहिए जिसने उन्हें बनाया।
2,00,000 अक्षरों तक का टेक्स्ट पेस्ट करें। इमेज जैसी बाइनरी फ़ाइलों के डिकोड किए बाइट डाउनलोड बनने की जगह hex में दिखाए जाते हैं।
नहीं। Base64 सिर्फ़ बाइट लिखने का तरीका बदलता है ताकि वे सादा टेक्स्ट चाहने वाले सिस्टम से सुरक्षित निकल सकें। इसे कोई भी डिकोड कर सकता है; पासवर्ड या कोई राज़ छिपाने के लिए इसका इस्तेमाल कभी न करें।
Base64URL "+" और "/" की जगह "-" और "_" लगाता है और आमतौर पर "=" पैडिंग हटा देता है, ताकि नतीजा URL और फ़ाइल नामों में सुरक्षित रहे। JSON Web Token इसी का इस्तेमाल करते हैं।
नहीं। उसे उसी अनुरोध में बदलकर लौटा दिया जाता है और कभी डेटाबेस या लॉग में नहीं लिखा जाता।
यह टूल ! ' ( ) और * को भी एस्केप करता है, जिन्हें encodeURIComponent वैसे ही छोड़ देता है, इसलिए it's (50%) off! बन जाता है it%27s%20%2850%25%29%20off%21. दोनों रूप डिकोड होकर एक ही टेक्स्ट देते हैं, और क्वेरी वैल्यू के अंदर इन अक्षरों को एस्केप करना हमेशा सुरक्षित है. स्पेस %20 बनता है, + नहीं; + वाला रूप HTML फ़ॉर्म एन्कोडिंग से आता है, और यहाँ का डिकोडर दोनों पढ़ लेता है.
Linux या Mac पर echo -n 'Hello, World' | base64 से SGVsbG8sIFdvcmxk मिलता है, और echo 'SGVsbG8sIFdvcmxk' | base64 --decode उसे वापस टेक्स्ट बना देता है। -n छोड़ देने पर echo एक नई लाइन जोड़ देता है जो भी एन्कोड हो जाती है, और नतीजा SGVsbG8sIFdvcmxkCg== आता है: दो टूल के अलग नतीजे देने की सबसे आम वजह यही है। PowerShell में [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes('Hello, World')) एन्कोड करता है और [Text.Encoding]::UTF8.GetString([Convert]::FromBase64String('SGVsbG8sIFdvcmxk')) डिकोड करता है। यह पेज ठीक वही अक्षर UTF-8 में एन्कोड करता है जो आप पेस्ट करते हैं, और कोई नई लाइन नहीं जोड़ता।
सिर्फ़ कॉमा के बाद वाला हिस्सा पेस्ट करें: data:image/png;base64,iVBORw0KGgo... में वह iVBORw0KGgo... है, क्योंकि data:image/png;base64, वाला प्रीफ़िक्स Base64 नहीं है और पूरी स्ट्रिंग अस्वीकार हो जाती है। Base64 और Decode चुनें। जो बाइट टेक्स्ट नहीं हैं वे तस्वीर बनने की जगह hex में दिखते हैं, और फ़ाइल का प्रकार पहचानने के लिए इतना काफ़ी है: PNG की शुरुआत 89 50 4e 47 से, JPEG की ff d8 ff से और पूरी .docx, .xlsx या किसी और ZIP-आधारित फ़ाइल की 50 4b 03 04 से होती है। इमेज ख़ुद देखने के लिए पूरा data URI ब्राउज़र के एड्रेस बार में पेस्ट करें। इनपुट की सीमा 2,00,000 अक्षर है, यानी लगभग 1,50,000 बाइट की फ़ाइल।
Base64 हर 3 बाइट को 4 अक्षरों में लिखता है और आख़िरी समूह को 4 के गुणज तक = से भरता है (RFC 4648), इसलिए आउटपुट इनपुट बाइट का 4/3 होता है, ऊपर की ओर पूर्णांकित। Hello, World 12 बाइट है और 16 अक्षरों वाला SGVsbG8sIFdvcmxk बनता है। गिनती UTF-8 बाइट में होती है, अक्षरों में नहीं: café 4 अक्षर पर 5 बाइट है और Y2Fmw6k= बनता है, और ₹100 6 बाइट है और 4oK5MTAw बनता है। हिंदी का हर अक्षर UTF-8 में 3 बाइट लेता है, इसलिए हिंदी टेक्स्ट का Base64 अक्षरों की गिनती से कहीं लंबा होता है। ईमेल अटैचमेंट थोड़े और बढ़ते हैं, क्योंकि MIME Base64 को अधिकतम 76 अक्षरों की पंक्तियों में तोड़ता है (RFC 2045); यह पेज डिकोड करते समय उन लाइन ब्रेक को अनदेखा करता है। बिना पैडिंग वाला Base64URL सिर्फ़ = चिह्न बचाता है।