Chrome DevTools स्टोरेज: हर मैकेनिज्म की पूरी जानकारी (असली इस्तेमाल के साथ)

DevTools खोलें, Application पर क्लिक करें, और बाईं ओर की साइडबार देखें। Cookies, Local Storage, Session Storage, IndexedDB, Cache Storage, Shared Storage, Background Services… यह काफी कुछ है। मैंने सीनियर डेवलपर्स को भी हर चीज़ के लिए localStorage का इस्तेमाल करते देखा है — ऑथ टोकन, शॉपिंग कार्ट, यहाँ तक कि मेगाबाइट्स में API रिस्पॉन्स — सिर्फ इसलिए क्योंकि यह वही है जिसे वे जानते हैं। यह हमेशा गलत नहीं होता, लेकिन यह शायद ही कभी सबसे अच्छा विकल्प होता है। आइए असल में देखें कि इनमें से हर मैकेनिज्म क्या करता है, DevTools में आपको यह कहाँ मिलेगा, और — सबसे ज़रूरी — आपको इसे बाकी छह विकल्पों के बजाय कब चुनना चाहिए जो ठीक बगल में बैठे हैं।

Application पैनल का महत्व क्यों है

ब्राउज़रों में एकीकृत स्टोरेज इंस्पेक्टर आने से पहले, “मेरा डेटा क्यों नहीं टिक रहा” को डीबग करने का मतलब था अंदाज़े के सहारे console.log का सहारा लेना। Chrome DevTools के Application पैनल ने यह बदल दिया — यह आपको कुकीज़, लोकल स्टोरेज, सेशन स्टोरेज, IndexedDB डेटाबेस, कैश स्टोरेज एंट्रीज़, सर्विस वर्कर्स, और यहाँ तक कि Shared Storage और Interest Groups जैसी नई Privacy Sandbox फ़ीचर्स को देखने, संपादित करने और मैन्युअल रूप से डिलीट करने के लिए एक जगह देता है [1]।

यह इसलिए मायने रखता है क्योंकि इन हर तरह के स्टोरेज का व्यवहार अलग-अलग होता है — अलग-अलग साइज़ लिमिट, अलग-अलग जीवनकाल, अलग-अलग सिंक/एसिंक व्यवहार, सर्वर को अलग-अलग दृश्यता। गलत विकल्प चुनना सिर्फ एक स्टाइल चॉइस नहीं है; यह आपके ऐप के परफॉर्मेंस को बिगाड़ सकता है, टैब्स के बीच डेटा लीक कर सकता है, या बिना आपको पता चले चुपचाप ब्राउज़र द्वारा मिटाया जा सकता है। चलिए इसमें गहराई से उतरते हैं।

पूरी तस्वीर — एक झलक में तुलना

हर एक में गहराई से जाने से पहले, यहाँ वह चीट-शीट है जो काश कोई मुझे सालों पहले दे देता:

ये क्षमताएँ और व्यवहार सीधे उस तुलना डेटा से लिए गए हैं जिसे Chrome और MDN प्रकाशित करते हैं, और यह लगभग वैसा ही है जैसा मैं खुद DevTools में टटोलते वक्त देखता हूँ — सेशन/लोकल स्टोरेज प्रति ओरिजिन लगभग 5MB के आसपास रहता है, कुकीज़ की सीमा लगभग 4KB है, और IndexedDB डिस्क स्पेस के आधार पर सैकड़ों मेगाबाइट्स या उससे ज़्यादा तक फैल सकता है [2]।

अब चलिए वाकई हर एक में जाते हैं — यह किसके लिए है, और एक असली परिदृश्य जहाँ मैं इसे चुनूँगा।

Cookies — एकमात्र ऐसी चीज़ जिसे आपका सर्वर वाकई पढ़ सकता है

यहाँ वह बात है जिसे लगभग सभी पहले से जानते हैं लेकिन फिर भी कहीं न कहीं गलत समझ बैठते हैं: कुकीज़ ही एकमात्र क्लाइंट स्टोरेज मैकेनिज्म हैं जो हर मैचिंग HTTP रिक्वेस्ट के साथ अपने आप सर्वर को भेज दी जाती हैं [2]। जब आपको सर्वर-साइड सेशन वैलिडेशन की ज़रूरत हो तो यह एक फ़ीचर है, और जब आप उनमें मेगाबाइट्स का कचरा भरने लगते हैं तो यह एक परफॉर्मेंस टैक्स बन जाता है।

