ब्राउज़र में लोकल फ़ाइल प्रोसेसिंग कैसे काम करती है

अगर कुछ अपलोड ही नहीं होता, तो काम असल में कर कौन रहा है — और कहाँ?

5 मिनट का पठन · 17 अगस्त 2026 को समीक्षित

यहाँ “लोकल” का मतलब क्या है

आम ऑनलाइन कन्वर्टर दरअसल एक अपलोड एंडपॉइंट वाली वेबसाइट होती है। आपकी फ़ाइल ऐसी मशीन तक भेजी जाती है जो आपके नियंत्रण में नहीं है, वहीं प्रोसेस होती है, कुछ समय तक वहीं रखी रहती है, और फिर डाउनलोड के रूप में वापस दी जाती है। लोकल प्रोसेसिंग इस वाक्य का बीच का हिस्सा हटा देती है: आपकी फ़ाइल पढ़ने वाला कोड उसी ब्राउज़र टैब के अंदर, आपके अपने प्रोसेसर पर चलता है जो पहले से खुला है, और नतीजा वापस आपकी अपनी डिस्क पर लिखा जाता है।

साइट अब भी नेटवर्क से ही आती है — HTML, स्टाइलशीट, स्क्रिप्ट और WebAssembly मॉड्यूल, सब किसी भी वेब पेज की तरह सर्वर से आते हैं। फ़र्क दिशा का है। प्रोग्राम कोड नीचे आता है; आपकी फ़ाइल ऊपर नहीं जाती।

ब्राउज़र में ज़रूरी हिस्से पहले से मौजूद हैं

प्लेटफ़ॉर्म की वे सुविधाएँ जिनसे लोकल फ़ाइल टूल बनता है
सुविधा	यह क्या देती है
File और Blob API	यूज़र की चुनी या ड्रॉप की गई फ़ाइल के बाइट बिना फ़ॉर्म सबमिट किए पढ़ना
Web Workers	भारी काम बैकग्राउंड थ्रेड पर चलाना, ताकि इंटरफ़ेस चलता रहे
WebAssembly	कंपाइल की गई C, C++ या Rust कोडेक लाइब्रेरी को लगभग नेटिव रफ़्तार पर चलाना
Canvas और OffscreenCanvas	इमेज को डीकोड करना, ड्रॉ करना, रीसाइज़ करना और दोबारा एन्कोड करना
WebCodecs	ब्राउज़र के अपने हार्डवेयर-एक्सेलरेटेड वीडियो एन्कोडर और डीकोडर तक पहुँच
WebGPU	मॉडल इनफ़रेंस और समानांतर पिक्सेल काम ग्राफ़िक्स प्रोसेसर पर चलाना
File System Access	जहाँ समर्थन हो, नतीजा सीधे यूज़र की चुनी जगह पर लिखना

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

फ़ाइल किस रास्ते से गुज़रती है

आप एक फ़ाइल चुनते हैं। ब्राउज़र पेज को उसका हैंडल देता है — कॉपी नहीं, एक रेफ़रेंस।
पेज शुरुआती बाइट पढ़कर फ़ाइल का असली प्रकार उसके सिग्नेचर से पहचानता है, एक्सटेंशन पर भरोसा करने के बजाय।
वह अनुमान लगाता है कि काम में कितनी मेमोरी लगेगी, और अगर वह डिवाइस की सुरक्षित क्षमता से ज़्यादा है तो काम से मना कर देता है या उसे कतार में डाल देता है।
बाइट एक Web Worker में ट्रांसफ़र किए जाते हैं। ArrayBuffer ट्रांसफ़र करने से उसकी कॉपी नहीं बनती, मालिकाना हक बदल जाता है, इसलिए बड़ी फ़ाइल मेमोरी में दो बार मौजूद नहीं रहती।
वर्कर के अंदर असल डीकोडिंग और एन्कोडिंग कोई WebAssembly कोडेक या कोई प्लेटफ़ॉर्म API करता है।
नतीजा बाइट के रूप में लौटता है, Blob में लपेटा जाता है, और आपको डाउनलोड के रूप में दिया जाता है या आपकी चुनी जगह पर लिख दिया जाता है।
उस Blob का अस्थायी URL रद्द कर दिया जाता है और बफ़र छोड़ दिए जाते हैं।

WebAssembly ही वह हिस्सा है जिसने तस्वीर बदली

