इमेज से Base64

Base64 इमेज (डेटा URI) क्या है?

एक डेटा URI किसी अलग फ़ाइल की ओर इशारा करने के बजाय इमेज को सीधे टेक्स्ट के अंदर एम्बेड करती है। इसका रूप है data:<mime>;base64,<encoded-bytes> — उदाहरण के लिए data:image/png;base64,iVBORw0KGgo…। चूँकि यह सादा टेक्स्ट है, आप इसे सीधे HTML, CSS, JSON, SVG या Markdown में डाल सकते हैं, और ब्राउज़र इमेज को बिना दूसरे नेटवर्क अनुरोध के रेंडर कर देता है। एन्कोड करने से तस्वीर कभी नहीं बदलती — यह ठीक उसी फ़ाइल का बाइट-दर-बाइट टेक्स्ट रूप है जो आपने दी।

साइज़ और कैशिंग — यह सौदा

Base64 हर 3 बाइट्स को 4 ASCII कैरेक्टर में बदल देता है, इसलिए एन्कोडेड टेक्स्ट हमेशा बाइनरी फ़ाइल से लगभग 33% बड़ा होता है, साथ ही एक छोटा हेडर। यह कुछ बहुत छोटे एसेट के लिए ठीक है पर बड़े के लिए बर्बादी। बड़ी अड़चन कैशिंग है: एक लिंक की गई इमेज फ़ाइल एक बार डाउनलोड होकर कैश हो जाती है, फिर हर जगह दोबारा इस्तेमाल होती है, जबकि एक इनलाइन डेटा URI हर उस पेज या स्टाइलशीट का हिस्सा बनकर फिर-से डाउनलोड होती है जिसमें वह होती है, और अपने आप में कैश नहीं हो सकती। छोटा इनलाइन करें, बड़ा लिंक करें।

कब इनलाइन बनाम कब लिंक

सुझाव

• पहले कंप्रेस या रीसाइज़ करें। छोटी इमेज की Base64 एक छोटी स्ट्रिंग होती है — एन्कोड करने से पहले किसी फ़ोटो को इमेज कंप्रेसर या इमेज रीसाइज़र से गुज़ारें।
• SVG ख़ास तौर पर अच्छी तरह इनलाइन होती है — वेक्टर आइकन तीखे रहते हैं और Base64 के रूप में रास्टर से बेहतर कंप्रेस होते हैं; CSS बैकग्राउंड और कंपोनेंट लाइब्रेरी के लिए बढ़िया।
• HTML/CSS साइज़ पर नज़र रखें। कुछ इनलाइन आइकन ठीक हैं; दर्जनों बड़ी डेटा URI आपके मार्कअप को भारी और पार्स होने में धीमा बना देती हैं।
• टेक्स्ट चाहिए, इमेज नहीं? सादे टेक्स्ट और स्ट्रिंग के लिए Base64 एन्कोडर / डिकोडर इस्तेमाल करें।

Base64 असल में कैसे काम करता है

Base64 बाइनरी डेटा को केवल सुरक्षित टेक्स्ट कैरेक्टर के एक छोटे समुच्चय से लिखने का तरीक़ा है। इसका वर्णमाला ठीक 64 प्रतीक हैं — बड़े अक्षर A–Z, छोटे a–z, अंक 0–9, साथ ही + और / — और मानक RFC 4648 में परिभाषित है। एन्कोडिंग एक तय लय में काम करती है: यह डेटा को एक बार में तीन बाइट्स (24 बिट) लेता है और उन्हें 6 बिट के चार कैरेक्टर के रूप में फिर से लिखता है (चूँकि 2⁶ = 64, हर कैरेक्टर साफ़ तौर पर एक वर्णमाला प्रतीक से मैप होता है)। जब डेटा तीनों में बराबर विभाजित नहीं होता, तो एक या दो = कैरेक्टर अंत में पैडिंग करते हैं।

वही 3-बाइट-से-4-कैरेक्टर अनुपात ठीक वहीं है जहाँ से ~33% साइज़ वृद्धि आती है: हर तीन इनपुट बाइट्स के लिए चार आउटपुट कैरेक्टर यानी 4/3 विस्तार। एक आम भाई भी है, base64url, जो + और / को - और _ से बदल देता है ताकि नतीजा बिना किसी अतिरिक्त एस्केपिंग के किसी URL या फ़ाइलनाम में डालना सुरक्षित रहे — यही वेरिएंट JSON Web Tokens (JWTs) के अंदर इस्तेमाल होता है।