DevTools में, ये आपको Application → Storage → Cookies → (कोई ओरिजिन चुनें) के अंतर्गत मिलेंगी। आप वैल्यूज़ को इनलाइन एडिट कर सकते हैं, नई जोड़ सकते हैं, नाम से फ़िल्टर कर सकते हैं, और HttpOnly, Secure, और SameSite जैसे फ़्लैग वहीं टेबल में देख सकते हैं [1]।

असली इस्तेमाल का मामला: ऑथेंटिकेशन सेशन। जब कोई यूज़र लॉगिन करता है, तो सर्वर एक HttpOnly कुकी सेट करता है जिसमें सेशन ID होती है। चूंकि यह HttpOnly है, JavaScript इसे पढ़ नहीं सकता (इसलिए कोई XSS बग इसे सीधे चुरा नहीं सकता), और चूंकि यह एक कुकी है, यह हर रिक्वेस्ट के साथ चली जाती है ताकि सर्वर यूज़र को “याद रखने” के लिए आपको क्लाइंट-साइड कोड लिखे बिना ही सेशन वैलिडेट कर सके।

एक दूसरा, बहुत मौजूदा इस्तेमाल का मामला है: सहमति और पर्सनलाइज़ेशन फ़्लैग जिनकी सर्वर को रेंडर के समय ज़रूरत होती है — जैसे कि यूज़र किस A/B टेस्ट बकेट में है, या उसने कुकी बैनर स्वीकार किया है या नहीं — क्योंकि सर्वर को यह HTML बनाने से पहले जानना ज़रूरी है।

यह जानना भी ज़रूरी है कि थर्ड-पार्टी कुकी की कहानी एक रोलरकोस्टर रही है। Google ने पहले घोषणा की थी कि वह थर्ड-पार्टी कुकीज़ को पूरी तरह खत्म कर देगा, फिर 2024 के मध्य में इसे वापस ले लिया — अब Chrome उन्हें पूरी तरह ब्लॉक करने के बजाय यूज़र को एक “चॉइस” प्रॉम्प्ट दिखाता है [3][4]। Safari और Firefox पहले से ही डिफ़ॉल्ट रूप से थर्ड-पार्टी कुकीज़ ब्लॉक करते हैं, इसलिए अगर आपका ऐप ट्रैकिंग या एम्बेड्स के लिए क्रॉस-साइट कुकीज़ पर निर्भर है, तो आप पहले से ही आंशिक रूप से कुकीज़-रहित दुनिया में जी रहे हैं, चाहे Chrome इसे ज़बरदस्ती करे या न करे [4]। और चाहे फर्स्ट-पार्टी हो या थर्ड-पार्टी, क्रॉस-साइट कुकीज़ में SameSite=None; Secure होना ज़रूरी है — यह Chrome 80 के बाद से एक सख्त शर्त रही है [4]।

localStorage — वह आसान दराज़ जिसमें सब कुछ ठूंस दिया जाता है

localStorage एक सिंक्रोनस की-वैल्यू स्टोर है, जो ओरिजिन के दायरे में सीमित है, और ब्राउज़र रीस्टार्ट के बाद भी टिका रहता है। यह आपको Application → Storage → Local Storage → (ओरिजिन) के अंतर्गत मिलेगा, जहाँ DevTools आपको सीधे टेबल में एंट्रीज़ जोड़ने, संपादित करने और मिटाने देता है [1]।

यह वाकई किसके लिए अच्छा है:

• यूज़र प्रेफरेंस — थीम (डार्क/लाइट), भाषा, लेआउट डेंसिटी
• छोटे फीचर फ्लैग या “यह टूलटिप दोबारा मत दिखाओ” जैसे मार्कर
• छोटे, कम बदलने वाले API रिस्पॉन्स की हल्की कैशिंग (सोचिए: देशों के कोड्स की एक सूची, यूज़र के पूरे ऑर्डर इतिहास की नहीं)

