मुफ़्त Base64 एनकोडर और डिकोडर ऑनलाइन

Base64 क्या है?

Base64 एक बाइनरी-से-टेक्स्ट एन्कोडिंग योजना है-बाइटों के किसी भी अनुक्रम (बाइनरी डेटा) को सामान्य ASCII अक्षरों के अनुक्रम के रूप में प्रस्तुत करने का एक तरीका, जो केवल-टेक्स्ट चैनलों से बिना बिगाड़ के गुज़र सकता है। नाम वर्णमाला के आकार को दर्शाता है: 64 अक्षर विशेष रूप से इसलिए चुने गए क्योंकि वे 7-बिट साफ़ ट्रांसमिशन से बिना बदलाव के पार होते हैं। मानक वर्णमाला है A-Z (स्थान 0-25), a-z (26-51), 0-9 (52-61), फिर + (62) और / (63)। जब इनपुट की लंबाई तीन का सटीक गुणक नहीं होती, तब = अक्षर पैडिंग के लिए आरक्षित रहता है। हर तीन इनपुट बाइट (24 बिट) चार आउटपुट अक्षर बनते हैं (हर एक 6 बिट उठाता है), इसीलिए Base64-कोडेड डेटा मूल से लगभग 33 % बड़ा होता है।

तंत्र: तीन बाइट (24 बिट) लें, चार 6-बिट टुकड़ों में पुनः-समूहित करें, हर टुकड़े को 64-अक्षर वर्णमाला में देखें। उत्कृष्ट उदाहरण: तीन ASCII बाइट M a n (0x4D 0x61 0x6E) 24-बिट पैटर्न 01001101 01100001 01101110 बनाते हैं; 6-बिट टुकड़ों में पुनः-समूहित: 010011 010110 000101 101110 = दशमलव 19, 22, 5, 46 = अक्षर T W F u। तो "Man" Base64 में "TWFu" के रूप में एन्कोड होता है। यदि इनपुट की लंबाई तीन से विभाज्य नहीं है, तो एन्कोडर एक या दो = से पैड करता है: 1 बाइट इनपुट 2 अक्षर + == देता है, 2 बाइट इनपुट 3 अक्षर + = देते हैं।

Base64 का संक्षिप्त इतिहास

Base64 IETF के Privacy Enhanced Mail (PEM) प्रयास से उत्पन्न हुआ। फ़रवरी 1987 का RFC 989 पहली औपचारिक परिभाषा थी; अगस्त 1989 का RFC 1113 ने इसे संशोधित किया; फ़रवरी 1993 का RFC 1421 ने Base64 एन्कोडिंग सहित PEM विनिर्देश को अंतिम रूप दिया। Base64 ईमेल मुख्यधारा में तब आया जब MIME (Multipurpose Internet Mail Extensions) विनिर्देश ने इसे अपनाया: नवंबर 1996 का RFC 2045 ने Base64 को बाइनरी ईमेल अनुलग्नकों के लिए मानक एन्कोडिंग के रूप में परिभाषित किया-इसीलिए हर PDF या छवि जो आपने कभी ईमेल से जोड़ी है, नेटवर्क के पार Base64 के रूप में गई। मौजूदा प्रामाणिक विनिर्देश RFC 4648 («The Base16, Base32, and Base64 Data Encodings»), अक्टूबर 2006 में Simon Josefsson द्वारा प्रकाशित है, जिसने RFC 3548 (जुलाई 2003) का स्थान लिया और विभिन्न Base16 / Base32 / Base64 परिवार एन्कोडिंगों को एक दस्तावेज़ में एकीकृत किया। RFC 4648 वही स्पेक है जिसे हर आधुनिक Base64 कार्यान्वयन निशाना बनाता है।

URL-सुरक्षित Base64-दो अक्षर क्यों बदले जाते हैं

