Data URI किसी फ़ाइल की सामग्री को सीधे HTML, CSS या JS में data:[प्रकार];base64,[डेटा] के रूप में एम्बेड कर देता है, बिना अलग HTTP रिक्वेस्ट के। भारत जैसे मोबाइल-फ़र्स्ट बाज़ार में, जहाँ बड़ी संख्या में यूज़र सीमित 2G/3G डेटा प्लान या सस्ते एंट्री-लेवल स्मार्टफ़ोन पर वेब ब्राउज़ करते हैं, हर बची हुई HTTP रिक्वेस्ट का असर लोडिंग टाइम पर साफ़ दिखता है।
कम रिक्वेस्ट का फ़ायदा, पर पेज साइज़ की कीमत पर
धीमे या अस्थिर मोबाइल नेटवर्क पर हर अतिरिक्त HTTP राउंड-ट्रिप की लेटेंसी अक्सर फ़ाइल के असल आकार से ज़्यादा भारी पड़ती है, इसलिए छोटे आइकन को Data URI में एम्बेड करना फ़ायदेमंद हो सकता है। लेकिन इसकी सीमा है — बहुत सारी इमेज को इस तरह एम्बेड करने से खुद HTML फ़ाइल इतनी भारी हो जाती है कि फ़ायदा उलटा नुकसान में बदल जाता है, खासकर जब यूज़र को हर किलोबाइट के लिए डेटा चार्ज चुकाना पड़ता है।
फ़ायदे
- कम HTTP रिक्वेस्ट — धीमी कनेक्शन पर छोटे आइकन या बैकग्राउंड इमेज के लिए उपयोगी।
- फ़ाइल दस्तावेज़ से "जुड़ी" होती है और CDN या फ़ोल्डर बदलने पर टूटती नहीं।
- तुरंत दिखने वाले प्लेसहोल्डर के लिए उपयोगी, जब तक असली इमेज लोड हो रही हो।
सीमाएँ
- Base64 बाइनरी फ़ाइल की तुलना में डेटा का आकार लगभग एक-तिहाई बढ़ा देता है।
- बड़ा Data URI खुद HTML/CSS फ़ाइल को फुला देता है और पेज से अलग कैश नहीं हो सकता।
- बड़ी या बार-बार इस्तेमाल होने वाली इमेज के लिए, कैश करने योग्य अलग फ़ाइल दोबारा विज़िट पर लगभग हमेशा बेहतर रहती है।
SVG टेक्स्ट के रूप में, न कि Base64
रास्टर फ़ॉर्मेट के उलट, SVG टेक्स्ट (XML) है, इसलिए इसे Base64 में एन्कोड करना ज़रूरी नहीं: स्पेशल कैरेक्टर्स को percent-encoding से सही तरीके से एस्केप करना ही काफ़ी है (data:image/svg+xml,%3Csvg...)। यह तरीका थोड़ा हल्का रहता है — सीमित डेटा प्लान वाले यूज़र्स के लिए हर किलोबाइट मायने रखता है।