जहाँ मैंने इसे गलत होते देखा है: लोग “सुविधा” के लिए localStorage में JWT स्टोर करते हैं, यह समझे बिना कि पेज पर चलने वाली कोई भी स्क्रिप्ट — चाहे वह किसी समझौता किए गए npm पैकेज से आई हो या किसी XSS छेद से — इसे पढ़ सकती है। HttpOnly वाली कुकीज़ कम से कम आपके टोकन और मनमानी JavaScript के बीच एक दीवार खड़ी कर देती हैं। अगर आपको क्लाइंट-साइड पर टोकन स्टोर करना ही पड़े और कुकीज़ का इस्तेमाल न कर सकें, तो कम से कम यह समझ लें कि आप XSS-प्रतिरोध को सुविधा के बदले में दे रहे हैं।

दूसरी समस्या: localStorage सिंक्रोनस है और मेन थ्रेड को ब्लॉक करता है। किसी टेक्स्ट एडिटर में हर कीस्ट्रोक पर कुछ सौ KB JSON लिख दीजिए, और आपको अपने UI में हकलाहट महसूस होने लगेगी। मैंने वाकई एक “साधारण” ऑटोसेव फीचर को इनपुट रिस्पॉन्सिवनेस को तबाह करते देखा है क्योंकि कोई हर oninput इवेंट पर localStorage.setItem(JSON.stringify(hugeObject)) कर रहा था। यह बिल्कुल वैसी ही “मेरी मशीन पर तो काम कर रहा है” वाली बग है जिसे Application पैनल पकड़ने में मदद करता है — Storage टैब खोलें, साइज़ को रियल टाइम में बढ़ते देखें, और आप समस्या को अपने यूज़र्स से पहले पकड़ लेंगे।

sessionStorage — वह जो एक टैब अपने पड़ोसी के साथ साझा नहीं करेगा

sessionStorage DevTools में बिल्कुल localStorage जैसा दिखता है (वही टेबल, वही एडिट/डिलीट UI, बस साइडबार में अलग एंट्री [1]), लेकिन इसमें एक अहम फर्क है: यह सिर्फ एक टैब के दायरे में सीमित है, और जब वह टैब बंद होता है तो यह गायब हो जाता है। यहाँ तक कि बिल्कुल एक ही ओरिजिन की ओर इशारा करने वाले दो टैब भी sessionStorage डेटा साझा नहीं करेंगे — पहली बार इसका सामना करने पर यह बहुत लोगों को चौंका देता है।

असली इस्तेमाल के मामले:

• मल्टी-स्टेप फॉर्म्स / चेकआउट विज़ार्ड्स — “स्टेप 2 ऑफ 4” डेटा स्टोर करना ताकि रीफ्रेश करने पर यूज़र की प्रगति बर्बाद न हो, लेकिन आप नहीं चाहते कि यह हमेशा के लिए बना रहे
• डुप्लिकेट फॉर्म सबमिशन रोकना — फॉर्म सबमिट होने पर एक फ़्लैग सेट करना, दोबारा सबमिट होने देने से पहले उसे जांचना
• एक बार का ऑनबोर्डिंग फ़्लो जिसे रीसेट हो जाना चाहिए अगर यूज़र नए टैब में ऐप ताज़ा खोलता है

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

IndexedDB — जब आपको वाकई ब्राउज़र में एक डेटाबेस चाहिए

यहीं से चीज़ें ज़्यादा दिलचस्प हो जाती हैं — और, ईमानदारी से कहूं तो, यहीं से ये थोड़ी मुश्किल भी हो जाती हैं। IndexedDB एक पूर्ण ट्रांज़ैक्शनल, एसिंक्रोनस, NoSQL-जैसा डेटाबेस है जो ब्राउज़र में बना हुआ है, जो स्ट्रक्चर्ड डेटा, ब्लॉब्स, और फ़ाइलों को स्टोर कर सकता है, साथ ही इंडेक्स और रेंज क्वेरीज़ का समर्थन भी करता है [2][5]। DevTools में यह Application → Storage → IndexedDB के अंतर्गत मिलता है, जहाँ आप व्यक्तिगत डेटाबेस, ऑब्जेक्ट स्टोर्स, और यहाँ तक कि व्यक्तिगत रिकॉर्ड्स में भी जा सकते हैं [1]।

असली इस्तेमाल के मामले जिनके लिए मैं इसे वाकई चुनूँगा:

• ऑफ़लाइन-फर्स्ट ऐप्स — नोट लेने वाले ऐप्स, टू-डू ऐप्स, ईमेल क्लाइंट जिन्हें कमज़ोर कनेक्शन पर भी काम करना हो
• बड़े API रिस्पॉन्स सेट्स को कैश करना — जैसे कोई प्रोजेक्ट मैनेजमेंट टूल जो हज़ारों टास्क कैश करता है ताकि UI तुरंत महसूस हो
• क्लाइंट-साइड पर फ़ाइलें/ब्लॉब्स स्टोर करना — इमेज एडिटर्स, PDF व्यूअर्स, बाइनरी डेटा से जुड़ी कोई भी चीज़ जो localStorage की स्ट्रिंग-ओनली, ~5MB दुनिया के लिए बहुत बड़ी हो

समझौता यह है कि IndexedDB का API मशहूर रूप से अटपटा है — कच्चा IndexedDB कोड नेस्टेड कॉलबैक्स और onsuccess/onerror हैंडलर्स से भरा होता है जो 2010 के किसी कोड जैसा लगता है (क्योंकि, खैर, यह कुछ हद तक है ही)। ज़्यादातर टीमें इसे Dexie.js या idb जैसी लाइब्रेरी से रैप करती हैं ताकि इसे झेलना आसान हो जाए। अगर आप इसे डीबग कर रहे हैं, तो Application पैनल का IndexedDB व्यूअर सच में DevTools के सबसे सुहावने हिस्सों में से एक है — आप ऑब्जेक्ट स्टोर्स को विस्तृत कर सकते हैं, रिकॉर्ड्स का निरीक्षण कर सकते हैं, और बिना एक भी लाइन कोड लिखे एक पूरा डेटाबेस मिटा सकते हैं।

इतिहास का एक अंश जो बताता है कि IndexedDB क्यों जीता: Chrome पहले Web SQL Database का भी समर्थन करता था, जो SQLite-आधारित रिलेशनल API था। इसे डिप्रिकेट करके Chromium 119 से पूरी तरह हटा दिया गया क्योंकि यह कभी मानकीकृत नहीं हुआ — सिर्फ Chromium ने ही इसके स्पेक को पूरी तरह लागू किया था [6]। अब आधिकारिक सलाह यह है कि ज़्यादातर मामलों के लिए Web Storage APIs या IndexedDB का इस्तेमाल करें, और गंभीर रिलेशनल/परफॉर्मेंस ज़रूरतों वाले ऐप्स के लिए, Origin Private File System के ऊपर चलने वाले WebAssembly में कंपाइल किए गए SQLite का इस्तेमाल करें [6] — जो हमें सुविधाजनक रूप से अगले सेक्शन तक ले आता है।

Cache Storage और Service Workers — ऐसी चीज़ें बनाना जो ऑफ़लाइन काम करें

यह वह जोड़ी है जो Progressive Web Apps को शक्ति देती है। एक service worker एक स्क्रिप्ट है जो आपके पेज और नेटवर्क के बीच बैठती है, रिक्वेस्ट्स को इंटरसेप्ट करती है, और Cache API / Cache Storage वह जगह है जहाँ यह असली रिस्पॉन्स ऑब्जेक्ट्स को छिपाती है [7][8]। DevTools में:

• Application → Application → Service Workers रजिस्ट्रेशन स्टेटस, स्कोप दिखाता है, और आपको अपडेट ट्रिगर करने, फ़ोर्स एक्टिवेशन करने, या ऑफ़लाइन होने का अनुकरण करने देता है [9]
• Application → Storage → Cache Storage Cache API के ज़रिए कैश की गई हर चीज़ की एक रीड-ओनली ब्राउज़ करने योग्य सूची है — आप निरीक्षण कर सकते हैं, URL के अनुसार फ़िल्टर कर सकते हैं, और अलग-अलग एंट्रीज़ मिटा सकते हैं [1][7]

असली इस्तेमाल का मामला: एक न्यूज़ साइट जो चाहती है कि लेख बिना सिग्नल वाली सबवे में भी पढ़े जा सकें। सर्विस वर्कर नेविगेशन रिक्वेस्ट्स को इंटरसेप्ट करता है, पहले Cache Storage को जांचता है, और सिर्फ ज़रूरत पड़ने पर ही नेटवर्क पर जाता है। या Twitter/X के “आप ऑफ़लाइन हैं” स्क्रीन के बारे में सोचिए जो अब भी आपकी आखिरी लोड हुई टाइमलाइन दिखाती है — यही Cache Storage अपना काम कर रहा है।

