Base64 एनकोड/डीकोड
Base64 एन्कोड/डीकोड टेक्स्ट और इमेज, दोनों वर्कफ़्लो को सपोर्ट करता है। आप टेक्स्ट को एन्कोड/डीकोड कर सकते हैं, इमेज को Data URL या raw Base64 में बदल सकते हैं, या Data URL / Base64 को फिर से इमेज में बदलकर लोकल प्रीव्यू और डाउनलोड कर सकते हैं।
इनपुट टेक्स्ट
अक्षर
0 / 500,000
इमेज चुनें या ड्रॉप करें
ब्राउज़र पढ़ सके तो PNG, JPEG, WebP, GIF, SVG, BMP, AVIF, TIFF, ICO, HEIC और HEIF समर्थित हैं।
आउटपुट टेक्स्ट
आउटपुट टेक्स्ट
इनपुट टेक्स्ट
अक्षर
0 / 500,000
रॉ Base64 के लिए MIME प्रकार
Raw Base64 में MIME जानकारी नहीं होती। ऑटोमैटिक प्रीव्यू बनाने के लिए पहले मूल इमेज प्रकार चुनें।
इमेज Data URL पेस्ट करें, या raw Base64 पेस्ट करके MIME प्रकार चुनें, तब यहाँ प्रीव्यू दिखेगा।
क्विक स्टार्ट
सामान्य उपयोग के मामले
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,… रूप का उपयोग करें; डिकोड करते समय कॉमा के बाद वाले हिस्से को डिकोड करें (यह टूल उसे अपने‑आप निकालता है)।
राउंड‑ट्रिप सत्यापन
पहले एनकोड करें, फिर तुरंत डीकोड करके परिणाम की सुसंगतता जाँचें।
इमेज अपलोड
मूल बाइट्स बदले बिना Data URL और raw Base64 आउटपुट के बीच स्विच करें।
इमेज Data URL
data:image/...;base64,... पेस्ट करें, MIME प्रकार अपने-आप पहचान लिया जाएगा और इमेज तुरंत प्रीव्यू होगी।
Raw Base64 इमेज डेटा
मूल इमेज MIME प्रकार दें, ताकि टूल उसे अपने-आप प्रीव्यू कर सके और इमेज के रूप में डाउनलोड कर सके।
एन्कोडिंग पैरामीटर और वेरिएंट
उपयोग टिप्स
सीमाएं और संगतता
गोपनीयता और सुरक्षा
अक्सर पूछे जाने वाले प्रश्न
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, +, / और = ही अनुमत हैं, और कुल लंबाई वैध होनी चाहिए।
अंतर आमतौर पर line wrapping, '=' padding रखने या हटाने, URL-safe variants (-/_), या अलग text encoding की वजह से होता है। तुलना करते समय सुनिश्चित करें कि दोनों तरफ़ एक ही text encoding हो, automatic wrapping बंद हो, और URL-safe तथा padding के उपयोग पर सहमति हो।
Base64 8‑बिट डेटा को 6‑बिट प्रस्तुति में मैप करता है; लगभग 33% का ओवरहेड इसके डिज़ाइन का हिस्सा है।
हाँ। टेक्स्ट मोड में emoji और बहुभाषी टेक्स्ट UTF-8 के रूप में प्रोसेस होते हैं। अगर decoded result वास्तव में non-text binary data है, तो उसका अपठनीय दिखना सामान्य है।