Base64 एन्क्रिप्शन नहीं है
Base64 किसी भी बाइट को सिर्फ़ अक्षरों, अंकों और दो-चार चिह्नों से लिख देता है। यह इसलिए बना कि बाइनरी डेटा उन रास्तों से गुज़र सके जो सिर्फ़ टेक्स्ट के लिए बने हैं — ईमेल का मुख्य भाग, JSON के फ़ील्ड, HTML के एट्रिब्यूट।
इसमें न कोई चाबी है न कोई राज़, इसलिए इसे वापस खोलने में कुछ नहीं लगता। पासवर्ड को Base64 में बदलकर कॉन्फ़िग फ़ाइल में रखना छिपाना नहीं, बस एक कदम और जोड़ना है। सचमुच छिपाना हो तो एन्क्रिप्ट करें या किसी सीक्रेट मैनेजर को सौंपें।
URL-safe कब चुनें
मानक Base64 में + और / आते हैं। ये दोनों पते के भीतर कुछ और मतलब रखते हैं, इसलिए ऐसा मान सीधे क्वेरी स्ट्रिंग में डालने पर बिगड़ जाता है। आखिर में लगी = पैडिंग के साथ भी यही होता है।
URL-safe इन तीनों को सुधारा हुआ रूप है: + की जगह -, / की जगह _, और पैडिंग हटी हुई। JWT के तीनों हिस्से इसी रूप में होते हैं, और OAuth के ऑथराइज़ेशन कोड या फ़ाइल नाम में जाने वाले मान भी अक्सर यही होते हैं। मान पते में जा रहा हो तो URL-safe, बाकी जगह मानक रूप।
लंबाई बढ़ जाती है
Base64 तीन बाइट को चार अक्षरों में बदलता है, इसलिए नतीजा मूल से लगभग 33% लंबा होता है। इससे पहले UTF-8 भी लगता है — देवनागरी का एक अक्षर तीन बाइट लेता है, तो दस अक्षर का वाक्य 30 बाइट बनता है और Base64 में 40 अक्षर।
यह बढ़ोतरी तब मायने रखती है जब आप इमेज को data: URL के रूप में HTML में डालते हैं। छोटे आइकन के लिए एक रिक्वेस्ट बचाना फ़ायदे का सौदा है, पर पूरी फ़ोटो डालने पर पेज उतना ही भारी हो जाता है और पहली बार दिखने में देर लगती है।
डिकोड न होने पर
“यह Base64 नहीं है” आमतौर पर तब आता है जब स्ट्रिंग बीच से कटी हो, या आगे-पीछे उद्धरण चिह्न और लाइन ब्रेक साथ आ गए हों। यह टूल खाली जगह और लाइन ब्रेक खुद हटा देता है और URL-safe अक्षर भी लेता है, इसलिए फिर भी न चले तो स्ट्रिंग ही अधूरी है।
“यह टेक्स्ट नहीं, बाइनरी में खुलता है” का मतलब है कि डिकोडिंग हो गई, पर नतीजा पढ़ने लायक अक्षर नहीं है। अगर मान किसी इमेज या ज़िप फ़ाइल का Base64 है, तो यही सही जवाब है, गलती नहीं।