समझने वाली मुख्य अवधारणा — और मुझे यह तब तक ठीक से समझ नहीं आई जब तक मैंने इसे मुश्किल तरीके से डीबग नहीं किया — यह है कि Cache API सामान्य HTTP कैश से बिल्कुल अलग मैकेनिज्म है। HTTP कैश रिस्पॉन्स हेडर्स और ब्राउज़र हेयुरिस्टिक्स द्वारा संचालित होता है; Cache Storage API पूरी तरह कोड-संचालित है — आप तय करते हैं कि क्या कैश होगा, कब, और कितनी देर के लिए [8][7]। यह शक्तिशाली है, लेकिन इसका मतलब यह भी है कि पुराने एंट्रीज़ को इनवैलिडेट करना आपकी ज़िम्मेदारी है; ब्राउज़र इसे Cache-Control हेडर्स के आधार पर अपने आप नहीं करेगा जैसा वह HTTP कैश के लिए करता है।

एक डीबगिंग टिप जिसने मुझे एक झुंझलाने वाली दोपहर से बचाया: सर्विस वर्कर को अनरजिस्टर करने से उसके कैश साफ नहीं होते। ये स्वतंत्र हैं। अगर सर्विस वर्कर को मारने के बाद आपकी “फिक्स” दिख नहीं रही है, तो Cache Storage को अलग से जांचें — या बस Application → Storage के अंतर्गत बड़े लाल Clear storage बटन को दबाएं, जो एक क्लिक में सर्विस वर्कर्स को अनरजिस्टर करता है और सभी जुड़े हुए स्टोरेज को मिटा देता है [9][10]। उस एक बटन ने मुझे “मेरा पुराना कोड अब भी क्यों चल रहा है” जैसी सिरदर्दी से जितनी बार बचाया है, मैं उतना मानने को भी तैयार नहीं।

नए (और अजीब) वाले: OPFS, Shared Storage, और Storage Buckets

Application पैनल बढ़ता ही रहता है क्योंकि वेब प्लेटफ़ॉर्म बढ़ता ही रहता है। कुछ नई एंट्रीज़ जिनके बारे में जानना उपयोगी है:

• Origin Private File System (OPFS) — एक सैंडबॉक्स्ड, ओरिजिन-स्कोप्ड फ़ाइल सिस्टम जो बाइट-स्तर पर, उच्च-प्रदर्शन फ़ाइल एक्सेस देता है, जिसमें Web Workers से सिंक्रोनस रीड/राइट भी शामिल हैं [11]। यह ब्राउज़र-इन SQLite (WASM के ज़रिए) का पसंदीदा घर बन गया है और RxDB और ElectricSQL जैसी लोकल-फर्स्ट परियोजनाओं द्वारा इस्तेमाल होता है [11]। पकड़? DevTools के पास अभी तक नेटिव OPFS समर्थन नहीं है — आपको इसके फ़ाइल ट्री को DevTools के अंदर से ब्राउज़ करने के लिए OPFS Explorer जैसा थर्ड-पार्टी एक्सटेंशन चाहिए [12]।
• Shared Storage — Privacy Sandbox पहल का हिस्सा, यह साइट्स को क्रॉस-साइट डेटा स्टोर करने देता है बिना इसे सीधे JavaScript के सामने उजागर किए — आप सिर्फ प्राइवेसी-संरक्षित “वर्कलेट्स” के ज़रिए समग्र अंतर्दृष्टि निकाल सकते हैं। असली इस्तेमाल के मामलों में अद्वितीय विज्ञापन अभियान की पहुंच को मापना या थर्ड-पार्टी कुकीज़ पर निर्भर हुए बिना क्रिएटिव्स को घुमाना शामिल है [13]। आप कच्चे की-वैल्यू पेयर्स को Application → Storage → Shared Storage के अंतर्गत देख सकते हैं [1][13]।
• Storage Buckets — एक उभरता हुआ API जो आपको किसी ओरिजिन के स्टोरेज को अलग-अलग “बकेट्स” में बांटने देता है, जिनमें अपना खुद का कोटा और परसिस्टेंस व्यवहार होता है, ताकि आप, मसलन, महत्वपूर्ण ऑफ़लाइन डेटा वाले बकेट को persistent के रूप में चिह्नित कर सकें जबकि डिस्पोज़ेबल कैश डेटा वाले बकेट को दबाव में पहले बेदखल होने दें [14]।

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