डेटा URI योजना

उस Base64 को एक उपयोगी पते में लपेटना डेटा URI योजना का काम है, जिसे RFC 2397 में 1998 में Larry Masinter ने परिभाषित किया। इसका व्याकरण है data:[<mediatype>][;base64],<data>। कुछ बातें जानना ज़रूरी है: अल्पविराम हमेशा ज़रूरी है, ख़ाली डेटा के लिए भी; ;base64 टोकन ही संकेत करता है कि पेलोड Base64 है, न कि percent-encoded टेक्स्ट; और यदि आप मीडिया टाइप बिल्कुल छोड़ दें, तो डिफ़ॉल्ट text/plain;charset=US-ASCII होता है। किसी इमेज के लिए आपको हमेशा एक स्पष्ट टाइप जैसे data:image/png;base64,… दिखेगा ताकि ब्राउज़र जान सके कि उसे कैसे डिकोड करना है। यही वजह है कि यह टूल MIME टाइप बताता है — यह आपकी फ़ाइल से ही सीधे पढ़ा जाता है, इसलिए URI उस ठीक फ़ॉर्मैट के लिए सही होती है।

Base64 आख़िर मौजूद ही क्यों है

Base64 वेब के लिए नहीं बना था — यह ईमेल से आता है। मूल मेल प्रोटोकॉल केवल 7-बिट ASCII टेक्स्ट ले जाने के लिए डिज़ाइन किए गए थे, जिसमें किसी इमेज या अटैचमेंट के मनमाने बाइट्स भेजने का कोई सुरक्षित तरीक़ा नहीं था। MIME मानकों ने इसे हल किया — बाइनरी को एक ऐसी टेक्स्ट वर्णमाला में फिर-से एन्कोड करके जो किसी भी केवल-टेक्स्ट चैनल में सही-सलामत बची रहे, और Base64 वही एन्कोडिंग बन गई। एक डेटा URI उसी विचार को वेब पेज पर लागू करती है: किसी तस्वीर को टेक्स्ट में बदल दें ताकि वह अलग फ़ाइल होने के बजाय HTML या CSS के अंदर रह सके।

यह इतिहास Base64 के बारे में समझने लायक सबसे ज़रूरी बात की ओर इशारा करता है: यह एक एन्कोडिंग है, न कंप्रेशन और न एन्क्रिप्शन। यह डेटा को छोटा नहीं करता — यह उसे लगभग एक-तिहाई बड़ा करता है — और यह किसी चीज़ को सुरक्षित नहीं करता, क्योंकि कोई भी इसे तुरंत डिकोड कर सकता है (यही टूल कर देगा)। यदि आप Base64 देखकर मान लें कि यह "एन्क्रिप्टेड" है, तो आप ग़लत हैं; यह बस पढ़ने योग्य टेक्स्ट के लिबास में बाइनरी है।

क्या इनलाइन करना अब भी प्रदर्शन में मदद करता है?

डेटा URI के पक्ष में क्लासिक तर्क HTTP अनुरोध हटाना था, और HTTP/1.1 के तहत — जहाँ ब्राउज़र प्रति होस्ट केवल कुछ ही कनेक्शन खोल सकते थे — एक राउंड ट्रिप बचाना असली जीत थी। HTTP/2 ने गणित बदल दिया: यह कई फ़ाइलों को एक कनेक्शन पर मल्टीप्लेक्स करता है, इसलिए अतिरिक्त अनुरोध की लागत तेज़ी से घट गई और इनलाइन करने का मामला कमज़ोर पड़ गया। एक और सूक्ष्म कर भी है: Base64 टेक्स्ट समकक्ष कच्चे बाइनरी की तुलना में gzip या Brotli से कम कुशलता से कंप्रेस होता है, इसलिए अनुरोध पर आपने जो कुछ बाइट्स "बचाए" उनमें से कुछ तार पर वापस आ जाते हैं। टिकाऊ नियम बस इतना है — छोटा इनलाइन करें, बड़ा लिंक करें — एक नन्हा नाज़ुक आइकन किसी render-blocking अनुरोध से बचने के लिए अब भी इनलाइन करने लायक हो सकता है, पर कोई भी बड़ी चीज़ एक सामान्य, अलग से कैश होने योग्य फ़ाइल ही रहनी चाहिए। (एक बढ़िया अपवाद: किसी SVG के लिए, मार्कअप को URL-encode करना आमतौर पर Base64-encode करने से छोटा होता है, क्योंकि SVG पहले से ही टेक्स्ट है और उसे Base64 आवरण से कोई लाभ नहीं होता।)