मानक Base64 वर्णमाला + और / का उपयोग करती है-दोनों URLs में आरक्षित अक्षर हैं। URL क्वेरी स्ट्रिंग में + आमतौर पर «स्पेस» का अर्थ रखता है (form-encoded परंपरा); / पथ विभाजक है। मानक Base64 को URL में डालने का मतलब है दोनों को percent-encode करना, जो स्ट्रिंग को और फुलाता है और कुरूप बनाता है। RFC 4648 §5 एक URL-सुरक्षित संस्करण परिभाषित करता है: + को - (हाइफ़न-माइनस) से और / को _ (अंडरस्कोर) से बदलें। कभी-कभी इसे Base64URL या base64url कहा जाता है। परिणाम एक ऐसी स्ट्रिंग है जो आगे एस्केप के बिना सीधे URLs में बैठ जाती है-ठीक वही जो JWT (JSON Web Tokens), OAuth state पैरामीटर, WebAuthn क्रेडेंशियल IDs और अधिकांश आधुनिक वेब APIs उपयोग करते हैं। कुछ कार्यान्वयन अंतिम = पैडिंग भी हटा देते हैं क्योंकि लंबाई अगले फ़ील्ड से अंतर्निहित है। JWT की डॉट-अलग तीन-भाग संरचना (हेडर.पेलोड.हस्ताक्षर) तीन Base64URL-कोडेड खंडों से बनती है; यदि आपने कभी JWT को हाथ से डिकोड किया है, आपने - और _ अक्षर देखे हैं जो इसे मानक Base64 के बजाय Base64URL के रूप में चिह्नित करते हैं।

Base-N परिवार-Base16, Base32, Base58, Base85

Base64 अकेली बाइनरी-से-टेक्स्ट एन्कोडिंग नहीं है। Base16 (हेक्स) 16 अक्षर (0-9 और A-F) का उपयोग करती है-100 % आकार विस्तार (हर बाइट 2 हेक्स अक्षरों में बदल जाता है), पर तुच्छ रूप से पठनीय और हैश आउटपुट, फ़ाइल चेकसम और मशीन पहचानकर्ताओं के लिए सार्वभौमिक डिफ़ॉल्ट। Base32 (RFC 4648, Crockford का प्रकार भी) 32 अक्षर उपयोग करती है-दृष्टिगत रूप से अस्पष्ट जोड़े जैसे 0/O और 1/I/L को बाहर रखने का ध्यान; 60 % विस्तार; TOTP गुप्त कुंजियों, ULIDs और Tor onion पतों में उपयोग। Base58 Bitcoin-प्रामाणिक है: 58 अक्षर जो आसानी से भ्रमित होने वाले 0/O/I/l को बाहर करते हैं, साथ ही मानक Base64 के विशेष अक्षर +/=। Bitcoin पते, Solana पते और कई क्रिप्टो वॉलेट पहचानकर्ता Base58Check (Base58 साथ 4-बाइट चेकसम) उपयोग करते हैं। Base85 / Ascii85 अधिक घनत्व पैक करती है (4 बाइट को 5 अक्षरों के रूप में एन्कोडिंग, केवल 25 % विस्तार) पर ऐसा वर्णमाला उपयोग करती है जिसमें URL-असुरक्षित विराम चिह्न शामिल है; Adobe के PostScript और PDF फ़ॉर्मेट एम्बेडेड बाइनरी डेटा के लिए आंतरिक रूप से Base85 उपयोग करते हैं। सामान्य व्यापार: वर्णमाला में अधिक अक्षर मतलब कम विस्तार पर अधिक प्रतिबंधित अक्षर सेट; कम अक्षर मतलब अधिक बड़ी आउटपुट की कीमत पर सुरक्षित परिवहन।

Base64 के सामान्य उपयोग

