कुकी पार्सर

Set-Cookie हेडर और document.cookie स्ट्रिंग को संरचित डेटा में पार्स करें। अधिकतम सुरक्षा और गोपनीयता के लिए सारी प्रोसेसिंग आपके ब्राउज़र में ही होती है।

एकाधिक प्रारूप सुरक्षा फ़्लैग कुकी आँकड़े

वैल्यू दृश्य (स्पष्ट, वैकल्पिक)

मूल वैल्यू हमेशा बनी रहती है। डिकोडिंग एक बार, और केवल चुने गए दृश्य में ही लागू होती है। URL डिकोडिंग + को वैसा ही रखती है; Base64 को UTF-8 टेक्स्ट चाहिए। यह हस्ताक्षरित या एन्क्रिप्टेड टोकन को डिक्रिप्ट नहीं करता। HttpOnly कुकीज़ ब्राउज़र का JavaScript नहीं पढ़ सकता; केवल वही हेडर चिपकाएँ जिन्हें देखने की आपको अनुमति है।

कुकी डेटा

कुल कुकी

सिक्योर कुकी

HttpOnly कुकी

पार्स की गई कुकी

नाम	वैल्यू	डोमेन	पाथ	समाप्ति	Max-Age	फ़्लैग

कुकी पार्सर का उपयोग कैसे करें

मोड चुनें

HTTP हेडर के लिए Set-Cookie हेडर मोड या ब्राउज़र कुकी स्ट्रिंग के लिए document.cookie मोड चुनें

डेटा पेस्ट करें

अपने Set-Cookie हेडर (प्रति पंक्ति एक) या document.cookie स्ट्रिंग इनपुट फ़ील्ड में पेस्ट करें

परिणाम देखें

सुरक्षा फ़्लैग के आँकड़ों के साथ संरचित तालिका में पार्स की गई कुकी देखें

HTTP कुकी क्या हैं?

HTTP कुकी छोटे डेटा टुकड़े हैं जिन्हें ब्राउज़र वेबसाइटों की ओर से संग्रहीत करता है। ये Set-Cookie HTTP रिस्पॉन्स हेडर से भेजी जाती हैं और बाद के अनुरोधों में Cookie हेडर से जुड़ जाती हैं। कुकी का उपयोग सेशन प्रबंधन, पर्सनलाइज़ेशन और ट्रैकिंग के लिए होता है। HttpOnly, Secure और SameSite जैसे सुरक्षा फ़्लैग कुकी को क्रॉस-साइट स्क्रिप्टिंग (XSS) और क्रॉस-साइट रिक्वेस्ट फ़ॉर्जरी (CSRF) हमलों से बचाने में मदद करते हैं।

HttpOnly

क्लाइंट-साइड स्क्रिप्ट को कुकी एक्सेस करने से रोकता है, XSS हमले कम करता है

Secure

सुनिश्चित करता है कि कुकी केवल HTTPS कनेक्शन पर ही भेजी जाए

SameSite

क्रॉस-साइट कुकी भेजने को नियंत्रित करता है: CSRF हमलों से बचाव के लिए Strict, Lax या None

सामान्य प्रश्न

कौन से कुकी प्रारूप समर्थित हैं?

टूल Set-Cookie HTTP हेडर और document.cookie JavaScript स्ट्रिंग पार्स करता है। एक साथ कई कुकी पार्स की जा सकती हैं।

क्या यह सुरक्षा फ़्लैग दिखाता है?

हाँ। हर कुकी के लिए HttpOnly, Secure, SameSite (Strict/Lax/None), Path और Domain एट्रिब्यूट दिखाए जाते हैं।

क्या एक साथ कई कुकी पार्स कर सकता हूँ?

हाँ। Set-Cookie मोड में प्रति पंक्ति एक हेडर पेस्ट करें। document.cookie मोड में स्ट्रिंग की सभी कुकी पार्स होती हैं।

SameSite एट्रिब्यूट के मानों का क्या अर्थ है?