सुरक्षा और Content Security Policy पर एक नोट

चूँकि कोई डेटा URI कोई भी सामग्री ले जा सकती है, इसके सुरक्षा निहितार्थ ध्यान देने लायक हैं। किसी Content Security Policy के तहत, img-src में data: की अनुमति देना आम और काफ़ी कम-जोखिम वाला है (इनलाइन आइकन इसी तरह काम करते हैं), पर script-src में data: की अनुमति देना ख़तरनाक है — एक हमलावर किसी data: स्क्रिप्ट URL के ज़रिए कोड छुपाकर चला सकता है, इसलिए सुरक्षा गाइड वहाँ कभी इसकी अनुमति न देने की सलाह देते हैं। डेटा URI का दुरुपयोग फ़िशिंग पेज बनाने में भी हुआ है, यही वजह है कि आधुनिक ब्राउज़र अब किसी data: URL पर सीधे शीर्ष-स्तरीय नेविगेशन ब्लॉक कर देते हैं। इनमें से कुछ भी आपके अपने पेज के लिए किसी इमेज को एन्कोड करने पर असर नहीं डालता; इसका बस इतना मतलब है कि आपको किसी डेटा URI को उसकी सक्रिय सामग्री के रूप में मानना चाहिए, न कि निष्क्रिय टेक्स्ट के रूप में।

इसके पीछे के ब्राउज़र APIs

यह कन्वर्टर ब्राउज़र के अपने FileReader.readAsDataURL() पर बना है, जो आपकी फ़ाइल को लोकल रूप से पढ़ता है और पूरी data:<mime>;base64,… स्ट्रिंग लौटाता है — "कच्ची Base64" आउटपुट बस वही स्ट्रिंग है जिसका प्रीफ़िक्स हटा दिया गया हो। आपने btoa() और atob(), वे निचले-स्तर के एन्कोड और डिकोड फ़ंक्शन, भी शायद देखे होंगे। इनमें एक मशहूर पेच है: btoa() हर कैरेक्टर को एक ही बाइट मानता है, इसलिए यह U+00FF से ऊपर के किसी भी कैरेक्टर पर त्रुटि दे देता है — इसे कोई इमोजी या ग़ैर-लैटिन कैरेक्टर दें तो यह विफल हो जाता है। आधुनिक हल है पहले TextEncoder से टेक्स्ट को बाइट्स में बदलना (या नए Uint8Array Base64 हेल्पर इस्तेमाल करना)। इमेज के लिए यह कभी सामने नहीं आता, क्योंकि readAsDataURL कच्चे बाइट्स पर काम करता है — और यही ठीक वजह है कि यह यहाँ सही टूल है।

कोई डेटा URI असल में कहाँ जाती है

एक बार आपके पास एन्कोडेड स्ट्रिंग आ जाए, सवाल यह है कि उसे कहाँ पेस्ट करें। वही डेटा URI कई संदर्भों में काम करती है, यही वजह है कि यह टूल आम संदर्भों के लिए तैयार स्निपेट बना देता है:

इनमें से हर एक तस्वीर को सीधे दस्तावेज़ में एम्बेड करता है, इसलिए किसी अलग इमेज फ़ाइल के लिए दूसरा अनुरोध नहीं होता। यही पूरी अपील है — और, जैसा ऊपर बताया गया, यही पूरा सौदा भी, क्योंकि हर बार लोड होने पर बाइट्स होस्ट फ़ाइल के अंदर साथ चलते हैं।

ईमेल में डेटा URI क्यों भरोसेमंद हैं

एक संदर्भ ख़ास ज़िक्र का हक़दार है: ईमेल। कई ईमेल क्लाइंट डिफ़ॉल्ट रूप से रिमोट इमेज ब्लॉक कर देते हैं — जब तक पाठक "इमेज दिखाएँ" पर क्लिक न करे, वे किसी बाहरी सर्वर पर होस्ट तस्वीर लोड नहीं करते, कुछ हद तक ट्रैकिंग पिक्सल के ख़िलाफ़ प्राइवेसी उपाय के तौर पर। किसी डेटा URI के रूप में एम्बेडेड इमेज इसे पूरी तरह किनारे कर देती है, क्योंकि कहीं से कुछ भी फ़ेच नहीं करना पड़ता; तस्वीर पहले से ही संदेश के अंदर है। यह डेटा URI को किसी HTML ईमेल हस्ताक्षर में एक छोटा लोगो डालने का भरोसेमंद तरीक़ा बनाता है, जहाँ आप चाहते हैं कि वह हर बार, हर क्लाइंट पर, बिना किसी टूटी-इमेज प्लेसहोल्डर के दिखे। वही सावधानी अब भी लागू है — इसे छोटा रखें, क्योंकि एन्कोडेड बाइट्स ईमेल की हर कॉपी के अंदर सफ़र करते हैं।

