Base64 एनकोड / डिकोड

Base64 एनकोड या डिकोड कैसे करें

1. अपना टेक्स्ट इनपुट बॉक्स में पेस्ट कीजिए।
2. प्लेन टेक्स्ट को Base64 में बदलने के लिए Encode चुनिए, या उल्टी दिशा के लिए Decode।
3. टाइप करते ही रिज़ल्ट तुरंत दिख जाता है।
4. अगर डिकोडिंग फ़ेल हो, तो मिसिंग पैडिंग (=) या ऐसे कैरेक्टर देखिए जो वैध Base64 नहीं हैं।
5. आउटपुट लेने के लिए Copy पर क्लिक कीजिए।

असल काम में Base64 कहाँ मिलता है

JWT का बीच वाला सेगमेंट Base64url-एनकोडेड JSON होता है, इसलिए इसे डिकोड करने पर टोकन के क्लेम दिख जाते हैं। Basic Auth हेडर Base64 में 'user:password' होता है। data URI इमेज को CSS या HTML में Base64 के रूप में एम्बेड करते हैं। Kubernetes secrets, SAML रिस्पॉन्स और ईमेल अटैचमेंट भी इसी का इस्तेमाल करते हैं।

एक पेच: स्टैंडर्ड Base64 में + और / होते हैं, जबकि JWT में इस्तेमाल होने वाले URL-safe वेरिएंट में इनकी जगह - और _ होते हैं। अगर कोई JWT सेगमेंट डिकोड न हो, तो आमतौर पर यही कैरेक्टर का फ़र्क़ (या हटी हुई पैडिंग) वजह होती है।

एनकोडिंग एन्क्रिप्शन नहीं है — पहले यह पढ़ें

Base64 के बारे में समझने की सबसे ज़रूरी बात यही है: यह कोई भी सुरक्षा या गोपनीयता बिल्कुल नहीं देता। यह बाइनरी डेटा और 64 छपने-योग्य कैरेक्टर के बीच एक सार्वजनिक, रिवर्सिबल मैपिंग है। आपकी Base64 स्ट्रिंग देखने वाला कोई भी इसे एक ही कदम में डिकोड कर सकता है, इसी टूल से, और मूल को पूरा पढ़ सकता है। कोई key नहीं, कोई पासवर्ड नहीं, और तोड़ने को कुछ भी नहीं।

इसलिए किसी राज़ को छिपाने के लिए Base64 ग़लत चुनाव है। अगर कोई कॉन्फ़िग फ़ाइल पासवर्ड को Base64 में 'एनकोडेड' रखती है, तो उस पासवर्ड को प्लेनटेक्स्ट ही मानें। डेटा को असल में सुरक्षित रखने के लिए आपको असली एन्क्रिप्शन (गोपनीयता के लिए) या bcrypt या argon2 जैसे मज़बूत एल्गोरिदम से हैशिंग (पासवर्ड के लिए) चाहिए। Base64 सिर्फ़ बाइनरी को टेक्स्ट की तरह भेजना सुरक्षित बनाता है; यह उसे कभी निजी नहीं बनाता।

आपके ब्राउज़र में यह बदलाव कैसे होता है

एनकोडिंग आपके टेक्स्ट को उसके UTF-8 बाइट में बदलती है, फिर उन बाइट को तीन-तीन (24 बिट) के ब्लॉक में समूहित करके चार 6-बिट टुकड़ों में फिर से बाँटती है। हर 6-बिट मान 64-कैरेक्टर वर्णमाला में एक index की तरह काम करता है, इसीलिए Base64 आउटपुट हमेशा चार का गुणज होता है, और जब इनपुट की लंबाई तीन से भाग न हो तो आख़िरी समूह को = चिह्न पैड करते हैं।

यह सारा गणित आपके अपने डिवाइस पर JavaScript में उसी पल होता है जब आप टाइप करते हैं। कुछ भी कहीं नहीं भेजा जाता, इसलिए रिज़ल्ट तुरंत दिखता है और पेज लोड होने के बाद टूल ऑफ़लाइन भी काम करता रहता है। डिकोडिंग बस इस प्रक्रिया को उलट देती है: यह चार कैरेक्टर को वापस तीन बाइट में पढ़ती है और बाइट स्ट्रीम को फिर से UTF-8 टेक्स्ट के रूप में समझती है।

टोकन और क्रेडेंशियल डिकोड करते समय निजता

लोग जिन स्ट्रिंग को सबसे ज़्यादा डिकोड करना चाहते हैं, वे ठीक वही हैं जिन्हें किसी सर्वर-साइड टूल में कभी पेस्ट नहीं करना चाहिए: JWT, Basic Auth हेडर, session cookies, signed webhook पेलोड, और किसी Kubernetes manifest से निकाले secrets। चूँकि ये अक्सर असली सिस्टम तक पहुँच देते हैं, इन्हें जाँचने के लिए अपलोड करना जीती-जागती क्रेडेंशियल सौंप देना होगा।