SameSite=Strict कुकी केवल उसी साइट के नेविगेशन पर भेजता है - पूरी CSRF सुरक्षा, लेकिन बाहर से आने वाले लिंक पर कुकी नहीं जाती। Lax (ब्राउज़र डिफ़ॉल्ट) टॉप-लेवल GET नेविगेशन को कुकी ले जाने देता है, जिससे बाहरी लिंक से लॉगिन सेशन चलते रहते हैं और अधिकांश CSRF रुकते हैं। None प्रतिबंध हटा देता है लेकिन Secure ज़रूरी है, वरना ब्राउज़र अस्वीकार कर देता है - क्रॉस-साइट iframe और पेमेंट फ़्लो को यही कॉम्बिनेशन चाहिए।

सेशन और पर्सिस्टेंट कुकी में क्या अंतर है?

Expires या Max-Age रहित कुकी सेशन कुकी है: वह केवल मेमोरी में रहती है और ब्राउज़र सेशन के साथ गायब हो जाती है (हालाँकि आधुनिक ब्राउज़र क्रैश के बाद पुनर्स्थापित कर सकते हैं)। Expires पूर्ण समयसीमा तय करता है, Max-Age सेकंड में सापेक्ष; दोनों हों तो Max-Age जीतता है। remember-me लॉगिन और लंबी जीवन वाली एनालिटिक्स ID रीस्टार्ट से बचती हैं पर्सिस्टेंट कुकी की वजह से ही।

__Secure- और __Host- कुकी प्रीफ़िक्स क्या करते हैं?

ये नाम-स्तर की गारंटियाँ हैं जिन्हें ब्राउज़र लागू करता है। __Secure- के लिए https ओरिजिन और Secure एट्रिब्यूट चाहिए। __Host- और सख़्त है: Secure, कोई Domain एट्रिब्यूट नहीं (host-only), और Path=/ - इसलिए __Host- युक्त कुकी को कोई सबडोमेन ओवरराइट नहीं कर सकता, जो उसे उसी साइट पर पिन करता है। असमर्थित ब्राउज़र इन प्रीफ़िक्स को साधारण नाम-अक्षर मानते हैं।

कुकी कितनी बड़ी हो सकती है, और प्रति डोमेन कितनी रखी जा सकती हैं?

RFC 6265 के अनुसार ब्राउज़रों को प्रति कुकी कम से कम 4096 बाइट और प्रति डोमेन कम से कम 50 कुकी स्वीकार करनी हैं। Chrome लगभग 180 कुकी/डोमेन और कुल कुछ हज़ार तक रखता है; Safari व्यवहार में सख़्त है। कुकी डोमेन के हर अनुरोध के साथ जाती है, इसलिए भारी कुकी स्टोरेज ट्रैफ़िक धीमा करता है - इसीलिए बड़ी साइटें स्टेट localStorage या सर्वर-साइड सेशन में खिसकाती हैं।

HttpOnly और Secure कुकी की रक्षा कैसे करते हैं?

HttpOnly कुकी को JavaScript के document.cookie से छुपाता है, ताकि इंजेक्ट किए गए XSS स्क्रिप्ट उसे पढ़ न सकें - इसे हमेशा सेशन कुकी पर लगाएँ। Secure ट्रांसमिशन केवल HTTPS कनेक्शन तक सीमित रखता है, जिससे प्लेन HTTP पर रिसाव रुकता है। दोनों में से कोई कुकी को एन्क्रिप्ट नहीं करता; दोनों Set-Cookie हेडर में एक-पंक्ति की हार्डनिंग हैं।

प्रामाणिक संदर्भ

इस टूल के पीछे के मूल स्रोत — दूसरे हाथ के सार नहीं, बल्कि आधिकारिक स्टैंडर्ड और स्पेसिफिकेशन।

RFC 6265 - HTTP State Management Mechanism

कुकीज़ और उनके एट्रिब्यूट परिभाषित करने वाला IETF HTTP State Management Mechanism मानक।

MDN Web Docs - Set-Cookie

Set-Cookie हेडर का Mozilla संदर्भ: एट्रिब्यूट, प्रीफ़िक्स और सुरक्षा फ़्लैग।

HTTP cookie - Wikipedia

HTTP कुकीज़ स्टेट कैसे ले जाती हैं: सेशन, एट्रिब्यूट और same-site नियम।