कैशिंग लागत, विस्तार से

सबसे बड़े नुकसान के बारे में ठोस होना ज़रूरी है, क्योंकि यही वह है जिसे लोग अनदेखा करते हैं। एक सामान्य लिंक की गई इमेज एक बार डाउनलोड होती है और फिर हर बाद के पेज पर ब्राउज़र कैश से परोसी जाती है — तेज़, और अतिरिक्त बाइट्स से मुक्त। एक इनलाइन डेटा URI अपने आप में कैश नहीं हो सकती; यह HTML या CSS फ़ाइल के अंदर रहती है, इसलिए हर बार फ़ाइल बदलने पर उसी फ़ाइल के हिस्से के रूप में फिर-से डाउनलोड होती है, और पेजों के बीच साझा नहीं हो सकती। वही आइकन बीस पेजों पर इनलाइन करें और ब्राउज़र प्रभावी रूप से उसे एक कॉपी कैश करने के बजाय बीस बार डाउनलोड करता है। यही "छोटा इनलाइन करें, बड़ा लिंक करें" नियम के पीछे का निर्णायक कारक है: एक नन्हा एकल एसेट एम्बेड करना ठीक है, पर पेजों में दोबारा इस्तेमाल होने वाली कोई भी चीज़ लगभग हमेशा एक अलग, कैश होने योग्य फ़ाइल में ही होनी चाहिए।

किसी डेटा URI की संरचना, फ़ील्ड-दर-फ़ील्ड

कोई डेटा URI यादृच्छिक कैरेक्टर की दीवार जैसी दिखती है, पर इसकी एक स्पष्ट, पढ़ने योग्य संरचना है। data:image/png;base64,iVBORw0KGgo… को लें और उसके हिस्सों में तोड़ें:

पेलोड में एक मज़ेदार संकेत भी छुपा है: iVBORw0KGgo से शुरू होने वाली Base64 स्ट्रिंग लगभग हमेशा एक PNG होती है (वे कैरेक्टर PNG फ़ाइल हस्ताक्षर को एन्कोड करते हैं), जबकि /9j/ से शुरू होने वाली एक JPEG होती है। एक बार आप हिस्से पढ़ लें, तो कोई डेटा URI रहस्यमय नहीं रहती — यह बस एक मीडिया टाइप, शब्द base64, और एन्कोडेड फ़ाइल है, एक अल्पविराम से जुड़े हुए। यही ठीक वह स्ट्रिंग है जो इस टूल का "डेटा URI" बॉक्स आपको देता है, और "कच्ची Base64" बॉक्स वही चीज़ है जिसमें अल्पविराम तक और उसे शामिल करके सब कुछ हटा दिया गया हो।

किसी डेटा URI को वापस फ़ाइल में बदलना

चूँकि Base64 एक प्रतिवर्ती एन्कोडिंग है, यह प्रक्रिया दोनों तरफ़ चलती है — और यही ऊपर का "Base64 → इमेज" टैब करता है। कोई पूरी data: URI, या फ़ॉर्मैट चुनकर केवल कच्ची Base64 पेस्ट करें, और टूल टेक्स्ट को वापस मूल बाइट्स में डिकोड करता है, तस्वीर का पूर्वावलोकन दिखाता है, और उसे एक असली फ़ाइल के रूप में डाउनलोड करने देता है। डिकोड बस हर क़दम को उलट देता है: यह फ़ाइल फ़ॉर्मैट जानने के लिए मीडिया टाइप पढ़ता है, data:…;base64, प्रीफ़िक्स हटाता है, और हर चार Base64 कैरेक्टर को वापस तीन बाइट्स में बदल देता है। यदि स्ट्रिंग वैध इमेज डेटा नहीं है — आमतौर पर एक अधूरी copy-paste की वजह से — तो आपको टूटी इमेज के बजाय एक साफ़ त्रुटि मिलेगी, क्योंकि बाइट्स किसी ऐसी तस्वीर में डिकोड नहीं होंगे जिसे ब्राउज़र रेंडर कर सके। यह एन्कोडिंग का ठीक उलटा है, और किसी स्टाइलशीट या HTML फ़ाइल में किसी के द्वारा डेटा URI के रूप में एम्बेड की गई इमेज को वापस पाने का एक आसान तरीक़ा।

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