• ईमेल अनुलग्नक (MIME)।RFC 2045 1996 से। हर PDF, छवि या दस्तावेज़ जो आपने ईमेल से जोड़ा, नेटवर्क पर Base64 के रूप में गया, क्योंकि SMTP मूल रूप से 7-बिट साफ़ टेक्स्ट प्रोटोकॉल था जो कच्चे बाइनरी को नहीं संभाल सकता था।
• HTML/CSS में data: URIs।data:image/png;base64,iVBORw0KGgo... एक छोटी छवि को सीधे HTML या CSS स्टाइलशीट में एम्बेड करता है, एक HTTP अनुरोध हटाते हुए। ~10 KB से कम के आइकनों के लिए उपयोगी; बड़ी छवियों के लिए प्रति-उत्पादक क्योंकि 33 % Base64 विस्तार HTTP-अनुरोध ओवरहेड बचत से अधिक होता है।
• JSON पेलोड में बाइनरी।JSON spec के अनुसार केवल-टेक्स्ट है-JSON मान में कच्चे बाइट डालने का कोई तरीका नहीं। जिन APIs को छवियाँ, PDFs या अन्य बाइनरी प्रसारित करनी होती है, वे उन्हें JSON फ़ील्ड में Base64 स्ट्रिंग के रूप में एम्बेड करते हैं। Stripe के webhook पेलोड, Twilio के MMS APIs और कई AI-दृष्टि एंडपॉइंट इस पैटर्न का उपयोग करते हैं।
• JWT (JSON Web Tokens)।JWT के तीन डॉट-अलग भाग (हेडर.पेलोड.हस्ताक्षर) सभी Base64URL-कोडेड हैं। JWT spec (RFC 7519, मई 2015) JOSE पर बनती है (RFC 7515-7518, मई 2015 भी), जो सभी पूरे Base64URL को अनिवार्य करते हैं।
• OAuth और OpenID Connect।कई कार्यान्वयनों में state पैरामीटर, PKCE code verifier, ID tokens और access tokens Base64URL का उपयोग करते हैं।
• HTTP Basic Authentication।हेडर Authorization: Basic dXNlcjpwYXNz Base64(उपयोगकर्ता-नाम:पासवर्ड) ले जाता है। ध्यान: यह परिवहन के लिए एन्कोडिंग है, एन्क्रिप्शन नहीं-प्लेन HTTP पर Basic Auth नेटवर्क देख रहे किसी भी व्यक्ति को क्रेडेंशियल्स प्लेनटेक्स्ट में दिखा देता है। हमेशा HTTPS के साथ युग्मित करें।
• Subresource Integrity (SRI)।<script> और <link> टैगों पर integrity="sha384-..." विशेषता अपेक्षित फ़ाइल सामग्री के Base64-कोडेड हैश को ले जाती है; निष्पादन से पहले ब्राउज़र सत्यापित करते हैं कि डाउनलोडेड फ़ाइल मेल खाती है।
• CSS में SVG पृष्ठभूमि।background-image: url("data:image/svg+xml;base64,...") SVG को सीधे स्टाइलशीट में एम्बेड करता है। Base64 रूप कभी-कभी URL-encoded रूप पर तरजीह दी जाती है (जो SVG को पठनीय रखता है पर भिन्न एस्केप नियम उपयोग करता है)।

एन्कोडिंग एन्क्रिप्शन नहीं है-एक सामान्य सुरक्षा भूल

Base64 शून्य सुरक्षा देता है। एन्कोडिंग मिलीसेकंडों में कोई भी पूरी तरह उलट सकता है-वर्णमाला सार्वजनिक है, एल्गोरिथम तुच्छ है, और कोई भी ब्राउज़र या एक-पंक्ति का CLI कमांड इसे डिकोड कर सकता है। फिर भी, «Base64-कोडेड संवेदनशील डेटा» MITRE के CWE-261 (Weak Encoding for Password) में सबसे अधिक उद्धृत उदाहरणों में से एक है और सुरक्षा ऑडिटों में लगातार दिखाई देता है: क्लाइंट कोड में Base64 से «अस्पष्ट किए» API कुंजी; डेटाबेस बैकअप फ़ाइलों में Base64 से «एन्कोडेड» पासवर्ड; सार्वजनिक Git रिपॉज़िटरी में कमिट होने से पहले Base64 से «एन्क्रिप्ट किए» गए रहस्य। इनमें से कोई भी सुरक्षित नहीं है। यदि आपको वास्तविक गोपनीयता चाहिए, असली एन्क्रिप्शन उपयोग करें: सममित के लिए AES-256-GCM, असममित के लिए RSA-OAEP या ECDH+ChaCha20-Poly1305। Base64 परिवहन के लिए उपयुक्त है (बाइनरी को टेक्स्ट-अनुकूल रूप में बदलना) पर सुरक्षा के लिए कभी नहीं।

ब्राउज़र कार्यान्वयन: btoa / atob और Unicode नुकसान

