ब्राउज़र-आधारित फ़ाइल रूपांतरण: यह कैसे काम करता है और आपकी फ़ाइलें निजी क्यों रहती हैं

सर्वर-आधारित कनवर्टर पर फ़ाइल अपलोड करें और तीन चीज़ें होती हैं। आपकी फ़ाइल नेटवर्क के माध्यम से एक IP पते पर जाती है जिसे आप नियंत्रित नहीं करते। उस सर्वर पर एक प्रक्रिया इसे डिकोड करती है। फिर, साइट की अवधारण नीति के आधार पर, फ़ाइल मिनटों से लेकर हमेशा के लिए डिस्क पर पड़ी रहती है।

ब्राउज़र टैब में वही काम करें और फ़ाइल कभी भी आपकी मशीन की RAM नहीं छोड़ती। डिकोडर ब्राउज़र इंजन द्वारा लागू WebAssembly सैंडबॉक्स के अंदर चलता है। नेटवर्क को कभी छुआ नहीं जाता।

यह नीति का अंतर नहीं है। यह आर्किटेक्चर का अंतर है। सर्वर-आधारित कनवर्टर आपकी फ़ाइलों को हटाने का वादा कर सकता है; ब्राउज़र-आधारित उन्हें लीक नहीं कर सकता क्योंकि वह उन्हें कभी प्राप्त ही नहीं करता।

आर्किटेक्चर

चार परतें क्लाइंट-साइड रूपांतरण को कार्यशील बनाती हैं:

परत 1: फ़ाइल पहुँच

जब आप ब्राउज़र टैब में कोई फ़ाइल ड्रॉप करते हैं, तो DragEvent या <input type="file"> JavaScript को एक File ऑब्जेक्ट देता है। File फ़ाइल की सामग्री नहीं है। यह एक संदर्भ है: एक नाम, आकार, MIME प्रकार, और एक विधि (file.arrayBuffer()) जो मांग पर डिस्क से मेमोरी में बाइट्स पढ़ती है।

जब तक वह विधि कॉल नहीं की जाती, शून्य बाइट्स स्थानांतरित हुए हैं। फ़ाइल आपके फ़ाइलसिस्टम पर रहती है। ब्राउज़र का फ़ाइल पिकर एक OS-स्तरीय डायलॉग है; वेब पृष्ठ केवल वही File ऑब्जेक्ट देखता है जिसे उपयोगकर्ता ने स्पष्ट रूप से चुना।

परत 2: प्रारूप पहचान

किसी भी फ़ाइल के पहले बाइट्स विश्वसनीय रूप से उसके प्रारूप की पहचान करते हैं। JPEG FF D8 FF से शुरू होता है। PNG 89 50 4E 47 से शुरू होता है। HEIC फ़ाइल में ऑफ़सेट 8 पर heic या heif ब्रांड के साथ एक ftyp बॉक्स होता है।

फ़ाइल का हेडर पढ़ना (आमतौर पर पहले 32 बाइट्स) यह पुष्टि करने के लिए पर्याप्त है कि वह वास्तव में क्या है, एक्सटेंशन की परवाह किए बिना। यह जाँच किसी भी डिकोडर द्वारा पिक्सेल डेटा को छूने से पहले चलती है। यदि हेडर मेल नहीं खाता, तो फ़ाइल तुरंत अस्वीकार कर दी जाती है। कोई बर्बाद CPU नहीं, डिकोड के बीच में कोई भ्रामक त्रुटि संदेश नहीं।

परत 3: डिकोडिंग

कच्चे बाइट्स डिकोडर के माध्यम से पिक्सेल बनते हैं। कौन सा डिकोडर प्रारूप पर निर्भर करता है:

• JPEG, PNG, WebP, BMP: ब्राउज़र इनके लिए मूल डिकोडर प्रदान करता है। createImageBitmap() संपीड़ित बाइट्स को प्लेटफ़ॉर्म के कोडेक (Windows पर Windows Imaging Component, macOS पर Core Graphics, Linux/ChromeOS पर Skia) को सौंपता है और कच्चे पिक्सेल डेटा लौटाता है। यह पथ तेज़ है, जहाँ OS समर्थन करता है वहाँ हार्डवेयर-त्वरित है, और किसी अतिरिक्त कोड की आवश्यकता नहीं है।
• HEIC: Safari के अलावा कोई ब्राउज़र मूल HEIC डिकोडर प्रदान नहीं करता। हमारा कनवर्टर libheif, एक C लाइब्रेरी, को WebAssembly में संकलित करके बंडल करता है। .wasm बाइनरी (~1.2 MB संपीड़ित) एक बार डाउनलोड होती है और कैश होती है। यह HEIF/HEIC फ़ाइलों को पूरी तरह से WASM सैंडबॉक्स के अंदर कच्चे RGB पिक्सेल में डिकोड करता है।
• PDF: PDF.js (Mozilla का PDF रेंडरर) प्रत्येक पृष्ठ को अनुरोधित रिज़ॉल्यूशन पर canvas पर रेंडर करता है। कोई सर्वर-साइड रेंडरिंग नहीं। PDF कभी ब्राउज़र नहीं छोड़ता।