Extension Storage — DevTools से chrome.storage को डीबग करना

अगर आप Chrome एक्सटेंशन बनाते या डीबग करते हैं, तो यह एक छिपा हुआ रत्न है। Application → Storage → Extension Storage के तहत, DevTools हर इंस्टॉल किए गए एक्सटेंशन को उसके chrome.storage.local और chrome.storage.sync डेटा के साथ निरीक्षण योग्य, संपादन योग्य की-वैल्यू पेयर्स के रूप में सूचीबद्ध करता है [17]।

दोनों स्टोरेज क्षेत्र बहुत अलग तरह से व्यवहार करते हैं। chrome.storage.local वर्तमान मशीन पर डेटा स्टोर करता है — तेज़, कोई आकार सीमा नहीं। chrome.storage.sync ऐसा डेटा लिखता है जिसे Chrome उन सभी डिवाइसों में चुपचाप सिंक कर देता है जहां यूज़र साइन इन है [18]। DevTools पैनल का असली फायदा: आप किसी भी की में क्लिक करके वैल्यू को लाइव एडिट कर सकते हैं और तुरंत देख सकते हैं कि आपका एक्सटेंशन अलग-अलग स्टोर्ड स्टेट्स पर कैसे रिस्पॉन्ड करता है।

Storage Buckets — ब्राउज़र को बताना कि पहले क्या हटाना है

Storage Buckets API एक असली प्रोडक्शन समस्या का Chromium का जवाब है: स्टोरेज प्रेशर इवेक्शन ओरिजिन के हिसाब से all-or-nothing होता है। Storage Buckets इसे ठीक करते हैं: आप स्टोरेज को अलग-अलग कोटा सीमाओं, इवेक्शन प्राथमिकता और परसिस्टेंस फ्लैग्स के साथ नामांकित बकेट्स में विभाजित कर सकते हैं [14]।

const criticalBucket = await navigator.storageBuckets.open("user-docs", {
  durability: "strict",
  persisted: true,
});
const cacheBucket = await navigator.storageBuckets.open("temp-cache", {
  durability: "relaxed",
  persisted: false,
});

user-docs बकेट strict + persisted: true के साथ चिह्नित है — ब्राउज़र इसे दबाव में नहीं छूएगा। temp-cache relaxed + persisted: false है — इवेक्शन के लिए उचित खेल। Application → Storage → Storage Buckets में आप हर नामांकित बकेट का निरीक्षण कर सकते हैं और सत्यापित कर सकते हैं कि आपकी परसिस्टेंस सेटिंग्स वही हैं जो आप सोचते हैं [14]।

Private State Tokens — निगरानी के बिना एंटी-फ्रॉड

Private State Tokens (पहले Trust Tokens कहा जाता था) एक Privacy Sandbox API है जो एक जारीकर्ता — जैसे कि एक साइट जो पहले से जानती है कि आप एक वास्तविक इंसान हैं — को किसी अन्य साइट पर आपके लिए बिना आपकी पहचान जोड़े या क्रॉस-साइट ट्रैकिंग सक्षम किए गारंटी देने देता है [19]।

Application → Storage → Private State Tokens में, DevTools दिखाता है कि किन जारीकर्ताओं ने वर्तमान ब्राउज़र प्रोफाइल में टोकन स्टोर किए हैं और हर जारीकर्ता के लिए कितने टोकन बचे हैं। नेटवर्क पैनल व्यक्तिगत जारी करने और रिडेम्पशन अनुरोधों को भी लॉग करता है ताकि आप पूरे फ्लो को ट्रेस कर सकें [19]। आप इनसे मिलेंगे अगर आप कोई एंटी-फ्रॉड या बॉट-डिटेक्शन सेवा एकीकृत कर रहे हैं जो थर्ड-पार्टी कुकीज़ से दूर चली गई है।

Interest Groups — ब्राउज़र खुद का विज्ञापन नीलामी कैसे चलाता है

Interest Groups Protected Audience API (पहले FLEDGE) का हिस्सा हैं। तीसरे पक्ष की कुकीज़ के बजाय, ब्राउज़र खुद आपको स्थानीय रूप से रुचि समूहों में जोड़ता है और डिवाइस पर बोली लगाने की नीलामी चलाता है [20]। आपका ब्राउज़िंग इतिहास कभी आपकी मशीन नहीं छोड़ता।