यहाँ डिकोडिंग सिर्फ़ आपके ब्राउज़र में चलती है, इसलिए क्लेम झाँकने के लिए आप जो टोकन पेस्ट करते हैं वह कभी आपकी मशीन से बाहर नहीं जाता और कहीं लॉग नहीं होता। टैब बंद करते ही वह चला जाता है। फिर भी सुनहरा नियम लागू रहता है: यही तथ्य कि आप किसी JWT को एक सेकंड में डिकोड कर सकते हैं, बिल्कुल यही वजह है कि उस कंटेंट को गुप्त रखने के लिए Base64 पर कभी भरोसा नहीं करना चाहिए।

स्टैंडर्ड Base64 बनाम URL-safe वेरिएंट

दो रूप मौजूद हैं। स्टैंडर्ड Base64 (RFC 4648) अपने 62वें और 63वें कैरेक्टर के रूप में + और / इस्तेमाल करता है और = से पैड करता है। इन कैरेक्टर का URLs और फ़ाइलनाम के अंदर ख़ास अर्थ होता है, इसलिए एक URL-safe वेरिएंट + की जगह - और / की जगह _ रखता है, और अक्सर आख़िर की पैडिंग पूरी तरह हटा देता है। JWT, कई API और कुछ फ़ाइलनाम स्कीम इसी URL-safe रूप का इस्तेमाल करते हैं।

यह बेमेल भ्रम का एक जाना-पहचाना स्रोत है। ब्राउज़र से कॉपी किए किसी JWT सेगमेंट में - और _ होंगे और कोई = चिह्न नहीं; इसे किसी सख़्त स्टैंडर्ड डिकोडर को दें तो वह अटक सकता है। अगर कोई डिकोड फ़ेल हो, तो यह जाँचना कि आप URL-safe वर्णमाला देख रहे हैं या नहीं, और पैडिंग हटी है या नहीं, असल डेटा को छुए बिना ज़्यादातर मामले सुलझा देता है।

Unicode, इमोजी और बाइनरी डेटा संभालना

Base64 खुद सिर्फ़ बाइट जानता है, कैरेक्टर नहीं, इसलिए टेक्स्ट को पहले बाइट में बदलना पड़ता है। यह टूल UTF-8 इस्तेमाल करता है, यानी मात्रा वाले Latin अक्षर, अरबी या चीनी जैसी गैर-Latin लिपियाँ, और इमोजी सब सही राउंड-ट्रिप करते हैं: बदलाव से पहले इन्हें इनके मल्टी-बाइट UTF-8 सीक्वेंस में एनकोड किया जाता है और वापसी में फिर से जोड़ा जाता है।

यह बाइट-पहले डिज़ाइन ही वजह है कि Base64 ऐसी चीज़ें भी दर्शा सकता है जो बिल्कुल टेक्स्ट नहीं हैं, जैसे किसी data URI में एम्बेड इमेज की कच्ची सामग्री। ऐसी स्ट्रिंग डिकोड करने पर आपको ऐसे बाइट दिखेंगे जो छपने-योग्य कैरेक्टर नहीं हैं, और यह अपेक्षित है: हर Base64 ब्लॉब टेक्स्ट की तरह पढ़ने के लिए नहीं होता, और स्क्रीन भर अनाप-शनाप का मतलब आमतौर पर यह होता है कि मूल बाइनरी था, न कि डिकोडिंग फ़ेल हुई।

संबंधित निजता-प्रथम टूल

Base64 शायद ही अकेला सफ़र करता है। डिकोड किया JWT सेगमेंट JSON होता है, इसलिए इसे JSON formatter में पेस्ट करके क्लेम को साफ़-सुथरे तरीके से बिछा दें। अगर कोई Base64 मान escaped कैरेक्टर वाला URL निकले, तो URL encoder और decoder उसे पढ़ने-योग्य बना देता है। कच्चे बिट-स्तर की जिज्ञासा के लिए, binary translator दिखाता है कि सबसे पहले कैरेक्टर बाइट में कैसे मैप होते हैं।

और जब आपको वाक़ई एक रिवर्सिबल एनकोडिंग के बजाय एकतरफ़ा फ़िंगरप्रिंट चाहिए, hash generator SHA-256 और उससे जुड़े डाइजेस्ट गिनता है। ये सब आपके ब्राउज़र में इसी तरह पूरी तरह चलते हैं, इसलिए आप संवेदनशील डेटा पर इन्हें आपस में जोड़ सकते हैं बिना उसमें से कुछ भी अपलोड हुए।

अक्सर पूछे जाने वाले सवाल

संबंधित टूल