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

Base64 कहाँ से आया, और हम अभी भी इसका उपयोग क्यों करते हैं

Base64 को 7-बिट ASCII पाइप के माध्यम से 8-बिट बाइनरी डेटा ले जाने के लिए डिज़ाइन किया गया था। पहला औपचारिक विनिर्देश RFC 989 (फरवरी 1987) गोपनीयता-संवर्धित मेल के लिए था। RFC 1341 (जून 1992) और विशेष रूप से RFC 2045 «MIME भाग एक» (नवंबर 1996) ने इसे बाइनरी फाइलों को ईमेल से अटैच करने का मानक तरीका बना दिया। वर्तमान कैनोनिकल दस्तावेज़ RFC 4648 (अक्टूबर 2006) है, जिसने URL-safe संस्करण भी परिभाषित किया। यांत्रिकी सरल है: इनपुट के 3 बाइट्स (24 बिट्स) लें, चार 6-बिट समूहों में विभाजित करें, 64-वर्ण वर्णमाला A-Z a-z 0-9 + / में प्रत्येक को देखें, आउटपुट की लंबाई 4 का गुणक बनाने के लिए = पैडिंग जोड़ें। आउटपुट का आकार इनपुट का 4 ÷ 3 ≈ 133 % है। URL में एम्बेड करने के लिए (JWT, OAuth, S3 प्री-साइन किए गए URL), RFC 4648 §5 का URL-safe संस्करण + के बजाय - और / के बजाय _ प्रतिस्थापित करता है; पैडिंग आमतौर पर छोड़ी जाती है।

data: URL: आपके HTML और CSS में Base64

data: URL योजना RFC 2397 (अगस्त 1998) में निर्दिष्ट की गई थी। प्रारूप: data:[<mediatype>][;base64],<data>। उदाहरण: <img src="data:image/png;base64,iVBORw0KGgo..."> बिना अतिरिक्त HTTP अनुरोध के एक PNG को इनलाइन एम्बेड करता है। WHATWG URL Living Standard आधुनिक ब्राउज़र इन URL की व्याख्या कैसे करते हैं को नियंत्रित करता है और HTML Living Standard पुष्टि करता है कि वे जहां भी URL की अनुमति है वहां वैध हैं, जिसमें <img>, <link>, <iframe>, और CSS url() फ़ंक्शन शामिल हैं। व्यावहारिक मार्गदर्शन: लगभग 4 KB से कम के एसेट के लिए data URL का उपयोग करें, जहां एक HTTP अनुरोध बचाना 33 प्रतिशत पेलोड फूलावट को मात देता है। 10 KB से ऊपर, ब्राउज़र कैशिंग के साथ नियमित फ़ाइल संदर्भ लगभग हमेशा जीतते हैं, विशेष रूप से HTTP/2 मल्टीप्लेक्सिंग पर।

इस उपकरण को शक्ति देने वाली ब्राउज़र API

यह पृष्ठ HTML Living Standard से FileReader API का उपयोग करता है (मूल रूप से W3C File API First Public Working Draft नवंबर 2009; Chrome 13 / Firefox 3.6 / Safari 6 / Internet Explorer 10 में शिप किया गया)। FileReader.readAsDataURL(blob) एक कॉल के साथ पूर्ण data:<mime>;base64,<...> स्ट्रिंग लौटाता है। लीगेसी विकल्प btoa() है (ऐतिहासिक Unix «binary-to-ASCII» कमांड के नाम पर और JavaScript DOM Level 0 का अवशेष), लेकिन यह गैर-Latin-1 इनपुट पर फेंकता है जब तक कि आप पहले UTF-8 के माध्यम से ट्रांसकोड न करें। आधुनिक प्रतिस्थापन Uint8Array.prototype.toBase64() है, TC39 Stage 4 में ECMAScript 2025 में जोड़ा गया। इसे Chrome 132 (जनवरी 2025), Firefox 133 (नवंबर 2024), और Safari 18.2 (दिसंबर 2024) में शिप किया गया। किसी भी नए कोड के लिए नई API का उपयोग करें; पुराने ब्राउज़रों के साथ संगतता के लिए btoa आरक्षित करें।

जहाँ इस उपकरण का आउटपुट वास्तव में जाता है

• HTML / CSS में इनलाइन आइकन और छोटी छवियाँ स्व-निहित या ऑफलाइन-प्रथम दस्तावेजों के लिए।
• JSON फ़ाइल-अपलोड पेलोड जब बैकएंड multipart/form-data के बजाय JSON फ़ील्ड में Base64 स्ट्रिंग की अपेक्षा करता है।
• MIME ईमेल अनुलग्नक: RFC 2045 किसी भी गैर-7-बिट बॉडी के लिए Base64 (या quoted-printable) की आवश्यकता होती है, जिसका अर्थ है हर PDF, छवि या डॉक अनुलग्नक।
• JWT / OAuth टोकन: हर JWT तीन URL-safe Base64 खंड हैं जो . द्वारा जुड़े हुए हैं।
• परीक्षण फिक्सचर गिट में प्रतिबद्ध, ताकि परीक्षण छवियाँ / नमूना दस्तावेज़ परीक्षण फ़ाइल के साथ यात्रा करें।
• Web Push पेलोड जब Push API के माध्यम से बाइनरी ब्लॉब वितरित कर रहे हैं।
• क्रिटिकल-पथ वेब फ़ॉन्ट CSS में एम्बेडेड पहली पेंट के FOIT (अदृश्य पाठ की चमक) से बचने के लिए, ट्रेड-ऑफ स्वीकार किया गया।