क्या मेरी इमेज किसी सर्वर पर अपलोड होती है?

नहीं। इमेज को अंतर्निर्मित FileReader API से पूरी तरह आपके ब्राउज़र में पढ़ा और लोकल रूप से Base64 में बदला जाता है — यह कभी आपके डिवाइस से बाहर नहीं जाती और न कभी लॉग या ट्रांसमिट होती है। पेज लोड हो जाने के बाद यह ऑफ़लाइन भी काम करती है, यही वजह है कि निजी स्क्रीनशॉट, आईडी फ़ोटो या आंतरिक एसेट के लिए यह सुरक्षित है।

डेटा URI क्या है और नतीजा मैं कहाँ पेस्ट करूँ?

एक डेटा URI ऐसी दिखती है data:image/png;base64,iVBORw0KGgo… — MIME टाइप, शब्द base64, फिर एन्कोडेड बाइट्स। आप पूरी स्ट्रिंग को सीधे किसी HTML <img src="…">, किसी CSS background-image: url("…"), या किसी Markdown इमेज में डाल सकते हैं। यह टूल आपके लिए वे तीनों स्निपेट बना देता है ताकि आप जो चाहिए बस वही कॉपी कर लें।

Base64 मूल फ़ाइल से बड़ी क्यों होती है?

Base64 हर 3 बाइट्स को 4 ASCII कैरेक्टर के रूप में एन्कोड करता है, इसलिए टेक्स्ट हमेशा बाइनरी इमेज से लगभग 33% बड़ा होता है — साथ ही छोटा data:…;base64, हेडर। किसी इमेज को सीधे टेक्स्ट में एम्बेड करने का यही सौदा है। यह छोटे एसेट के लिए ठीक है पर बड़ी फ़ोटो के लिए बर्बादी है, जिन्हें सामान्य फ़ाइल के रूप में लिंक करना बेहतर है।

मैं कौन-से इमेज फ़ॉर्मैट एन्कोड कर सकता हूँ?

कोई भी फ़ॉर्मैट जिसे आपका ब्राउज़र फ़ाइल के रूप में पढ़ सके — PNG, JPEG, GIF, WebP, SVG, BMP और ICO सभी काम करते हैं। MIME टाइप फ़ाइल से ही लिया जाता है, इसलिए बनी डेटा URI उस फ़ॉर्मैट के लिए सही होती है। एन्कोड करने से इमेज बदलती या दोबारा कंप्रेस नहीं होती; यह मूल फ़ाइल का बाइट-दर-बाइट टेक्स्ट रूप है।

क्या मैं किसी Base64 स्ट्रिंग को वापस इमेज में डिकोड कर सकता हूँ?

हाँ — “Base64 → इमेज” टैब पर जाएँ और या तो पूरी डेटा URI या केवल कच्ची (raw) Base64 पेस्ट करें (फिर उसका फ़ॉर्मैट चुनें)। टूल इमेज का पूर्वावलोकन दिखाता है और उसे असली फ़ाइल के रूप में डाउनलोड करने देता है। यदि स्ट्रिंग वैध इमेज डेटा नहीं है तो आपको टूटी इमेज के बजाय एक साफ़ त्रुटि मिलेगी।

क्या किसी इमेज को Base64 के रूप में इनलाइन करने से पेज स्पीड बेहतर होती है?

कुछ बहुत छोटे एसेट के लिए, हाँ — यह अतिरिक्त HTTP अनुरोध हटा देता है। पर इनलाइन इमेज अलग से कैश नहीं हो सकतीं और HTML/CSS को भारी बना देती हैं, इसलिए छोटे आइकन से आगे किसी भी चीज़ के लिए यह आमतौर पर नुकसानदेह है। एक अच्छा नियम है — कुछ किलोबाइट से कम के एसेट इनलाइन करें और उससे बड़ा सब कुछ लिंक करें।

संबंधित टूल

• Base64 एन्कोडर / डिकोडर (टेक्स्ट)
• इमेज कंप्रेसर
• इमेज रीसाइज़र
• इमेज से PDF

सभी ब्राउज़र टूल देखें →