Application → Storage → Interest Groups में DevTools हर रुचि समूह दिखाता है जिसमें वर्तमान पेज ने आपके ब्राउज़र को जोड़ने के लिए कहा है, जिसमें मालिक, बिडिंग लॉजिक URL और उस समूह से जुड़े विज्ञापनों की सूची शामिल है [20]। इवेंट टाइमलाइन joined, bid, win, और leave इवेंट लॉग करती है। एक व्यावहारिक नोट: अगर आप पेज लोड होने के बाद Application पैनल खोलते हैं, तो आपको join इवेंट नहीं दिखेंगे — DevTools पहले से खुला रखकर पेज रिफ्रेश करें [20]।

कोटा, बेदखली, और आपका डेटा कभी-कभी क्यों… गायब हो जाता है

क्या कभी किसी यूज़र ने रिपोर्ट किया है कि “मेरा डेटा गायब हो गया” और आपको इसका कोई अंदाज़ा नहीं था कि क्यों? आमतौर पर इसका जवाब यही है: स्टोरेज अनंत नहीं है, और ब्राउज़र वह डेटा बेदखल कर देगा जिसे वह ज़रूरी नहीं समझता।

Chromium-आधारित ब्राउज़र आम तौर पर किसी ओरिजिन के स्टोरेज को कुल डिस्क स्पेस के एक प्रतिशत पर सीमित कर देते हैं — और विशेष सीमा इस बात पर निर्भर करती है कि उस ओरिजिन को “persistent” स्टोरेज दिया गया है या वह “best-effort” मोड में काम कर रहा है [15]। बेस्ट-एफर्ट मोड में, जब ब्राउज़र पर स्टोरेज का दबाव आता है, तो वह सबसे पहले सबसे कम हाल ही में इस्तेमाल किए गए ओरिजिन्स को बेदखल करना शुरू करता है — और किसी भी ऐसे ओरिजिन को छोड़ देता है जिसने navigator.storage.persist() को कॉल किया हो और उसे परसिस्टेंस मिल गया हो [15]।

आप navigator.storage.estimate() API के ज़रिए ठीक-ठीक देख सकते हैं कि आपका ऐप कहाँ खड़ा है, जो आपका वर्तमान usage और आपका quota दोनों लौटाता है — दोनों ही इस बात के आधार पर बदलते रहते हैं कि डिवाइस पर वाकई कितनी खाली डिस्क जगह है [16]। और DevTools में, Application → Storage का अवलोकन शाब्दिक रूप से आपको एक पाई चार्ट खींचकर दिखाता है कि आपके ओरिजिन का कोटा कुकीज़, IndexedDB, कैश स्टोरेज, इत्यादि में कैसे बंटा हुआ है [1] — साथ ही एक स्लाइडर भी जो छोटे कोटा का अनुकरण करता है, जो यह टेस्ट करने के लिए शानदार है कि असली यूज़र को उस दीवार से टकराने से पहले आपका ऐप तंग स्टोरेज में कैसा व्यवहार करता है।

व्यावहारिक डीबगिंग चेकलिस्ट जिसे मैं हमेशा अपनाता हूँ जब स्टोरेज अजीब व्यवहार करता है:

1. Application → Storage खोलें और उपयोग पाई चार्ट देखें — क्या किसी एक प्रकार का स्टोरेज अप्रत्याशित रूप से बहुत बड़ा है?
2. जांचें कि क्या ओरिजिन को परसिस्टेंस मिला है (navigator.storage.persisted()) — अगर नहीं, तो दबाव में बेदखली निष्पक्ष खेल है
3. कम-स्टोरेज स्थितियों का अनुकरण करने के लिए कोटा ओवरराइड स्लाइडर का इस्तेमाल करें और देखें क्या टूटता है
4. साफ शुरुआत के लिए Clear storage दबाएं, फिर समस्या को शुरू से दोहराएं
5. खासतौर पर सर्विस-वर्कर समस्याओं के लिए, Cache Storage और Service Workers को अलग-अलग जांचें — एक को साफ करने से दूसरा साफ नहीं होता [9]

तो मैं वाकई कौन सा चुनूँ?

यहाँ वह निर्णय फ्रेमवर्क है जिसका मैं वाकई इस्तेमाल करता हूँ जब किसी नए फीचर की शुरुआत करता हूँ जिसे क्लाइंट पर कुछ याद रखने की ज़रूरत है:

• क्या सर्वर को हर रिक्वेस्ट पर इसे पढ़ने की ज़रूरत है? → Cookie. कुछ और अपने आप नहीं भेजा जाता [2]।
• क्या यह छोटा है (कुछ KB), सरल की-वैल्यू है, और टैब से ज़्यादा टिकना चाहिए? → localStorage.
• क्या यह छोटा, सरल है, और टैब बंद होने पर मर जाना चाहिए? → sessionStorage.
• क्या यह स्ट्रक्चर्ड, बड़ा, बाइनरी है, या इसे क्वेरींग/इंडेक्सिंग की ज़रूरत है? → IndexedDB (शायद Dexie या idb में रैप किया हुआ)।
• क्या आप ऑफ़लाइन इस्तेमाल के लिए नेटवर्क रिस्पॉन्स कैश कर रहे हैं? → Cache Storage, सर्विस वर्कर द्वारा संचालित।
• क्या आपको असली फ़ाइल सिस्टम या ब्राउज़र-इन SQL डेटाबेस चाहिए? → OPFS, संभवतः SQLite-WASM के साथ जोड़ा हुआ [6][11]।
• क्या आप यूज़र की प्राइवेसी का उल्लंघन किए बिना क्रॉस-साइट मेज़रमेंट करने की कोशिश कर रहे हैं? → Shared Storage [13]।
• क्या आपके पास महत्वपूर्ण डेटा है जो स्टोरेज इवेक्शन से बचना चाहिए? → persisted: true के साथ Storage Buckets [14]।
• Chrome एक्सटेंशन बना या डीबग कर रहे हैं? → Extension Storage (chrome.storage.local / chrome.storage.sync) [17][18]।
• Privacy Sandbox के साथ एड-टेक काम कर रहे हैं? → Private State Tokens (एंटी-फ्रॉड सिग्नल) और Interest Groups (ऑन-डिवाइस विज्ञापन नीलामी) [19][20]।

वैसे, इनमें से कोई भी एक-दूसरे को बाहर नहीं करता — ज़्यादातर गंभीर वेब ऐप्स इनमें से कई को एक साथ इस्तेमाल करते हैं। एक PWA ऑथ के लिए कुकीज़, थीम प्रेफरेंस के लिए localStorage, ऑफ़लाइन कंटेंट के लिए IndexedDB, और ऐप शेल के लिए Cache Storage — सब एक साथ इस्तेमाल कर सकता है। Application पैनल वही टूल है जो आपको यह सब एक साथ, एक ही जगह पर, बिना एक भी डीबग console.log लिखे काम करते (या न करते) देखने देता है।

अगली बार जब कुछ “बस सेव नहीं हो रहा है”, तो अंदाज़े लगाना छोड़ें — DevTools खोलें, Application पर क्लिक करें, और वाकई देखें। दस में से नौ बार, जवाब बिल्कुल आपकी आंखों के सामने बैठा होता है।

स्रोत

1. Application panel overview | Chrome DevTools | Chrome for Developers
2. Browser Storage Explained: LocalStorage vs SessionStorage vs IndexedDB vs Cookies - DEV Community
3. Third-Party Cookie Deprecation Testing and Debugging - Chromium
4. Third-Party Cookie Deprecation: The 2026 Guide | Ethyca
5. 9 differences between IndexedDB and LocalStorage - DEV Community
6. Deprecating and removing Web SQL | Blog | Chrome for Developers
7. CacheStorage - Web APIs | MDN
8. Service workers and the Cache Storage API | Articles | web.dev
9. Debug Progressive Web Apps | Chrome DevTools | Chrome for Developers
10. Tips and Tricks for Debugging Service Workers
11. The origin private file system | Articles | web.dev
12. OPFS Explorer - Chrome DevTools extension - GitHub
13. Shared Storage overview | Privacy Sandbox | Chrome for Developers
14. Not all storage is created equal: introducing Storage Buckets | Blog | Chrome for Developers
15. Storage quotas and eviction criteria - Web APIs | MDN
16. Estimating Available Storage Space | Blog | Chrome for Developers
17. View and edit extension storage | Chrome DevTools | Chrome for Developers
18. chrome.storage API Reference | Chrome for Developers
19. Private State Tokens | Privacy Sandbox | Chrome for Developers
20. Protected Audience API overview | Privacy Sandbox | Chrome for Developers