JavaScript Base64 के लिए दो अंतर्निहित वैश्विक फ़ंक्शन उजागर करता है: btoa() (binary-to-ASCII, एन्कोड) और atob() (ASCII-to-binary, डिकोड)। दोनों Netscape प्रारंभिक युग के लिगेसी APIs हैं और एक प्रसिद्ध सीमा रखते हैं: वे केवल Latin-1 बाइट स्ट्रिंग पर काम करते हैं। btoa('é') बुलाना InvalidCharacterError फेंकता है क्योंकि JavaScript स्ट्रिंग 'é' में U+00FF से ऊपर एक code point है जो एकल बाइट में फ़िट नहीं होता। आधुनिक सुधार है पहले TextEncoder के माध्यम से UTF-8 बाइटों में एन्कोड करना, फिर परिणामी Uint8Array को btoa() उपभोग के लिए Latin-1 स्ट्रिंग में बदलना। पैटर्न: btoa(String.fromCharCode(...new TextEncoder().encode(str)))। उल्टा डिकोडिंग: new TextDecoder().decode(Uint8Array.from(atob(str), c => c.charCodeAt(0)))। नए ब्राउज़र Uint8Array.toBase64() और Uint8Array.fromBase64() को अंतर्निहित विधियों के रूप में उजागर करते हैं, पर 2026 में अपनाव अभी भी जारी है-btoa/atob के माध्यम से पॉलीफ़िल क्रॉस-ब्राउज़र डिफ़ॉल्ट बना हुआ है। विशेष रूप से फ़ाइलों के लिए FileReader.readAsDataURL() सबसे सरल मार्ग है: एक input में एक फ़ाइल छोड़ें, reader एक data:mime/type;base64,... स्ट्रिंग लौटाता है जिसमें सब कुछ सही एन्कोडेड है; केवल Base64 भाग पाने के लिए data: उपसर्ग हटाएँ।

ईमानदार दायरा: यह उपकरण क्या करता है और क्या नहीं

यह उपकरण टेक्स्ट या फ़ाइलों (5 MB तक) को Base64 में एन्कोड करता है और Base64 स्ट्रिंग्स को टेक्स्ट या डाउनलोडेबल फ़ाइलों में डिकोड करता है। डिफ़ॉल्ट रूप से मानक RFC 4648 वर्णमाला (+ और / के साथ) उपयोग करता है; URL-सुरक्षित Base64URL (- और _ के साथ) एक भविष्य का टॉगल है। UTF-8 टेक्स्ट TextEncoder के माध्यम से सही ढंग से संभाला जाता है-btoa-Latin-1 जाल ठीक किया गया। 5 MB फ़ाइल आकार सीमा इसलिए है क्योंकि Base64 डेटा को 33 % विस्तारित करता है और एन्कोडेड स्ट्रिंग पूरी तरह ब्राउज़र मेमोरी में रहती है; एक 5 MB बाइनरी फ़ाइल लगभग 6.7 MB Base64 टेक्स्ट प्लस मूल बफ़र पैदा करती है, जो हर आधुनिक डिवाइस पर काम करता है। बड़ी फ़ाइलों के लिए मानक विकल्प हैं macOS/Linux पर कमांड-लाइन base64 (base64 -i input.bin -o output.txt), Python का base64 मॉड्यूल, या Node.js Buffer.from(data).toString('base64')। यह उपकरण नहीं संभालता: स्ट्रीमिंग Base64 (मेमोरी से बड़ी फ़ाइलों के लिए फ़ाइल-दर-खंड एन्कोडिंग); इस संस्करण में URL-सुरक्षित संस्करण (योजनाबद्ध); और न ही MIME quoted-printable एन्कोडिंग (टेक्स्ट ईमेल सामग्री के लिए एक अलग RFC 2045 योजना)।

गोपनीयता: केवल-ब्राउज़र क्यों मायने रखता है

Base64 एन्क्रिप्शन नहीं है, पर एन्कोडेड किया जाने वाला डेटा अक्सर संवेदनशील होता है: API कुंजी जिन्हें आप कॉन्फ़िग फ़ाइल में एम्बेड कर रहे हैं, प्रमाणपत्र जिन्हें आप परिवहन के लिए एन्कोडिंग कर रहे हैं, आंतरिक स्क्रीनशॉट जिन्हें आप दस्तावेज़ीकरण में data URIs के रूप में एम्बेड कर रहे हैं, या PDF रसीदें जिन्हें आप ग्राहक के लिए एन्कोडिंग कर रहे हैं। सर्वर-साइड एन्कोडर आपका इनपुट देखते हैं। यह उपकरण JavaScript के माध्यम से पूरी तरह आपके ब्राउज़र में चलता है-Encode क्लिक करते समय DevTools के Network टैब में सत्यापित करें, या लोड होने के बाद पृष्ठ को ऑफ़लाइन (एयरप्लेन मोड) करें और उपकरण फिर भी काम करता है। API क्रेडेंशियल्स, PII स्क्रीनशॉट, आंतरिक दस्तावेज़ या किसी भी ऐसे डेटा को एन्कोड करने के लिए सुरक्षित जिसे आप किसी अजनबी की हार्ड ड्राइव पर कॉपी नहीं देखना चाहते।

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