इमेज और वीडियो कोडेक दशकों की बारीकी से ऑप्टिमाइज़ की गई C हैं। उन्हें JavaScript में दोबारा लिखना कभी व्यावहारिक नहीं था। WebAssembly एक पोर्टेबल बाइनरी इंस्ट्रक्शन फ़ॉर्मैट है जिसे ब्राउज़र सैंडबॉक्स में नेटिव कोड के करीब की रफ़्तार से चलाते हैं, यानी वे मौजूदा लाइब्रेरी जैसी हैं वैसी ही कंपाइल करके ब्राउज़र तक भेजी जा सकती हैं।

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

नेटवर्क से अब भी क्या आता है, और वह आपकी फ़ाइल क्यों नहीं है

नेटवर्क से तीन चीज़ें आती हैं: पेज खुद, आपने जो टूल खोला है उसका इंजन, और — बैकग्राउंड हटाने के लिए — मॉडल वेट्स। ये तीनों FileSlimmer की अपनी स्टैटिक एसेट हैं, जो आपके बाइट पढ़े जाने से पहले FileSlimmer के अपने ऑरिजिन से ही ली जाती हैं। ये डाउनलोड हैं, इन्हें कैश किया जा सकता है, और पहली बार के बाद इन्हें बिना किसी नेटवर्क के ब्राउज़र के अपने कैश से ही परोसा जा सकता है।

उसके आगे सब कुछ लोकल है। इंजनों को फ़ाइल के बाइट सिर्फ़ पेज से postMessage के ज़रिए मिलते हैं; उन्हें कभी कोई ऐसा URL नहीं दिया जाता जहाँ वे कुछ भेज सकें, और एक कंटेंट सिक्योरिटी पॉलिसी यह भी सीमित कर देती है कि पेज किससे कनेक्ट कर सकता है, भले कोई कोड कोशिश करे।

समझौते, साफ़ शब्दों में

लोकल प्रोसेसिंग बनाम सर्वर प्रोसेसिंग
पहलू	आपके ब्राउज़र में	सर्वर पर
आपकी फ़ाइल कहाँ जाती है	कहीं नहीं	ऐसी मशीन पर जो आपके नियंत्रण में नहीं
रफ़्तार	जितनी आपका डिवाइस दे सके	जितनी ऑपरेटर ने खरीदी हो
बहुत बड़ी फ़ाइलें	ब्राउज़र की मेमोरी तक सीमित	ऑपरेटर की तय सीमाओं तक सीमित
ऑफ़लाइन चलता है	इंजन कैश हो जाने के बाद, हाँ	नहीं
असामान्य फ़ॉर्मैट	सिर्फ़ वही जो WebAssembly में कंपाइल हो सके	जो भी ऑपरेटर इंस्टॉल कर ले
हज़ार फ़ाइलों का बैच	डिवाइस की क्षमता से बँधा	आम तौर पर ज़्यादा उपयुक्त

लोकल प्रोसेसिंग हर हाल में बेहतर नहीं है। यह तब बेहतर है जब फ़ाइल निजी हो, डिवाइस सक्षम हो, और काम मेमोरी में समा जाए। सर्वर तब बेहतर है जब आपको एक मशीन की क्षमता से कहीं ज़्यादा प्रोसेस करना हो। यह साफ़ रखना कि आप किस स्थिति में हैं, इस ज़िद से ज़्यादा काम का है कि कोई एक तरीका हर जगह जीतता है।

यह किस बात का दावा नहीं करता

यह इस बात का बयान है कि यह एप्लिकेशन क्या करता है। यह आपके ब्राउज़र एक्सटेंशन के बारे में दावा नहीं है, जो आपके खोले हुए किसी भी पेज की सामग्री पढ़ सकते हैं; न आपके ऑपरेटिंग सिस्टम के बारे में, जो आपकी छुई हर फ़ाइल देख सकता है; और न आपके नेटवर्क ऑपरेटर के बारे में, जिसे यह दिखता है कि आपने कौन-सी साइट खोली। ये सब किसी भी वेबसाइट की पहुँच से बाहर हैं, और जो टूल आपको इसका उल्टा बताए वह अपनी बात बढ़ा-चढ़ाकर कह रहा है।

दावा सीमित और जाँचने लायक है: आपकी चुनी हुई फ़ाइलें इसी ब्राउज़र में लोकल तौर पर प्रोसेस होती हैं और FileSlimmer उन्हें अपलोड नहीं करता। अगला गाइड बताता है कि इसे मानने के बजाय खुद कैसे जाँचें।

इसके लिए टूल

स्रोत

और गाइड

सभी FileSlimmer गाइड