यह पेज हिन्दी में दिखाया जा रहा है, क्योंकि आपका ब्राउज़र यही भाषा माँगता है।
इस पेज का कोड चालू नहीं हुआ।
index.html को सीधे किसी फ़ोल्डर से खोलने पर ब्राउज़र JavaScript मॉड्यूल रोक देता है, इसलिए कोई तस्वीर चुनने पर कुछ नहीं होगा। इसके बजाय फ़ोल्डर को http पर सर्व कीजिए:
ऊपर फ़ाइल चुनते ही यह खुल जाएगा।तैयार — इंटरनेट काट दीजिए, यह फिर भी चलता रहेगा।इस ब्राउज़र में उपलब्ध नहीं (बाकी सब फिर भी चलता है)।ऑफ़लाइन कैश के लिए https:// या localhost चाहिए।यहाँ कैश नहीं हो सकता, पर अपलोड फिर भी कुछ नहीं होता।आपकी फ़ाइलें कहीं नहीं गईं। {total} फ़ाइलें लोड हुईं, और वे सब इसी साइट की अपनी हैं। {platform}किसी चीज़ ने {hosts} से संपर्क किया, और यह टूल ऐसा कभी नहीं करता। यह देखने लायक बात है। {platform}विज्ञापन, माप और दान वाले बटन के लिए साइट की अपनी स्क्रिप्ट {hosts} होस्ट से आईं। उनमें से किसी को न कोई फ़ाइल मिली, न उसका एक बाइट।विज्ञापन, माप और दान वाले बटन के लिए साइट की अपनी स्क्रिप्ट {hosts} होस्ट से आईं। उनमें से किसी को न कोई फ़ाइल मिली, न उसका एक बाइट।कुछ गड़बड़ हो गई: {detail}। दोबारा शुरू करने के लिए पेज फिर से लोड कीजिए।{count} फ़ाइल पढ़ी जा रही है…{count} फ़ाइलें पढ़ी जा रही हैं…कोई उदाहरण आज़माइएउदाहरण बनाया जा रहा है…यह ब्राउज़र उदाहरण नहीं बना सका। इसके बजाय कोई फ़ाइल चुनिए।
तस्वीर से data URI — CSS या HTML के लिए तस्वीर को base64 कीजिए
पूरी तस्वीर, टेक्स्ट की एक पंक्ति में। सीधे CSS या HTML में चिपका दीजिए।
● यह टूल तस्वीरें कभी अपलोड नहीं करता। यहाँ कोई सर्वर है ही नहीं।
एनकोडिंग आपके अपने ब्राउज़र में, आपके अपने हार्डवेयर पर होती है। यह उन्हीं बाइटों पर की गई गणित भर है जो पेज के पास पहले से हैं। न कोई एनकोडर, न कोई सर्वर, और छोड़ने को नेटवर्क वाला कोई कदम ही नहीं। इस टूल में किसी भी तरह की कोई नेटवर्क सुविधा है ही नहीं, इसलिए यहाँ से कुछ मँगाया भी नहीं जा सकता और भेजा भी नहीं जा सकता। और मान लीजिए कोई रास्ता होता भी, तो इस पेज के दूसरी तरफ़ ऐसा कोई सर्वर ही नहीं है जिसे तस्वीर भेजी जा सके।
✗ कोई अपलोड नहीं
✗ कोई खाता नहीं
✗ दोबारा एनकोड नहीं
✓ ऑफ़लाइन चलता है
✓ ओपन सोर्स
लाइव जाँच:जाँच जारी…
ऑफ़लाइन:जाँच जारी…
हमारी बात पर भरोसा मत कीजिए। DevTools खोलिए, Network टैब पर नज़र रखिए, और कोई तस्वीर भीतर छोड़िए। एक भी रिक्वेस्ट में न कोई तस्वीर जाती है, न थंबनेल, न फ़ाइल का नाम, न आपकी चुनी फ़ाइल का एक बाइट। या फिर इंटरनेट काट दीजिए और तब भी कोई तस्वीर एनकोड करके देखिए।
प्राइवेसी का यह दावा कैसे जाँचा जा सकता है
आपकी तस्वीरों के जाने के लिए कोई जगह ही नहीं है। यह पेज जिन-जिन पतों से संपर्क कर सकता है, Content-Security-Policy उन सबके नाम गिना देती है, और उनमें से एक भी इस साइट का नहीं है। यहाँ ऐसा कोई एंडपॉइंट है ही नहीं जहाँ आपकी फ़ाइलें जमा हो सकें, और होता भी तो कोड में ऐसा कुछ नहीं है जो उन्हें भेजता।
यहाँ कुछ भी कहीं से कुछ नहीं मँगाता।src/ में कहीं भी न fetch है, न XMLHttpRequest, न sendBeacon। एनकोडिंग का काम btoa और encodeURIComponent करते हैं, यानी दो ऐसे फ़ंक्शन जो ब्राउज़र के पास शुरू से हैं। दोनों बाइट लेते हैं और टेक्स्ट लौटा देते हैं, कहीं गए बिना।
प्रीव्यू ही सबूत है। हर नतीजे के बगल में दिखती तस्वीर उसी data URI से खींची जाती है जो इस पेज ने अभी बनाया, आपकी फ़ाइल से नहीं। वह इसीलिए बनती है कि URI सही है, आपकी मशीन पर, बिना किसी सर्वर के। और वह न बने, तो पेज आपको कुछ टूटा हुआ थमाने के बजाय साफ़ कह देता है।
मेटाडेटा की चेतावनी आपके पक्ष में है। data URI फ़ाइल की हूबहू नकल करता है, इसलिए किसी फ़ोटोग्राफ़ का GPS निशान उसी के साथ आपकी स्टाइलशीट में चला जाता है। यह पेज पढ़ लेता है कि उसमें कितना कुछ है और आपको बता देता है, क्योंकि दूसरा रास्ता यह है कि आपको कमिट हो जाने के बाद पता चले।
Google क्या लोड करता है, और उसे क्या नहीं दिया जाता। विज्ञापन और माप वाली स्क्रिप्ट Google से आती हैं, और दान का बटन Buy Me a Coffee से। इनमें से किसी को भी आपकी तस्वीरों के बारे में कुछ नहीं सौंपा जाता। फ़ाइल पढ़ने या एनकोड करने वाली हर पंक्ति इसी ऑरिजिन से आती है और रिपॉज़िटरी में मौजूद है।
यह ऑफ़लाइन भी चलता है। नेटवर्क काट दीजिए, टूल जस का तस काम करता रहेगा, क्योंकि इसमें नेटवर्क वाला कोई कदम कभी था ही नहीं। सबसे आसान सबूत यही है।
खुद जाँच लीजिए। ऊपर लिखी किसी भी बात को भरोसे पर मानने की ज़रूरत नहीं। यह पेज रिपॉज़िटरी के टेम्पलेट और कॉन्फ़िग से बनता है, एक ऐसी बिल्ड स्क्रिप्ट के ज़रिए जिसे आप पढ़ भी सकते हैं और खुद चला भी सकते हैं। उसका नतीजा dist ब्रांच पर कमिट रहता है, यानी जो सर्व हो रहा है और सोर्स से बिल्ड करने पर जो बनता है, दोनों का फ़र्क आप खुद देख सकते हैं:
सबसे पहले पढ़ने लायक फ़ाइलें ये हैं — Content-Security-Policy के लिए config/site.toml, दोनों एनकोडिंग और उनके पीछे की वजहों के लिए src/encode.js, मीडिया टाइप फ़ाइल के नाम से नहीं बल्कि फ़ाइल में से कैसे पढ़ा जाता है यह देखने के लिए src/sniff.js, और आप जो चिपकाने जा रहे हैं उसका कितना हिस्सा तस्वीर है ही नहीं, यह बताने वाली जाँच के लिए src/metadata.js।
अगर आपके दफ़्तर का सुरक्षा सॉफ़्टवेयर अपलोड की चेतावनी दे। वह उस पल पर नज़र रखता है जब ब्राउज़र में फ़ाइल चुनी जाती है, और यह नहीं जान सकता कि पन्ना उसे भेजने वाला है या नहीं — इसलिए चुनने पर ही चेतावनी देता है। यहाँ से कुछ नहीं भेजा जाता: ब्राउज़र के डेवलपर टूल खोलिए, Network पर जाइए, और एक फ़ाइल चुनिए। उसे ले जाने वाला कोई अनुरोध नहीं है, और पन्ने की अपनी स्थानीय झलक के अलावा कोई अनुरोध ही नहीं। यही जाँच आपकी IT टीम आधे मिनट में कर सकती है।
1 तस्वीरें चुनिए
2 बताइए कि यह जा कहाँ रहा है
अकेला data URI शायद ही कभी किसी को चाहिए होता है। चाहिए होती है वह पंक्ति जो स्टाइलशीट में जाती है। इसलिए पंक्ति चुन लीजिए, और तस्वीर उसी के भीतर, पहले से उद्धरण चिह्नों में लिपटी हुई आ जाती है। यही वह हिस्सा है जो आसानी से बिगड़ता है, और जो सिर्फ़ SVG के लिए नाकाम होता है।
alt टेक्स्ट जान-बूझकर खाली छोड़ा गया है। सिर्फ़ आप जानते हैं कि तस्वीर कोई अर्थ ढो रही है या बस सजावट है, और फ़ाइल के नाम से अंदाज़ा लगाकर लिखा गया विवरण स्क्रीन रीडर इस्तेमाल करने वाले के लिए किसी विवरण के न होने से भी बुरा है।
SVG को भी base64 कीजिए डिफ़ॉल्ट रूप से बंद, क्योंकि SVG टेक्स्ट है और base64 बाइटों के लिए है। percent-encoding मार्कअप को स्टाइलशीट में पढ़ने लायक छोड़ देती है और आम तौर पर पाँचवाँ हिस्सा छोटी रहती है। जो इक्का-दुक्का टूलचेन ;base64 पर ही अड़े, उसके लिए इसे चालू कीजिए।
3 इसे कॉपी कीजिए
अभी कुछ चुना नहीं गया। ऊपर कोई तस्वीर छोड़िए और चिपकाने लायक पंक्ति यहाँ आ जाएगी।
{name}: यह ऐसा इमेज फ़ॉर्मैट नहीं जिसे यह टूल पहचानता हो। डेटा URI में टाइप सही होना ही चाहिए, इसलिए यह अंदाज़ा नहीं लगाएगा।नाम {extension} कहता है, पर बाइट {label} हैं। URI {mime} कहता है, और वही चलेगा।{name} को सूची से हटाइए{n} तस्वीर{n} तस्वीरें{n} तस्वीर, कुल {size} टेक्स्ट। इसमें से कुछ भी कहीं नहीं गया।{n} तस्वीरें, कुल {size} टेक्स्ट। इसमें से कुछ भी कहीं नहीं गया।{size} अंदर{n} अक्षर बाहरफ़ाइल जितना ही बड़ाफ़ाइल से {percent}% बड़ाफ़ाइल से {percent}% छोटाइतना छोटा कि यह साफ़ फ़ायदे का सौदा है: एक अनुरोध कम, और जिस फ़ाइल में यह बैठेगा उसमें कुछ खास जुड़ता भी नहीं।अंदर रखे आइकन के लिए सामान्य आकार। हर पन्ने पर दिखने वाली चीज़ के लिए सार्थक है।अंदर रखी तस्वीर के लिए बड़ा। जो कुछ भी यह स्टाइलशीट शामिल करता है वह अब इसे भी ढोता है, और यह अलग से कैश नहीं हो सकती।अंदर रखने के लिए बहुत बड़ा। सामान्य फ़ाइल की तरह परोसा जाता तो एक बार कैश होकर समांतर आता; अंदर रखे जाने पर यह हर पन्ने के नाज़ुक रास्ते पर है और आसपास कुछ भी बदलते ही दोबारा डाउनलोड होता है।EXIFXMPIPTCएक रंग प्रोफ़ाइलएक टाइमस्टैंपएक टिप्पणीटेक्स्टइसमें {size} का {kinds} है। वह तस्वीर के साथ ही URI में उतर जाता है।इसमें {size} का {kinds} है, जो फ़ाइल का {percent}% है। वह तस्वीर के साथ ही URI में उतर जाता है।इस ब्राउज़र ने नतीजा बनाने से मना कर दिया। URI ठीक बना है; फ़ॉर्मैट ही ऐसा है जिसे वह डीकोड नहीं कर सकता।Safari के सिवा कोई ब्राउज़र इस फ़ॉर्मैट को नहीं बनाता, इसलिए URI वैध तो होगा पर तस्वीर दिखेगी नहीं। पहले इसे बदल लीजिए।{a} · {b}{a}, {b}{a} और {b}{n} बाइट{n} KB{n} MBआपकी तस्वीरें कहीं नहीं गईं। {total} फ़ाइलें लोड हुईं, और वे सब इसी साइट की अपनी हैं। {platform}किसी चीज़ ने {hosts} से संपर्क किया, और यह टूल ऐसा कभी नहीं करता। यह देखने लायक बात है। {platform}विज्ञापन, माप और दान वाले बटन के लिए साइट की अपनी स्क्रिप्ट {hosts} होस्ट से आईं। उनमें से किसी को न कोई तस्वीर मिली, न उसका एक बाइट।विज्ञापन, माप और दान वाले बटन के लिए साइट की अपनी स्क्रिप्ट {hosts} होस्ट से आईं। उनमें से किसी को न कोई तस्वीर मिली, न उसका एक बाइट।
क्या इससे काम बन गया?
क्या गड़बड़ हुई?
शुक्रिया — इससे मदद मिलती है।
सिर्फ़ आपका जवाब भेजा जाता है, वह भी तभी जब आप बटन दबाते हैं। आपकी फ़ाइल, उसका नाम या उससे जुड़ी कोई बात कभी नहीं।
# तस्वीर से data URI — CSS या HTML के लिए तस्वीर को base64 कीजिए
पूरी तस्वीर, टेक्स्ट की एक पंक्ति में। सीधे CSS या HTML में चिपका दीजिए।
> PNG, JPEG, SVG या WebP को ऐसे data URI में बदलिए जिसे आप CSS या HTML में चिपका सकें। SVG को base64 के बजाय percent-encode किया जाता है, इसलिए वे पढ़ने लायक और छोटी रहती हैं। सब आपके ब्राउज़र में चलता है और कुछ अपलोड नहीं होता।
यह पेज एक इंटरैक्टिव टूल है जो पूरी तरह आपके ब्राउज़र में चलता है, https://abox.tools/hi/image-to-data-uri/ पर — आप इसे जो भी देते हैं, वह कहीं अपलोड नहीं होता। आगे वह सब कुछ है जो यह पेज इस टूल के बारे में शब्दों में कहता है; इसे इस्तेमाल करने के लिए यह पता खोलें।
## यह टूल तस्वीरें **कभी अपलोड नहीं करता**। यहाँ कोई सर्वर है ही नहीं।
एनकोडिंग आपके अपने ब्राउज़र में, आपके अपने हार्डवेयर पर होती है। यह उन्हीं बाइटों पर की गई गणित भर है जो पेज के पास पहले से हैं। न कोई एनकोडर, न कोई सर्वर, और छोड़ने को नेटवर्क वाला कोई कदम ही नहीं। इस टूल में किसी भी तरह की कोई नेटवर्क सुविधा है ही नहीं, इसलिए यहाँ से कुछ मँगाया भी नहीं जा सकता और भेजा भी नहीं जा सकता। और मान लीजिए कोई रास्ता होता भी, तो इस पेज के दूसरी तरफ़ ऐसा कोई सर्वर ही नहीं है जिसे तस्वीर भेजी जा सके।
- ✗ कोई अपलोड नहीं
- ✗ कोई खाता नहीं
- ✗ दोबारा एनकोड नहीं
- ✓ ऑफ़लाइन चलता है
- ✓ ओपन सोर्स
## तस्वीर को data URI में कैसे बदलें
1. **अपनी तस्वीरें चुनिए।** उन्हें पिकर पर छोड़ दीजिए, या हाथ से चुन लीजिए। ब्राउज़र उन्हें सीधे आपकी डिस्क से पढ़ता है, और इस दौरान कुछ भी कहीं नहीं भेजा जाता।
2. **बताइए कि नतीजा जा कहाँ रहा है।** अकेला URI, कोई CSS नियम, कोई कस्टम प्रॉपर्टी, कोई `<img>` टैग, या Markdown। इनमें से हर एक URI को उद्धरण चिह्नों में रखता है, और यही वह ब्योरा है जो तय करता है कि भीतर रखी SVG चलेगी या चुपचाप नहीं चलेगी।
3. **पढ़िए कि कीमत क्या पड़ी।** हर नतीजा बताता है कि वह कितने अक्षरों का बना, वह फ़ाइल से कितना बड़ा है, और इस साइज़ की चीज़ भीतर रखना अच्छा विचार है या नहीं। base64 एक-तिहाई जोड़ देता है। वह एक-तिहाई किसी बची हुई रिक्वेस्ट के बदले सही सौदा है या नहीं, यह पूरी तरह साइज़ पर निर्भर है, इसलिए पेज बता देता है कि आप लकीर के किस तरफ़ खड़े हैं।
4. **चेतावनियाँ देख लीजिए।** तस्वीर EXIF, कोई कलर प्रोफ़ाइल या XMP ढो रही हो, तो उसका नाम इस बात के साथ लिखा जाता है कि आपके नतीजे के कितने बाइट वही हैं। एक्सटेंशन असली फ़ॉर्मैट से न मिले, तो पेज असली फ़ॉर्मैट इस्तेमाल करता है और आपको बता देता है। और आपका ब्राउज़र नतीजा खींच ही न सके, तो वह भी कह देता है।
5. **कॉपी कीजिए, या डाउनलोड।** हर नतीजे के लिए एक बटन, और सबके लिए एक साथ भी। कस्टम प्रॉपर्टी एक `:root` ब्लॉक में लिपटी हुई निकलती हैं, स्टाइलशीट के सिरे पर चिपकाने को तैयार।
## विस्तार से
[तस्वीर को अपनी CSS के भीतर कब रखें, और कब नहीं](https://abox.tools/hi/guides/embed-an-image-in-css/): data URI की कीमत क्या है, base64 एक-तिहाई क्यों जोड़ देता है और gzip उसे वापस क्यों नहीं करता, SVG को base64 क्यों नहीं करना चाहिए, और वह कोटेशन की गलती जो भीतर रखी SVG को चुपचाप तोड़ देती है।
## बॉक्स में और भी टूल
- [SVG से तस्वीर](https://abox.tools/hi/svg-to-image/): साइज़ बताइए। वेक्टर के पास खोने को अपना कोई साइज़ है ही नहीं।
- [तस्वीर से SVG](https://abox.tools/hi/image-to-svg/): एक आकार, एक आउटलाइन। जो नहीं होना चाहिए, उस पर बस उँगली रख दीजिए।
- [ऊँचाई तुलना चार्ट](https://abox.tools/hi/compare-heights/): ऊँचाइयाँ टाइप कीजिए, तस्वीर ले जाइए। इसे बनाने के लिए कुछ भी बाहर नहीं भेजा जाता।
- [इमेज कंप्रेसर](https://abox.tools/hi/compress-image/): साइज़ आप बताइए। बाकी हिसाब यह लगा लेगा।
## सवाल
### क्या मेरी तस्वीर कहीं अपलोड होती है?
नहीं। फ़ाइल को पढ़ने और एनकोड करने का काम आपका अपना ब्राउज़र आपके अपने हार्डवेयर पर करता है, उन्हीं दो फ़ंक्शनों से जो उसके पास पहले से हैं। इस टूल में किसी भी तरह की कोई नेटवर्क सुविधा है ही नहीं, यानी यह न कभी कुछ मँगाता है, न कभी कुछ भेजता है। और पेज की `Content-Security-Policy` उन सारे पतों के नाम गिना देती है जिनसे यह संपर्क कर सकता है, जिनमें से एक भी इस साइट का नहीं है।
### data URI होता क्या है?
पूरी फ़ाइल को वहाँ लिखने का एक तरीका, जहाँ आम तौर पर कोई वेब पता जाता है। `url("logo.png")` लिखने के बजाय, जो ब्राउज़र से कहता है कि जाकर कुछ ले आओ, आप `url("data:image/png;base64,iVBORw0...")` लिखते हैं, जिसमें खुद तस्वीर होती है। ब्राउज़र उसे वहीं के वहीं डिकोड कर लेता है। व्यावहारिक असर एक कम रिक्वेस्ट का होता है, क्योंकि तस्वीर स्टाइलशीट या पेज के बाद नहीं, उसी के साथ पहुँच जाती है।
### मेरी SVG base64 में क्यों नहीं है?
क्योंकि उसके लिए base64 गलत एनकोडिंग है। SVG टेक्स्ट है, और URL टेक्स्ट पहले से ढो सकता है, यानी गिनती के कुछ ही अक्षरों को बचाना पड़ता है। उन्हें percent-encode करके बाकी को छोड़ देने से ऐसा URI बनता है जो उसी फ़ाइल के base64 से आम तौर पर पाँचवाँ हिस्सा छोटा होता है, और जिसे आप अपनी स्टाइलशीट में पढ़ भी सकते हैं। तत्वों के नाम, रंग और `viewBox`, सब वहीं मौजूद रहते हैं, बदलने के लिए तैयार। जो इक्का-दुक्का टूलचेन base64 पर ही अड़े, उसके लिए एक चेकबॉक्स भी है।
### base64 मेरी तस्वीर को कितना बड़ा कर देता है?
करीब एक-तिहाई। फ़ाइल के तीन बाइट base64 के चार अक्षर बन जाते हैं, यानी 33%, और वह भी आगे लगने वाले `data:image/png;base64,` से पहले। इससे नीचे उतरा ही नहीं जा सकता, क्योंकि सिर्फ़ URL में चलने वाले अक्षरों से मनमाने बाइट लिखने की कीमत यही है। इसीलिए पेज फ़ाइल के साइज़ के बगल में अक्षरों की गिनती भी दिखा देता है, बजाय इसके कि आपको स्टाइलशीट तैनात होने पर पता चले।
### तस्वीर को भीतर रखना असल में कब अच्छा विचार है?
जब वह छोटी हो और तुरंत चाहिए हो। हर पेज पर लोड होने वाली स्टाइलशीट में 2 KB का आइकन साफ़ फ़ायदे का सौदा है, क्योंकि एक चक्कर बच जाता है और तस्वीर उसी पल मौजूद रहती है जिस पल CSS। करीब 10 KB के आगे सौदा पलट जाता है। भीतर रखी तस्वीर अब अलग फ़ाइल रही ही नहीं, इसलिए उसे अलग से कैश नहीं किया जा सकता, किसी और चीज़ के साथ समानांतर लाया नहीं जा सकता, और उसके आसपास की फ़ाइल जब भी बदलती है वह पूरी की पूरी दोबारा डाउनलोड होती है। स्टाइलशीट में रखा 200 KB का फ़ोटोग्राफ़ साइट के हर पेज के क्रिटिकल पाथ में जुड़े 200 KB है। पेज बता देता है कि हर नतीजा उस लकीर के किस तरफ़ गिरता है।
### क्या gzip base64 का बोझ वापस उतार देता है?
उतना नहीं जितना लोग सोचते हैं। पहले से कंप्रेस हो चुकी फ़ाइल का base64 ठीक से कंप्रेस होता ही नहीं, और PNG, JPEG तथा WebP तीनों पहले से कंप्रेस हो चुकी होती हैं। कंप्रेसर को ढूँढ़ने लायक दोहराव लगभग बचा ही नहीं होता, इसलिए base64 ने जो एक-तिहाई जोड़ा था उसमें से आम तौर पर दसवाँ हिस्सा भर वापस मिलता है, पूरा नहीं। percent-encode की गई SVG उलटा मामला है। वह अब भी टेक्स्ट है, इसलिए लगभग उतनी ही अच्छी तरह कंप्रेस होती है जितनी पहले होती थी, और उसे base64 न करने की एक और वजह यही है।
### क्या इससे मेरी तस्वीर में कोई बदलाव आता है?
नहीं, और यहाँ के ज़्यादातर टूलों से यह एक जान-बूझकर रखा फ़र्क है। कुछ भी पिक्सलों में डिकोड करके दोबारा एनकोड नहीं होता। जो बाइट आपकी डिस्क से निकले, वही बाइट URI में जाते हैं। JPEG ठीक वही JPEG रहती है जो थी, उसी क्वालिटी पर, उन्हीं मापों के साथ। इसीलिए नतीजे को उसी फ़ाइल की नकल नहीं, खुद वही फ़ाइल कहा जा सकता है।
### तो मेरा EXIF और GPS डेटा भी स्टाइलशीट में चला जाता है?
हाँ, और चिपकाने से पहले यही हिस्सा सोचने लायक है। चूँकि कुछ भी दोबारा एनकोड नहीं होता, कैमरे ने जो कुछ लिखा वह सब तस्वीर के साथ सफ़र करता है, यानी जगह, समय और कैमरे का सीरियल नंबर। फ़ोन की फ़ोटो में यह फ़ाइल का 30 KB तक हो सकता है, जो आपके पेज के क्रिटिकल पाथ पर 40 KB base64 बन जाता है, और जो रिपॉज़िटरी में कमिट होने वाली किसी चीज़ के भीतर पड़ा घर का पता होता है। पेज पढ़ लेता है कि JPEG, PNG या WebP में कितना मेटाडेटा है, और बता देता है। उसे पहले निकालने के लिए [EXIF व्यूअर और रिमूवर](https://abox.tools/hi/exif-editor/) इस्तेमाल कीजिए।
### इसने मेरी फ़ाइल के एक्सटेंशन से अलग टाइप क्यों इस्तेमाल किया?
क्योंकि एक्सटेंशन गलत हो सकता है और बाइट नहीं। जिस फ़ाइल का नाम `logo.png` है पर जो असल में JPEG के रूप में एक्सपोर्ट हुई थी, वह इतनी आम है कि हर इमेज टूल को उससे निपटना ही पड़ता है। और जो data URI गलत टाइप घोषित करे वह बस बनता ही नहीं, न कोई पीछे हटने का रास्ता, न पढ़ने लायक कोई त्रुटि। इसलिए टाइप फ़ाइल के पहले कुछ बाइटों से पढ़ा जाता है, जो यहाँ के हर फ़ॉर्मैट में बिना किसी संदेह के बता देते हैं कि वह है क्या, और दोनों न मिलें तो पेज आपको बता देता है।
### प्रीव्यू खाली है। कहाँ गड़बड़ हुई?
शायद URI में कहीं नहीं। HEIC और TIFF दोनों बिलकुल सही data URI बनाती हैं जिन्हें Safari के सिवा कोई ब्राउज़र खींचेगा नहीं, इसलिए आप उसे जहाँ भी चिपकाएँ तस्वीर वहाँ भी गायब ही रहेगी। उसे पहले [इमेज कंप्रेसर](https://abox.tools/hi/compress-image/) या [इमेज रिसाइज़र](https://abox.tools/hi/resize-image/) से PNG, JPEG या WebP में बदल लीजिए। फ़ॉर्मैट आम वाला हो, तो खुद फ़ाइल के खराब होने की संभावना ज़्यादा है। प्रीव्यू उसी URI से खींचा जाता है जो इस पेज ने बनाया, इसलिए खाली प्रीव्यू का मतलब है कि तस्वीर डिकोड ही नहीं हुई।
### क्या data URI के साइज़ की कोई सीमा है?
ऐसी कोई नहीं जो आपको CSS में या `<img>` टैग में मिले, क्योंकि आज के ब्राउज़र वहाँ कोई व्यावहारिक छत नहीं लगाते। ब्राउज़र जिस चीज़ पर सीमा लगाते हैं वह है data URI को पते वाली पट्टी में टाइप करना, और ज़्यादातर अब किसी भी गंभीर चीज़ के लिए उससे मना कर देते हैं, ऐसी सुरक्षा वजहों से जिनका इस इस्तेमाल से कोई लेना-देना नहीं। असली सीमा वही ऊपर वाली है। कुछ भी तकनीकी तौर पर टूटने से बहुत पहले, जिस पेज में वह है वह आम इमेज फ़ाइल के मुकाबले धीमा पड़ चुका होता है।
### क्या यह मुफ़्त है, और क्या इसके लिए खाता बनाना पड़ेगा?
यह मुफ़्त है, और यहाँ न कोई खाता है, न साइन-इन, न ट्रायल, न वॉटरमार्क। फ़ाइलों की गिनती या साइज़ पर भी कोई सीमा नहीं है, क्योंकि इनका बिल चुकाने वाला कोई सर्वर है ही नहीं। काम आपके अपने डिवाइस पर होता है। साइट पर विज्ञापन हैं और खर्च वही उठाते हैं, लेकिन विज्ञापनों को आपकी तस्वीरों के बारे में कुछ नहीं दिया जाता।
### क्या यह ऑफ़लाइन चलता है?
हाँ। पेज एक बार लोड कर लीजिए, फिर इंटरनेट काट दीजिए, यह चलता रहेगा। कुछ अपलोड नहीं हो रहा, यह साबित करने का सबसे आसान तरीका भी यही है। जो टूल आपकी तस्वीरें एनकोड होने के लिए कहीं भेजता, वह प्लग निकालते ही रुक जाता।
## प्राइवेसी का यह दावा कैसे जाँचा जा सकता है
- **आपकी तस्वीरों के जाने के लिए कोई जगह ही नहीं है।** यह पेज जिन-जिन पतों से संपर्क कर सकता है, Content-Security-Policy उन सबके नाम गिना देती है, और उनमें से एक भी इस साइट का नहीं है। यहाँ ऐसा कोई एंडपॉइंट है ही नहीं जहाँ आपकी फ़ाइलें जमा हो सकें, और होता भी तो कोड में ऐसा कुछ नहीं है जो उन्हें भेजता।
- **यहाँ कुछ भी कहीं से कुछ नहीं मँगाता।** `src/` में कहीं भी न `fetch` है, न `XMLHttpRequest`, न `sendBeacon`। एनकोडिंग का काम `btoa` और `encodeURIComponent` करते हैं, यानी दो ऐसे फ़ंक्शन जो ब्राउज़र के पास शुरू से हैं। दोनों बाइट लेते हैं और टेक्स्ट लौटा देते हैं, कहीं गए बिना।
- **प्रीव्यू ही सबूत है।** हर नतीजे के बगल में दिखती तस्वीर उसी data URI से खींची जाती है जो इस पेज ने अभी बनाया, आपकी फ़ाइल से नहीं। वह इसीलिए बनती है कि URI सही है, आपकी मशीन पर, बिना किसी सर्वर के। और वह न बने, तो पेज आपको कुछ टूटा हुआ थमाने के बजाय साफ़ कह देता है।
- **मेटाडेटा की चेतावनी आपके पक्ष में है।** data URI फ़ाइल की हूबहू नकल करता है, इसलिए किसी फ़ोटोग्राफ़ का GPS निशान उसी के साथ आपकी स्टाइलशीट में चला जाता है। यह पेज पढ़ लेता है कि उसमें कितना कुछ है और आपको बता देता है, क्योंकि दूसरा रास्ता यह है कि आपको कमिट हो जाने के बाद पता चले।
- **Google क्या लोड करता है, और उसे क्या नहीं दिया जाता।** विज्ञापन और माप वाली स्क्रिप्ट Google से आती हैं, और दान का बटन Buy Me a Coffee से। इनमें से किसी को भी आपकी तस्वीरों के बारे में कुछ नहीं सौंपा जाता। फ़ाइल पढ़ने या एनकोड करने वाली हर पंक्ति इसी ऑरिजिन से आती है और रिपॉज़िटरी में मौजूद है।
- **यह ऑफ़लाइन भी चलता है।** नेटवर्क काट दीजिए, टूल जस का तस काम करता रहेगा, क्योंकि इसमें नेटवर्क वाला कोई कदम कभी था ही नहीं। सबसे आसान सबूत यही है।
**खुद जाँच लीजिए।** ऊपर लिखी किसी भी बात को भरोसे पर मानने की ज़रूरत नहीं। यह पेज रिपॉज़िटरी के टेम्पलेट और कॉन्फ़िग से बनता है, एक ऐसी बिल्ड स्क्रिप्ट के ज़रिए जिसे आप पढ़ भी सकते हैं और खुद चला भी सकते हैं। उसका नतीजा `dist` ब्रांच पर कमिट रहता है, यानी जो सर्व हो रहा है और सोर्स से बिल्ड करने पर जो बनता है, दोनों का फ़र्क आप खुद देख सकते हैं: https://github.com/A-Box-of-Tools/website
सबसे पहले पढ़ने लायक फ़ाइलें ये हैं — Content-Security-Policy के लिए `config/site.toml`, दोनों एनकोडिंग और उनके पीछे की वजहों के लिए `src/encode.js`, मीडिया टाइप फ़ाइल के नाम से नहीं बल्कि फ़ाइल में से कैसे पढ़ा जाता है यह देखने के लिए `src/sniff.js`, और आप जो चिपकाने जा रहे हैं उसका कितना हिस्सा तस्वीर है ही नहीं, यह बताने वाली जाँच के लिए `src/metadata.js`।
तस्वीर को data URI में कैसे बदलें
अपनी तस्वीरें चुनिए। उन्हें पिकर पर छोड़ दीजिए, या हाथ से चुन लीजिए। ब्राउज़र उन्हें सीधे आपकी डिस्क से पढ़ता है, और इस दौरान कुछ भी कहीं नहीं भेजा जाता।
बताइए कि नतीजा जा कहाँ रहा है। अकेला URI, कोई CSS नियम, कोई कस्टम प्रॉपर्टी, कोई <img> टैग, या Markdown। इनमें से हर एक URI को उद्धरण चिह्नों में रखता है, और यही वह ब्योरा है जो तय करता है कि भीतर रखी SVG चलेगी या चुपचाप नहीं चलेगी।
पढ़िए कि कीमत क्या पड़ी। हर नतीजा बताता है कि वह कितने अक्षरों का बना, वह फ़ाइल से कितना बड़ा है, और इस साइज़ की चीज़ भीतर रखना अच्छा विचार है या नहीं। base64 एक-तिहाई जोड़ देता है। वह एक-तिहाई किसी बची हुई रिक्वेस्ट के बदले सही सौदा है या नहीं, यह पूरी तरह साइज़ पर निर्भर है, इसलिए पेज बता देता है कि आप लकीर के किस तरफ़ खड़े हैं।
चेतावनियाँ देख लीजिए। तस्वीर EXIF, कोई कलर प्रोफ़ाइल या XMP ढो रही हो, तो उसका नाम इस बात के साथ लिखा जाता है कि आपके नतीजे के कितने बाइट वही हैं। एक्सटेंशन असली फ़ॉर्मैट से न मिले, तो पेज असली फ़ॉर्मैट इस्तेमाल करता है और आपको बता देता है। और आपका ब्राउज़र नतीजा खींच ही न सके, तो वह भी कह देता है।
कॉपी कीजिए, या डाउनलोड। हर नतीजे के लिए एक बटन, और सबके लिए एक साथ भी। कस्टम प्रॉपर्टी एक :root ब्लॉक में लिपटी हुई निकलती हैं, स्टाइलशीट के सिरे पर चिपकाने को तैयार।
विस्तार से
तस्वीर को अपनी CSS के भीतर कब रखें, और कब नहींdata URI की कीमत क्या है, base64 एक-तिहाई क्यों जोड़ देता है और gzip उसे वापस क्यों नहीं करता, SVG को base64 क्यों नहीं करना चाहिए, और वह कोटेशन की गलती जो भीतर रखी SVG को चुपचाप तोड़ देती है।
नहीं। फ़ाइल को पढ़ने और एनकोड करने का काम आपका अपना ब्राउज़र आपके अपने हार्डवेयर पर करता है, उन्हीं दो फ़ंक्शनों से जो उसके पास पहले से हैं। इस टूल में किसी भी तरह की कोई नेटवर्क सुविधा है ही नहीं, यानी यह न कभी कुछ मँगाता है, न कभी कुछ भेजता है। और पेज की Content-Security-Policy उन सारे पतों के नाम गिना देती है जिनसे यह संपर्क कर सकता है, जिनमें से एक भी इस साइट का नहीं है।
data URI होता क्या है?
पूरी फ़ाइल को वहाँ लिखने का एक तरीका, जहाँ आम तौर पर कोई वेब पता जाता है। url("logo.png") लिखने के बजाय, जो ब्राउज़र से कहता है कि जाकर कुछ ले आओ, आप url("data:image/png;base64,iVBORw0...") लिखते हैं, जिसमें खुद तस्वीर होती है। ब्राउज़र उसे वहीं के वहीं डिकोड कर लेता है। व्यावहारिक असर एक कम रिक्वेस्ट का होता है, क्योंकि तस्वीर स्टाइलशीट या पेज के बाद नहीं, उसी के साथ पहुँच जाती है।
मेरी SVG base64 में क्यों नहीं है?
क्योंकि उसके लिए base64 गलत एनकोडिंग है। SVG टेक्स्ट है, और URL टेक्स्ट पहले से ढो सकता है, यानी गिनती के कुछ ही अक्षरों को बचाना पड़ता है। उन्हें percent-encode करके बाकी को छोड़ देने से ऐसा URI बनता है जो उसी फ़ाइल के base64 से आम तौर पर पाँचवाँ हिस्सा छोटा होता है, और जिसे आप अपनी स्टाइलशीट में पढ़ भी सकते हैं। तत्वों के नाम, रंग और viewBox, सब वहीं मौजूद रहते हैं, बदलने के लिए तैयार। जो इक्का-दुक्का टूलचेन base64 पर ही अड़े, उसके लिए एक चेकबॉक्स भी है।
base64 मेरी तस्वीर को कितना बड़ा कर देता है?
करीब एक-तिहाई। फ़ाइल के तीन बाइट base64 के चार अक्षर बन जाते हैं, यानी 33%, और वह भी आगे लगने वाले data:image/png;base64, से पहले। इससे नीचे उतरा ही नहीं जा सकता, क्योंकि सिर्फ़ URL में चलने वाले अक्षरों से मनमाने बाइट लिखने की कीमत यही है। इसीलिए पेज फ़ाइल के साइज़ के बगल में अक्षरों की गिनती भी दिखा देता है, बजाय इसके कि आपको स्टाइलशीट तैनात होने पर पता चले।
तस्वीर को भीतर रखना असल में कब अच्छा विचार है?
जब वह छोटी हो और तुरंत चाहिए हो। हर पेज पर लोड होने वाली स्टाइलशीट में 2 KB का आइकन साफ़ फ़ायदे का सौदा है, क्योंकि एक चक्कर बच जाता है और तस्वीर उसी पल मौजूद रहती है जिस पल CSS। करीब 10 KB के आगे सौदा पलट जाता है। भीतर रखी तस्वीर अब अलग फ़ाइल रही ही नहीं, इसलिए उसे अलग से कैश नहीं किया जा सकता, किसी और चीज़ के साथ समानांतर लाया नहीं जा सकता, और उसके आसपास की फ़ाइल जब भी बदलती है वह पूरी की पूरी दोबारा डाउनलोड होती है। स्टाइलशीट में रखा 200 KB का फ़ोटोग्राफ़ साइट के हर पेज के क्रिटिकल पाथ में जुड़े 200 KB है। पेज बता देता है कि हर नतीजा उस लकीर के किस तरफ़ गिरता है।
क्या gzip base64 का बोझ वापस उतार देता है?
उतना नहीं जितना लोग सोचते हैं। पहले से कंप्रेस हो चुकी फ़ाइल का base64 ठीक से कंप्रेस होता ही नहीं, और PNG, JPEG तथा WebP तीनों पहले से कंप्रेस हो चुकी होती हैं। कंप्रेसर को ढूँढ़ने लायक दोहराव लगभग बचा ही नहीं होता, इसलिए base64 ने जो एक-तिहाई जोड़ा था उसमें से आम तौर पर दसवाँ हिस्सा भर वापस मिलता है, पूरा नहीं। percent-encode की गई SVG उलटा मामला है। वह अब भी टेक्स्ट है, इसलिए लगभग उतनी ही अच्छी तरह कंप्रेस होती है जितनी पहले होती थी, और उसे base64 न करने की एक और वजह यही है।
क्या इससे मेरी तस्वीर में कोई बदलाव आता है?
नहीं, और यहाँ के ज़्यादातर टूलों से यह एक जान-बूझकर रखा फ़र्क है। कुछ भी पिक्सलों में डिकोड करके दोबारा एनकोड नहीं होता। जो बाइट आपकी डिस्क से निकले, वही बाइट URI में जाते हैं। JPEG ठीक वही JPEG रहती है जो थी, उसी क्वालिटी पर, उन्हीं मापों के साथ। इसीलिए नतीजे को उसी फ़ाइल की नकल नहीं, खुद वही फ़ाइल कहा जा सकता है।
तो मेरा EXIF और GPS डेटा भी स्टाइलशीट में चला जाता है?
हाँ, और चिपकाने से पहले यही हिस्सा सोचने लायक है। चूँकि कुछ भी दोबारा एनकोड नहीं होता, कैमरे ने जो कुछ लिखा वह सब तस्वीर के साथ सफ़र करता है, यानी जगह, समय और कैमरे का सीरियल नंबर। फ़ोन की फ़ोटो में यह फ़ाइल का 30 KB तक हो सकता है, जो आपके पेज के क्रिटिकल पाथ पर 40 KB base64 बन जाता है, और जो रिपॉज़िटरी में कमिट होने वाली किसी चीज़ के भीतर पड़ा घर का पता होता है। पेज पढ़ लेता है कि JPEG, PNG या WebP में कितना मेटाडेटा है, और बता देता है। उसे पहले निकालने के लिए EXIF व्यूअर और रिमूवर इस्तेमाल कीजिए।
इसने मेरी फ़ाइल के एक्सटेंशन से अलग टाइप क्यों इस्तेमाल किया?
क्योंकि एक्सटेंशन गलत हो सकता है और बाइट नहीं। जिस फ़ाइल का नाम logo.png है पर जो असल में JPEG के रूप में एक्सपोर्ट हुई थी, वह इतनी आम है कि हर इमेज टूल को उससे निपटना ही पड़ता है। और जो data URI गलत टाइप घोषित करे वह बस बनता ही नहीं, न कोई पीछे हटने का रास्ता, न पढ़ने लायक कोई त्रुटि। इसलिए टाइप फ़ाइल के पहले कुछ बाइटों से पढ़ा जाता है, जो यहाँ के हर फ़ॉर्मैट में बिना किसी संदेह के बता देते हैं कि वह है क्या, और दोनों न मिलें तो पेज आपको बता देता है।
प्रीव्यू खाली है। कहाँ गड़बड़ हुई?
शायद URI में कहीं नहीं। HEIC और TIFF दोनों बिलकुल सही data URI बनाती हैं जिन्हें Safari के सिवा कोई ब्राउज़र खींचेगा नहीं, इसलिए आप उसे जहाँ भी चिपकाएँ तस्वीर वहाँ भी गायब ही रहेगी। उसे पहले इमेज कंप्रेसर या इमेज रिसाइज़र से PNG, JPEG या WebP में बदल लीजिए। फ़ॉर्मैट आम वाला हो, तो खुद फ़ाइल के खराब होने की संभावना ज़्यादा है। प्रीव्यू उसी URI से खींचा जाता है जो इस पेज ने बनाया, इसलिए खाली प्रीव्यू का मतलब है कि तस्वीर डिकोड ही नहीं हुई।
क्या data URI के साइज़ की कोई सीमा है?
ऐसी कोई नहीं जो आपको CSS में या <img> टैग में मिले, क्योंकि आज के ब्राउज़र वहाँ कोई व्यावहारिक छत नहीं लगाते। ब्राउज़र जिस चीज़ पर सीमा लगाते हैं वह है data URI को पते वाली पट्टी में टाइप करना, और ज़्यादातर अब किसी भी गंभीर चीज़ के लिए उससे मना कर देते हैं, ऐसी सुरक्षा वजहों से जिनका इस इस्तेमाल से कोई लेना-देना नहीं। असली सीमा वही ऊपर वाली है। कुछ भी तकनीकी तौर पर टूटने से बहुत पहले, जिस पेज में वह है वह आम इमेज फ़ाइल के मुकाबले धीमा पड़ चुका होता है।
क्या यह मुफ़्त है, और क्या इसके लिए खाता बनाना पड़ेगा?
यह मुफ़्त है, और यहाँ न कोई खाता है, न साइन-इन, न ट्रायल, न वॉटरमार्क। फ़ाइलों की गिनती या साइज़ पर भी कोई सीमा नहीं है, क्योंकि इनका बिल चुकाने वाला कोई सर्वर है ही नहीं। काम आपके अपने डिवाइस पर होता है। साइट पर विज्ञापन हैं और खर्च वही उठाते हैं, लेकिन विज्ञापनों को आपकी तस्वीरों के बारे में कुछ नहीं दिया जाता।
क्या यह ऑफ़लाइन चलता है?
हाँ। पेज एक बार लोड कर लीजिए, फिर इंटरनेट काट दीजिए, यह चलता रहेगा। कुछ अपलोड नहीं हो रहा, यह साबित करने का सबसे आसान तरीका भी यही है। जो टूल आपकी तस्वीरें एनकोड होने के लिए कहीं भेजता, वह प्लग निकालते ही रुक जाता।