क्या Base64 सुरक्षित है?

नहीं। Base64 एनकोडिंग है, एन्क्रिप्शन नहीं। कोई भी Base64 स्ट्रिंग को डिकोड कर सकता है। संवेदनशील डेटा की सुरक्षा के लिए कभी भी Base64 का उपयोग न करें, सुरक्षा के लिए उचित एन्क्रिप्शन (AES, RSA) का उपयोग करें।

Base64 फ़ाइलों को बड़ा क्यों बना देता है?

Base64 एनकोडिंग डेटा के आकार को लगभग 33% बढ़ा देती है। बाइनरी डेटा के तीन बाइट्स चार Base64 वर्णों में बदल जाते हैं। यह अतिरिक्त आकार बाइनरी डेटा को टेक्स्ट के रूप में प्रसारित करने की कीमत है।

क्या मैं फ़ाइलों को एनकोड कर सकता हूँ?

हाँ! एनकोडर पर किसी भी फ़ाइल को खींचें और छोड़ें, या ब्राउज़ करने के लिए क्लिक करें। फ़ाइल को Base64 Data URI में बदला जाएगा जिसे आप सीधे HTML, CSS या JavaScript में पेस्ट कर सकते हैं।

Base64 और Base64URL में क्या अंतर है?

दो अक्षर। मानक Base64 (RFC 4648 §4) वर्णमाला के 62वें और 63वें अक्षर के रूप में + और / उपयोग करता है। URL-सुरक्षित Base64URL (RFC 4648 §5) उनके स्थान पर - और _ उपयोग करता है, ताकि एन्कोडेड स्ट्रिंग बिना percent-encoding के सीधे URLs में बैठ जाए। JWT, OAuth, WebAuthn और अधिकांश आधुनिक वेब APIs Base64URL उपयोग करते हैं। यह उपकरण फ़िलहाल मानक Base64 निकालता है; URL-सुरक्षित भविष्य की सुविधा सूची पर है। मानक से URL-सुरक्षित में हाथ से बदलने के लिए: + को - से, / को _ से बदलें, वैकल्पिक रूप से अंतिम = पैडिंग हटाएँ।

मेरा Unicode टेक्स्ट कुछ Base64 उपकरणों में क्यों विफल होता है?

क्योंकि JavaScript का लिगेसी btoa() फ़ंक्शन केवल Latin-1 बाइट स्ट्रिंग पर काम करता है-btoa('é') बुलाना InvalidCharacterError फेंकता है। कई पुराने ब्राउज़र-आधारित एन्कोडर बिना UTF-8 रूपांतरण कदम के सीधे btoa उपयोग करते हैं, इसलिए कोई भी गैर-ASCII इनपुट टूट जाता है। आधुनिक कोड (और यह उपकरण) पहले TextEncoder के माध्यम से स्ट्रिंग्स एन्कोड करता है, UTF-8 बाइट अनुक्रम पैदा करता है जिसे btoa फिर सुरक्षित रूप से एन्कोड कर सकता है। नई अंतर्निहित विधि Uint8Array.toBase64() UTF-8 को मूल रूप से संभालती है पर अभी तक सभी ब्राउज़रों में baseline नहीं है।

क्या मेरा डेटा अपलोड किया जाता है?

नहीं। एन्कोडिंग और डिकोडिंग JavaScript के माध्यम से पूरी तरह आपके ब्राउज़र में चलती है। टेक्स्ट और फ़ाइलें कभी नेटवर्क पार नहीं करतीं-Encode क्लिक करते समय DevTools के Network टैब में सत्यापित करें, या लोड होने के बाद पृष्ठ को ऑफ़लाइन (एयरप्लेन मोड) करें और उपकरण फिर भी काम करता है। API क्रेडेंशियल्स, PII धारक स्क्रीनशॉट, आंतरिक कॉन्फ़िग फ़ाइलें या किसी भी ऐसे डेटा के लिए सुरक्षित जिसे आप किसी अजनबी की हार्ड ड्राइव पर कॉपी नहीं देखना चाहते।

संबंधित टूल