प्रत्येक डिकोडर मेमोरी से पढ़ता है और मेमोरी में लिखता है। कोई सॉकेट नहीं खोलता। विशेष रूप से WASM सैंडबॉक्स नेटवर्क अनुरोध नहीं कर सकता: ब्राउज़र WebAssembly मॉड्यूल को नेटवर्किंग API प्रदान नहीं करता। भले ही C कोड socket() कॉल करे, सैंडबॉक्स इसे ट्रैप कर लेगा।

परत 4: एन्कोडिंग

कच्चे पिक्सेल <canvas> तत्व के 2D संदर्भ में जाते हैं। canvas.toBlob() या canvas.toDataURL() JPG, PNG, या WebP आउटपुट के लिए ब्राउज़र के अंतर्निर्मित एन्कोडर को कॉल करता है। एन्कोडर प्लेटफ़ॉर्म-मूल कोड है: वही कोड पथ जिसका उपयोग आपका ऑपरेटिंग सिस्टम स्क्रीनशॉट सहेजने के लिए करता है।

आउटपुट एक Blob है, एक इन-मेमोरी बाइट बफ़र। यह डाउनलोड लिंक को सौंपा जाता है या JavaScript में निर्मित ZIP संग्रह में पैक किया जाता है। किसी भी बिंदु पर कोई बाइट नेटवर्क सॉकेट को नहीं छूता।

ब्राउज़र क्या लागू करता है

वेब पृष्ठ एक सैंडबॉक्स के अंदर चलते हैं जिसे ब्राउज़र इंजन स्तर पर बनाए रखता है। यह कोई विनम्र समझौता नहीं है। यह प्रक्रिया पृथक्करण द्वारा लागू किया गया है:

रेंडरर प्रक्रिया: JavaScript इंजन, DOM, और WASM रनटाइम बिना सीधे फ़ाइलसिस्टम या नेटवर्क पहुँच के एक सैंडबॉक्स्ड प्रक्रिया में रहते हैं। यह ब्राउज़र प्रक्रिया से IPC के माध्यम से बाहरी दुनिया से संचार करता है।

साइट पृथक्करण: आधुनिक ब्राउज़र प्रत्येक ओरिजिन को अपनी रेंडरर प्रक्रिया में रखते हैं। file-convert-factory.org पर आपकी फ़ाइलें किसी अन्य डोमेन पर चल रहे JavaScript के लिए अदृश्य हैं।

WASM सैंडबॉक्स: WebAssembly मॉड्यूल एक सपाट रैखिक मेमोरी बफ़र देखते हैं और कुछ नहीं। कोई फ़ाइलसिस्टम API नहीं, कोई fetch जब तक JavaScript से स्पष्ट रूप से आयात न किया जाए, DOM या अन्य ब्राउज़र API तक कोई पहुँच नहीं। एक समझौता किया गया WASM मॉड्यूल सबसे बुरा जो कर सकता है वह अपनी स्वयं की मेमोरी को दूषित करना और टैब को क्रैश करना है।

एक सर्वर-साइड कनवर्टर सर्वर के OS पर एक विशेषाधिकार प्राप्त प्रक्रिया के रूप में चलता है। यह डिस्क से पढ़ सकता है, डिस्क पर लिख सकता है, नेटवर्क कनेक्शन खोल सकता है, और चाइल्ड प्रक्रियाएँ बना सकता है। सुरक्षा मॉडल सर्वर ऑपरेटर की क्षमता और इरादों पर निर्भर करता है। ब्राउज़र सैंडबॉक्स केवल ब्राउज़र इंजन की शुद्धता पर निर्भर करता है, और ब्राउज़र सैंडबॉक्स सॉफ़्टवेयर में सबसे भारी ऑडिट की गई सुरक्षा सीमाओं में से हैं।

सर्वर-आधारित कनवर्टर क्या वादा करते हैं (और क्या नहीं)

सर्वर-आधारित कनवर्टर स्वाभाविक रूप से दुर्भावनापूर्ण नहीं हैं। कई अच्छी नीयत वाली टीमों द्वारा संचालित हैं। समस्या संरचनात्मक है:

1. अपलोड चरण एक प्रतिलिपि है। आपकी फ़ाइल अब दो स्थानों पर मौजूद है। आप एक प्रतिलिपि को नियंत्रित करते हैं। कोई और दूसरी को नियंत्रित करता है।
2. हटाना एक वादा है। "हम 24 घंटे बाद फ़ाइलें हटा देते हैं" का अर्थ है लॉग लाइन, cron जॉब, बैकअप सिस्टम, और सर्वर पहुँच वाले प्रत्येक कर्मचारी पर भरोसा करना। इनमें से कुछ भी बाहर से सत्यापित नहीं किया जा सकता।
3. मेटाडेटा फ़ाइल के साथ यात्रा करता है। आपकी फ़ोटो का EXIF डेटा (GPS निर्देशांक, कैमरा सीरियल नंबर, टाइमस्टैम्प) फ़ाइल बाइट्स का हिस्सा है। यदि फ़ाइल अपलोड की जाती है, तो मेटाडेटा अपलोड किया जाता है। हमारा EXIF गोपनीयता गाइड ठीक-ठीक बताता है कि इसमें क्या है और इसे कैसे हटाएँ। संक्षिप्त संस्करण: इस साइट पर प्रत्येक कनवर्टर मेटाडेटा हटाता है क्योंकि यह पिक्सेल को डिकोड करता है और उन्हें फिर से एन्कोड करता है, वह सब कुछ छोड़ देता है जो छवि डेटा नहीं है।
4. HTTPS पाइप की रक्षा करता है, एंडपॉइंट की नहीं। TLS पारगमन में अपलोड को एन्क्रिप्ट करता है। यह फ़ाइल के पहुँचने के बाद क्या होता है, इसके बारे में कुछ नहीं करता।

ब्राउज़र-आधारित कनवर्टर की गोपनीयता गारंटी संकरी लेकिन मज़बूत है। यह कहती है: आपकी फ़ाइलें आपके डिवाइस को नहीं छोड़तीं क्योंकि ऐसा करने के लिए कोई कोड पथ नहीं है। यह सत्यापनीय है। फ़ाइल कनवर्ट करते समय DevTools में Network टैब खोलें। आप WASM बाइनरी को एक बार लोड होते देखेंगे, फिर कुछ नहीं। शून्य बाइट्स अपलोड। /api/convert पर कोई अनुरोध नहीं। कोई WebSocket ट्रैफ़िक नहीं। रूपांतरण पूरी तरह से रेंडरर प्रक्रिया के अंदर होता है।

इसे स्वयं सत्यापित करें

आपको किसी की बात पर विश्वास करने की आवश्यकता नहीं है। Chrome DevTools (F12) खोलें, Network टैब पर स्विच करें, और किसी भी टूल पृष्ठ पर एक फ़ाइल कनवर्ट करें। आपको केवल यह नेटवर्क गतिविधि दिखाई देगी:

1. पृष्ठ HTML, CSS, और JavaScript: पहली विज़िट पर एक बार लोड।
2. WASM बाइनरी (HEIC कनवर्टर के लिए): एक बार लोड, उसके बाद कैश।
3. एनालिटिक्स अनुरोध (यदि आपने उन्हें अवरुद्ध नहीं किया है)।

कोई फ़ाइल डेटा ब्राउज़र नहीं छोड़ता। प्रत्येक अनुरोध का Content-Length मेगाबाइट्स में नहीं, किलोबाइट्स में मापा जाता है। यह किसी भी व्यक्ति द्वारा स्वतंत्र रूप से सत्यापनीय है जो DevTools खोलना जानता है।

सर्वर-आधारित सेवा के बारे में ऐसा नहीं कहा जा सकता। आप फ़ाइल अपलोड करते हैं, परिणाम प्राप्त करते हैं, और भरोसा करते हैं कि सर्वर ने इसे हटा दिया।

संबंधित उपकरण

इस साइट पर प्रत्येक कनवर्टर इसी आर्किटेक्चर का पालन करता है। पाइपलाइन (ड्रॉप, सत्यापन, डिकोड, एन्कोड, डाउनलोड) सभी 23 उपकरणों में समान रूप से चलती है:

• HEIC से JPG · HEIC से PNG · HEIC से WebP
• JPG से PNG · JPG से WebP · JPG से ICO
• PNG से JPG · PNG से WebP · PNG से ICO
• WebP से JPG · WebP से PNG · WebP से ICO
• BMP से JPG · BMP से PNG · BMP से WebP · BMP से ICO
• PDF से JPG · PDF से PNG · PDF से WebP
• छवि से टेक्स्ट (OCR): समान क्लाइंट-साइड आर्किटेक्चर, Tesseract को WASM में चलाता है

WASM सैंडबॉक्स के तकनीकी विवरण के लिए, हमारा WebAssembly व्याख्याकार देखें। आपकी फ़ोटो में कौन से मेटाडेटा होते हैं, इसकी गहरी जानकारी के लिए, EXIF गोपनीयता गाइड बाइट दर बाइट पढ़ने और हटाने की प्रक्रिया बताता है।