Base64 एनकोड/डीकोड
Base64 एनकोड/डीकोड
Base64 एनकोड/डीकोड: URL-safe और MIME प्रारूप विकल्पों के साथ पाठ और बाइनरी डेटा के Base64 एन्कोडिंग और डिकोडिंग का समर्थन करता है। डेटा URL पार्सिंग, लाइन-बाय-लाइन एन्कोडिंग और स्वचालित प्रारूप पहचान का समर्थन करता है, API कॉल, ईमेल अनुलग्नक और डेटा एम्बेडिंग के लिए उपयुक्त है।
क्विक स्टार्ट
सामान्य उपयोग के मामले
URL/JWT
URL‑safe वेरिएंट (-/_) को प्राथमिकता दें; कुछ स्थितियों में अंत का '=' छोड़ने से escaping समस्याएँ कम हो सकती हैं।
Email/MIME
जब wrap ज़रूरी हो, MIME 76 कॉलम (CRLF) का उपयोग करें; वेब पर आम तौर पर wrap की आवश्यकता नहीं। यह टूल 76‑कॉलम wrap और LF/CRLF स्विच प्रदान करता है।
बहु‑पंक्ति टेक्स्ट
हर पंक्ति को स्वतंत्र रूप से Base64 में एनकोड करने के लिए "प्रति पंक्ति एनकोड" चालू करें
MIME/PEM
76‑कॉलम wrapping चालू करें; जरूरत हो तो LF line break भी चालू करें
Data URL
एम्बेड करते समय data:[mime];base64,… रूप का उपयोग करें; डिकोड करते समय कॉमा के बाद वाले हिस्से को डिकोड करें (यह टूल उसे अपने‑आप निकालता है)।
राउंड‑ट्रिप सत्यापन
पहले एनकोड करें, फिर तुरंत डीकोड करके परिणाम की सुसंगतता जाँचें।
Image upload
Keep the original bytes and switch between Data URL and raw Base64 output without re-uploading
Image Data URL
Paste data:image/...;base64,... to auto-detect MIME and rebuild a previewable image
Raw Base64 image data
Supply the original image MIME explicitly before reconstructing or downloading
अतिरिक्त परिदृश्य
Base64 एन्कोड करें, Base64 डिकोड करें और Base64 कन्वर्टर को उसी प्रवाह में संभाला जा सकता है, ताकि कॉपी या एक्सपोर्ट से पहले परिणाम जल्दी जांचे जा सकें।
एन्कोडिंग पैरामीटर और वेरिएंट
उपयोग टिप्स
सीमाएं और संगतता
सेशन प्रबंधन
अक्सर पूछे जाने वाले प्रश्न
Base64 किसी भी बाइनरी डेटा को प्रिंटेबल टेक्स्ट अक्षरों के रूप में सुरक्षित रूप से प्रदर्शित करने की योजना है। यह सबसे पहले ईमेल के MIME मानक (1990 के दशक, RFC 1521/2045) में आया, बाद में RFC 4648 द्वारा मानकीकृत किया गया। इसका लक्ष्य एन्क्रिप्शन नहीं, बल्कि टेक्स्ट‑उन्मुख चैनलों पर बाइट्स को भरोसेमंद तरीके से भेजना है。 कैसे काम करता है: हर 3 बाइट (24 बिट) को चार 6‑बिट ब्लॉक में विभाजित करके 64 अक्षरों A–Z, a–z, 0–9, +, / पर मैप किया जाता है। अगर स्रोत लंबाई 3 का गुणज नहीं है, तो “=” padding का उपयोग लंबाई align करने के लिए किया जाता है; आकार आमतौर पर ~33% बढ़ता है。 वेरिएंट और चयन: RFC 4648 URL‑safe वेरिएंट परिभाषित करता है, जिसमें “+”/“/” की जगह “-”/“_” उपयोग होते हैं और अंत का “=” छोड़ा जा सकता है। URL, cookies और JWT के लिए URL‑safe की सलाह दी जाती है; पुराने MIME/toolchain के लिए मानक Base64 ( +/ और = यथावत) उपयोग करें। यह टूल डिफ़ॉल्ट रूप से URL‑safe उपयोग करता है; डिकोडर दोनों वेरिएंट स्वीकार करता है。 Data URL: एम्बेड करते समय data:[mime];base64,… रूप का उपयोग करें, और कॉमा के बाद वाले हिस्से को डिकोड करें (यह टूल उसे अपने‑आप निकालता है)। सुरक्षा याद दिलाना: Base64 उलटा‑योग्य फ़ॉर्मैटिंग है, गोपनीयता या अखंडता प्रदान नहीं करता; पहले एन्क्रिप्ट करें, फिर एनकोड।
नहीं। कोई भी Base64 डीकोड कर सकता है। यदि गोपनीयता चाहिए, तो पहले एन्क्रिप्ट करें, फिर Base64 में एनकोड करें।
केवल A–Z, a–z, 0–9, +, / और = ही अनुमत हैं, और कुल लंबाई वैध होनी चाहिए।
अंतर प्रायः इन बिंदुओं से आते हैं: लाइन wrap, क्या '=' padding रखा गया है, URL‑safe वेरिएंट (-/_) का उपयोग, और इम्प्लीमेंटेशन विवरण। सुझाव: UTF‑8 का उपयोग करें, wrap बंद रखें, और पहले से तय करें कि URL‑safe वेरिएंट व padding रखना है या नहीं।
Base64 8‑बिट डेटा को 6‑बिट प्रस्तुति में मैप करता है; लगभग 33% का ओवरहेड इसके डिज़ाइन का हिस्सा है।
UTF‑8 के साथ हाँ। गैर‑टेक्स्ट बाइनरी डेटा डीकोड के बाद गड़बड़ अक्षरों की तरह दिख सकता है।