सामान्य गलतियाँ

• Base64 को एन्क्रिप्शन के रूप में मानना। Base64 एन्कोडिंग है, सुरक्षा नहीं। स्ट्रिंग वाला कोई भी इसे अपने ब्राउज़र में डिकोड कर सकता है। प्रमाणीकरण क्रेडेंशियल, API कुंजी, या PII को «छिपाने» के लिए कभी भी Base64 का उपयोग न करें।
• data:<mime>;base64, उपसर्ग भूलना। एक नंगा Base64 स्ट्रिंग data URL नहीं है। एक <img> को रेंडर करने के लिए पूर्ण रूप data:image/png;base64,<आपका-base64> की आवश्यकता होती है।
• URL-safe और मानक Base64 मिलाना। JWT और S3 प्री-साइन URL URL-safe (- और _) का उपयोग करते हैं। इन संदर्भों में मानक Base64 (+ और /) पेस्ट करना मूक डिकोड विफलताओं को उत्पन्न करता है।
• CSP data: निर्देश भूलना। इसके Content Security Policy में img-src 'self' वाले पृष्ठ किसी भी data:image/... URL को लोड करने से इनकार करेंगे। आपको स्पष्ट रूप से img-src 'self' data: की अनुमति देनी होगी (और इसी तरह font-src, media-src, आदि के लिए)।
• मुख्य थ्रेड पर 100 MB फ़ाइलें समकालिक रूप से एन्कोड करना। FileReader.readAsDataURL 200 MB फ़ाइल पर कई सेकंड के लिए UI को ब्लॉक करता है। ~20 MB से अधिक किसी भी चीज़ के लिए, Web Worker या स्ट्रीम चंक्स का उपयोग करें।
• सीधे btoa("é") कॉल करना। यह InvalidCharacterError फेंकता है क्योंकि btoa Latin-1 की अपेक्षा करता है, UTF-8 नहीं। या तो btoa(unescape(encodeURIComponent(text))) (लीगेसी) का उपयोग करें, या आधुनिक toBase64() विधि के माध्यम से Uint8Array पास करें।
• 500 KB लोगो को data URL के रूप में इनलाइन करना। 33 प्रतिशत फूलावट के अलावा ब्राउज़र कैशिंग की हानि का अर्थ है कि हर पेज लोड 500 KB-एक-बार के बजाय 665 KB डाउनलोड करता है। एक नियमित एसेट संदर्भ का उपयोग करें।

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

Base64 का सटीक आकार ओवरहेड क्या है?

बिल्कुल इनपुट का 4 ÷ 3 ≈ 1.333×, साथ ही 1-2 बाइट्स = पैडिंग। 999-बाइट इनपुट 1332 अक्षरों के Base64 बन जाता है (कोई पैडिंग नहीं क्योंकि 999 ÷ 3 = 333 सटीक)। 1000-बाइट इनपुट 1336 बन जाता है (एक बाइट पैडिंग)। data URL के लिए, उपसर्ग बाइट्स जोड़ें (उदाहरण data:image/png;base64, 23 वर्ण है)।

JWT या S3 प्री-साइन URL के लिए URL-safe Base64 कैसे प्राप्त करें?

इस उपकरण से मानक Base64 आउटपुट लें और दो प्रतिस्थापन लागू करें: + → -, / → _। JWT विशेष रूप से पिछला = पैडिंग हटाता है; S3 इसे रखता है। RFC 4648 §5 संस्करण का दस्तावेज़ीकरण करता है।

क्या मैं भ्रष्टाचार के बिना Base64 के माध्यम से एक फ़ाइल को राउंड-ट्रिप कर सकता हूँ?

हाँ। Base64 एक हानिरहित एन्कोडिंग है। Base64 में एन्कोड करना फिर वापस डिकोड करना बाइट-समान मूल उत्पन्न करता है। डेटा खोने का एकमात्र तरीका Base64 स्ट्रिंग को छोटा करना (उदाहरण के लिए अपने भंडारण को वर्ण-सीमित करना) या डिकोडिंग करते समय मानक बनाम URL-safe वर्णमाला को भ्रमित करना है।

यह उपकरण अधिकतम कितनी फ़ाइल आकार को संभाल सकता है?

कोई कठिन सीमा नहीं; व्यवहार में ब्राउज़र मेमोरी छत है। 100 MB फ़ाइल एन्कोड करने के लिए लगभग 100 MB इनपुट प्लस 133 MB आउटपुट की आवश्यकता होती है, साथ ही परिणाम स्ट्रिंग के लिए DOM ओवरहेड, शायद कुल 400 MB। मोबाइल पर, लगभग 30 MB से ऊपर विफलताओं की अपेक्षा करें। एन्कोडिंग मुख्य थ्रेड पर चलती है, इसलिए प्रसंस्करण के दौरान UI जम जाती है; 20 MB से अधिक की फ़ाइलों के लिए, सर्वर-साइड या Web Worker समाधान अधिक आरामदायक है।

क्या मेरी फ़ाइल कहीं अपलोड हुई है?

नहीं। फ़ाइल को ब्राउज़र के FileReader.readAsDataURL API के साथ पढ़ा जाता है, जो पूरी तरह से आपके ब्राउज़र में चलता है। कोई नेटवर्क अनुरोध नहीं किया जाता है और आपकी फ़ाइल की कोई प्रतिलिपि किसी भी सर्वर पर संग्रहीत नहीं होती है। DevTools में नेटवर्क टैब खोलें और एक फ़ाइल छोड़ें: आप एन्कोडिंग के दौरान शून्य आउटगोइंग अनुरोध देखेंगे।