व्यावहारिक

जेडब्ल्यूटी डिकोडर और एक्सपायरी कैलकुलेटर

जेडब्ल्यूटी डिकोडर और समाप्ति कैलकुलेटर

JWT टोकन (पूर्ण टोकन चिपकाएँ)

क्या है JWT Decoder & Expiry Calculator?

▾

JWT डिकोडर और एक्सपायरी कैलकुलेटर JSON वेब टोकन (JWT, RFC 7519 में परिभाषित) को पार्स करता है - आधुनिक वेब एपीआई में स्टेटलेस प्रमाणीकरण के लिए मानक टोकन प्रारूप। यह बेस64यूआरएल-एन्कोडेड हेडर और पेलोड को डिकोड करता है, JSON दावों को पार्स करता है, और समाप्ति (एक्सप), जारी-एट (आईएटी), नॉट-बिफोर (एनबीएफ), विषय (उप), जारीकर्ता (आईएसएस), और ऑडियंस (एयूडी) सहित समय-आधारित दावों का विश्लेषण करता है। JWT का उपयोग OAuth2/OIDC प्रदाताओं (Auth0, Okta, AWS Cognito, क्लर्क, Firebase Auth, Supabase) और अधिकांश आधुनिक सत्र प्रणालियों द्वारा किया जाता है। एक JWT में तीन बेस 64url-एन्कोडेड सेगमेंट होते हैं जो अवधियों से अलग होते हैं: हेडर.पेलोड.सिग्नेचर। हेडर हस्ताक्षर एल्गोरिथ्म की घोषणा करता है (HS256, RS256, ES256 सामान्य हैं)। पेलोड में 'दावे' शामिल हैं - दोनों मानक दावे (उप, ऍक्स्प, आईएटी, एनबीएफ, आईएसएस, एयूडी, जेटीआई) और कस्टम एप्लिकेशन-विशिष्ट डेटा। हस्ताक्षर क्रिप्टोग्राफ़िक रूप से हेडर और पेलोड को HMAC सीक्रेट (HS256) या असममित कुंजी जोड़ी (RS256/ES256) का उपयोग करके बांधता है। डिकोडर हेडर और पेलोड सामग्री दिखाता है लेकिन हस्ताक्षर को सत्यापित नहीं करता है - जिसके लिए गुप्त या सार्वजनिक कुंजी की आवश्यकता होती है और किसी भी JWT पर भरोसा करने से पहले हमेशा सर्वर-साइड किया जाना चाहिए। प्रमाणीकरण समस्याओं को डीबग करने, क्लाइंट और सर्वर के बीच कौन सा डेटा प्रवाहित होता है, यह समझने और टोकन ठीक से बने हैं इसकी पुष्टि करने के लिए JWT संरचना को समझना आवश्यक है। सामान्य डिबगिंग परिदृश्य: 'मेरा टोकन क्यों अस्वीकार कर दिया गया है?' (आमतौर पर समाप्त हो चुकी या गलत श्रोता), 'यह टोकन किस उपयोगकर्ता के लिए है?' (उप दावा जांचें), 'यह कब समाप्त होता है?' (exp दावा), और 'इस उपयोगकर्ता के पास क्या अनुमतियाँ हैं?' (कस्टम दावे जैसे भूमिकाएँ, दायरे या अनुमतियाँ)। यह कैलकुलेटर सबसे सामान्य विश्लेषणों को संभालता है: संरचना सत्यापन (3 भाग, वैध बेस64यूआरएल), जेएसओएन पार्सिंग, समाप्ति स्थिति (वैध, जल्द ही समाप्त हो रहा है <7 दिन, समाप्त), अभी तक वैध नहीं हैंडलिंग (भविष्य में एनबीएफ), और सभी मानक दावों के साथ-साथ पूर्ण हेडर और पेलोड जेएसओएन का मानव-पठनीय प्रदर्शन। हस्ताक्षर दिखाया गया है लेकिन सत्यापित नहीं है - उत्पादन सत्यापन को हमेशा सही सत्यापन कुंजी के साथ JWT लाइब्रेरी (jsonwebtoken, jose, PyJWT, आदि) का उपयोग करना चाहिए।

PrimeCalcPro provides professional-grade tools trusted by businesses and academics.

सूत्र

▾

f(x)

जेडब्ल्यूटी टोकन = बेस64यूआरएल(जेएसओएन हेडर) + '।' + बेस64यूआरएल(जेएसओएन पेलोड) + '।' + बेस64यूआरएल(हस्ताक्षर); मान्य यदि (exp > अभी) और (nbf <= अभी या nbf अपरिभाषित)

चर विवरण

▾

प्रतीक	नाम	इकाई	विवरण
header	हैडर	JSON	टोकन हेडर जिसमें एल्गोरिदम (एलजी) और टाइप (टाइप) शामिल है। एल्गोरिदम: HS256 (HMAC-SHA256), RS256 (RSA-SHA256), ES256 (ECDSA-P256-SHA256), PS256 (RSA-PSS-SHA256)। प्रकार आमतौर पर 'JWT' होता है लेकिन छोड़ा जा सकता है।
payload	पेलोड (दावा)	JSON	टोकन JSON ऑब्जेक्ट के रूप में दावा करता है। मानक दावे (उप, ऍक्स्प, आईएटी, एनबीएफ, आईएसएस, एयूडी, जेटीआई) आरएफसी 7519 का पालन करते हैं। कस्टम दावे एप्लिकेशन-विशिष्ट (उपयोगकर्ता_आईडी, भूमिकाएं, अनुमतियां, संगठन_आईडी) हैं।
exp	समाप्ति समय	Unix timestamp (seconds)	टोकन समाप्त होने पर यूनिक्स टाइमस्टैम्प। यदि वर्तमान समय >= व्यय हो तो टोकन अमान्य है। मानक अभ्यास: एक्सेस टोकन के लिए अल्पकालिक (15-60 मिनट), ताज़ा टोकन के लिए लंबे समय तक (दिन-सप्ताह)।
iat	पर जारी किया	Unix timestamp (seconds)	टोकन जारी होने पर यूनिक्स टाइमस्टैम्प। टोकन आयु पर नज़र रखने और रीप्ले हमलों का पता लगाने के लिए उपयोग किया जाता है (आईएटी द्वारा निरस्त टोकन के डेटाबेस के साथ तुलना करें)।
nbf	इससे पहले नही	Unix timestamp (seconds)	इस टाइमस्टैम्प से पहले टोकन अमान्य है। वैकल्पिक दावा. उन टोकन के लिए उपयोग किया जाता है जो भविष्य के समय से शुरू होने वाली पहुंच प्रदान करते हैं (उदाहरण के लिए, निर्धारित पहुंच)।
sub	विषय	string	टोकन किसके बारे में/किस बारे में है। आमतौर पर एक उपयोगकर्ता आईडी, ईमेल, या स्थिर पहचानकर्ता। जारीकर्ता के नामस्थान में अद्वितीय होना चाहिए।

कैसे JWT Decoder & Expiry Calculator

▾

1चरण 1 - अपना JWT टोकन चिपकाएँ: पूरा टोकन कॉपी करें (आमतौर पर 'eyJ' से शुरू होने वाली एक लंबी स्ट्रिंग क्योंकि 'eyJ' '{"' का बेस 64url एन्कोडिंग है जो JSON हेडर शुरू करता है)। टोकन आमतौर पर पेलोड आकार के आधार पर 100-2000+ वर्ण लंबे होते हैं।
2चरण 2 - टोकन संरचना सत्यापन: कैलकुलेटर टोकन को अवधियों पर विभाजित करता है। एक वैध JWT में बिल्कुल 3 भाग होते हैं: हेडर, पेलोड, हस्ताक्षर। यदि विभाजन से 3 भाग नहीं बनते हैं, तो टोकन विकृत है। सामान्य कारण: कॉपी-पेस्ट के दौरान काट-छांट, एपीआई प्रतिक्रियाओं में गायब भाग, या गैर-जेडब्ल्यूटी टोकन (कुछ एपीआई अपारदर्शी टोकन का उपयोग करते हैं जो जेडब्ल्यूटी नहीं हैं)।
3चरण 3 - बेस64यूआरएल डिकोडिंग: प्रत्येक भाग बेस64यूआरएल-डिकोडेड है। बेस64यूआरएल बेस64 का एक यूआरएल-सुरक्षित संस्करण है जो + और / के बजाय - और _ का उपयोग करता है और पैडिंग (=) को छोड़ देता है। आधुनिक ब्राउज़र का atob() फ़ंक्शन बेस64 को संभालता है लेकिन रूपांतरण की आवश्यकता है: - → +, _ → /, पैडिंग जोड़ें। यदि डिकोडिंग विफल हो जाती है, तो टोकन दूषित हो जाता है।
4चरण 4 - JSON पार्सिंग: डिकोडेड हेडर और पेलोड वैध JSON ऑब्जेक्ट होने चाहिए। यदि JSON.parse विफल हो जाता है, तो टोकन की सामग्री दूषित हो जाती है या यह मानक JWT नहीं है। कुछ लीगेसी सिस्टम बाइनरी या गैर-JSON सामग्री के साथ 'JWT-जैसे' प्रारूप का उपयोग करते हैं जो यहां डिकोड नहीं होंगे।
5चरण 5 - दावा निष्कर्षण और विश्लेषण: कैलकुलेटर मानक दावे (एक्सप, आईएटी, एनबीएफ, सब, आईएसएस, एयूडी) निकालता है और उन्हें मानव-पठनीय रूप में प्रदर्शित करता है। exp और iat को यूनिक्स टाइमस्टैम्प से तारीखों में परिवर्तित किया जाता है। निरीक्षण के लिए कस्टम दावे पूर्ण पेलोड JSON में दिखाए जाते हैं।
6चरण 6 - समाप्ति स्थिति की गणना: व्यय दावे की तुलना में वर्तमान समय (अभी)। स्थिति श्रेणियाँ: वैध (अब समाप्त हो रहा है + 7 दिन), जल्द ही समाप्त हो रहा है (अब समाप्त हो रहा है लेकिन <7 दिन), समाप्त हो रहा है (अब समाप्त हो रहा है, कुछ दिन पहले पता चलता है), अभी मान्य नहीं है (एनबीएफ > अभी, टोकन भविष्य में उपयोग के लिए है)। संदर्भ के लिए शेष दिन दिखाए गए हैं।
7चरण 7 - हस्ताक्षर प्रदर्शन (सत्यापित नहीं): तीसरा खंड (हस्ताक्षर) दिखाया गया है लेकिन इस उपकरण द्वारा कभी सत्यापित नहीं किया गया है। सत्यापन के लिए गुप्त (HMAC एल्गोरिदम के लिए) या सार्वजनिक कुंजी (असममित एल्गोरिदम के लिए) की आवश्यकता होती है और इसे उचित JWT लाइब्रेरी का उपयोग करके सर्वर-साइड किया जाना चाहिए। उत्पादन कोड में असत्यापित JWT सामग्री पर कभी भरोसा न करें।

हल किए गए उदाहरण

▾

उदाहरण 1OAuth2 प्रदाता से मानक मान्य JWT

दिया गया:exp=1709999999, iat=1516239022, उप='1234567890', alg='HS256' वाला टोकन

परिणाम:वैध, एचएस256, विषय 1234567890, 9 मार्च 2024 को समाप्त हो रहा है

विशिष्ट अल्पकालिक एक्सेस टोकन सफलतापूर्वक डिकोड किया गया

यह मानक JWT.io उदाहरण टोकन है। हेडर HS256 एल्गोरिथम और JWT प्रकार की घोषणा करता है। पेलोड में उपयोगकर्ता की जानकारी (उप, नाम) और समय (आईएटी, एक्सपी) है। स्थिति व्यय के सापेक्ष वर्तमान तिथि पर निर्भर करेगी। दिखाया गया हस्ताक्षर एक प्लेसहोल्डर है - वास्तविक टोकन में वैध HMAC हस्ताक्षर होते हैं जिनकी गणना जारीकर्ता के रहस्य के साथ की जाती है।

उदाहरण 2समाप्त टोकन

दिया गया:अतीत में exp के साथ टोकन (उदाहरण के लिए, पिछले महीने)

परिणाम:समाप्त स्थिति, समाप्ति के बाद से दिन दिखाए गए, समाप्त = सत्य है

सामान्य डिबगिंग परिदृश्य - समाप्ति तिथि बीत जाने के कारण टोकन अस्वीकृत कर दिया गया

वैध दिखने वाले टोकन के साथ अधिकांश प्रमाणीकरण विफलताएँ केवल समाप्ति हैं। कैलकुलेटर बिल्कुल दिखाता है कि समाप्ति कितने दिन पहले हुई है। ठीक करने के लिए: रिफ्रेश_टोकन एंडपॉइंट (OAuth2) का उपयोग करके टोकन को रीफ्रेश करें या पुनः प्रमाणित करें। दौड़ की स्थिति से बचने के लिए प्रोडक्शन कोड को एक्सप से 5-10 मिनट पहले एक्सेस टोकन को स्वचालित रूप से रीफ्रेश करना चाहिए।

उदाहरण 3विकृत टोकन त्रुटि

दिया गया:टोकन में हस्ताक्षर भाग गायब है (केवल 2 खंड)

परिणाम:त्रुटि - अमान्य JWT प्रारूप (अवधि द्वारा अलग किए गए 3 भाग होने चाहिए)

आगे की प्रक्रिया से पहले काटे गए या गैर-जेडब्ल्यूटी टोकन पकड़ता है

अपूर्ण रूप से कॉपी किए गए टोकन या एपीआई से जो गैर-जेडब्ल्यूटी प्रारूप (अपारदर्शी टोकन, सादे जेडब्ल्यूई एन्क्रिप्टेड ब्लॉब्स) लौटाते हैं, सत्यापन विफल हो जाएगा। कैलकुलेटर का त्रुटि संदेश उपयोगकर्ताओं को टोकन अखंडता की जांच करने के लिए मार्गदर्शन करता है। सामान्य कारण: कॉपी के दौरान लाइन रैपिंग, एपीआई से आंशिक प्रतिक्रिया, या अपारदर्शी OAuth टोकन (कुछ Microsoft एंडपॉइंट) का उपयोग करना जो JWT नहीं हैं।

उदाहरण 4भविष्य में एनबीएफ के साथ टोकन (अनुसूचित पहुंच)

दिया गया:nbf के साथ टोकन = निर्धारित सक्षम करने के लिए भविष्य की तारीख

परिणाम:अभी तक वैध स्थिति नहीं - एनबीएफ़ तक टोकन का उपयोग नहीं किया जा सकता

समय-विलंबित प्राधिकरण के लिए दुर्लभ उपयोग का मामला

कुछ प्रणालियाँ टोकन जारी करती हैं जो भविष्य के समय में मान्य हो जाते हैं (उदाहरण के लिए, निर्धारित मीटिंग एक्सेस, समय-लॉक सामग्री)। एनबीएफ (पहले नहीं) समय से पहले उपयोग को रोकता है। अधिकांश जेडब्ल्यूटी पुस्तकालय एनबीएफ का सम्मान करते हैं और इस समय से पहले टोकन को अस्वीकार कर देते हैं। यदि आप यह स्थिति देखते हैं, तो टोकन टूटा नहीं है - यह जानबूझकर अभी तक मान्य नहीं है।

वास्तविक अनुप्रयोग

▾

🏗️

टोकन दावों और समाप्ति समय का निरीक्षण करके प्रमाणीकरण मुद्दों को डीबग करना

🔬

Auth0, Okta, AWS Cognito, या क्लर्क जैसे प्रदाताओं के साथ एकीकरण के दौरान OAuth2/OIDC टोकन का सत्यापन करना

📊

यह समझना कि तृतीय-पक्ष एपीआई से प्राप्त टोकन में कौन सा उपयोगकर्ता डेटा एन्कोड किया गया है

🏥

समर्थन उद्देश्यों के लिए उपयोगकर्ता सत्र टोकन का निरीक्षण करने के लिए आवश्यक व्यवस्थापक उपकरण बनाना

⚙️

इंजीनियरिंग साक्षात्कार और सुरक्षा ऑडिट के लिए JWT संरचना सीखना

मानक जेडब्ल्यूटी दावे (आरएफसी 7519)

▾

दावा	नाम	आवश्यक	उद्देश्य
iss	जारीकर्ता	वैकल्पिक	टोकन किसने जारी किया (जैसे, पहचान प्रदाता यूआरएल)
sub	विषय	वैकल्पिक	टोकन किसके बारे में है (आमतौर पर उपयोगकर्ता आईडी)
aud	श्रोता	वैकल्पिक	टोकन किसे स्वीकार करना चाहिए (आपका एपीआई)
exp	समय सीमा समाप्ति	अनुशंसित	जब टोकन अमान्य हो जाता है
nbf	इससे पहले नही	वैकल्पिक	जब टोकन वैध हो जाता है (भविष्य का शेड्यूल)
iat	पर जारी किया	अनुशंसित	जब टोकन बनाया गया था
jti	जेडब्ल्यूटी आईडी	वैकल्पिक	टोकन के लिए विशिष्ट पहचानकर्ता (रीप्ले रोकथाम के लिए)

अक्सर पूछे जाने वाले प्रश्न

▾

क्या JWT डिकोडिंग सत्यापन के समान है?

नहीं, डिकोडिंग उस सामग्री को निकालती है जिसे कोई भी पढ़ सकता है - हेडर और पेलोड केवल बेस 64url एन्कोडेड हैं, एन्क्रिप्टेड नहीं। सत्यापन क्रिप्टोग्राफ़िक रूप से गुप्त (एचएमएसी एल्गोरिदम) या सार्वजनिक कुंजी (आरएसए/ईसीडीएसए एल्गोरिदम) का उपयोग करके हस्ताक्षर की जांच करता है ताकि यह पुष्टि हो सके कि टोकन के साथ छेड़छाड़ नहीं की गई थी। उत्पादन में टोकन सामग्री पर भरोसा करने से पहले हमेशा सत्यापित करें। इस टूल जैसे डिकोडर डिबगिंग के लिए हैं, प्रमाणीकरण के लिए नहीं।

मुझे ब्राउज़र ऐप्स में JWTs कहाँ संग्रहीत करना चाहिए?

httpकेवल सुरक्षित कुकीज़ का उपयोग करें, लोकलस्टोरेज या सेशनस्टोरेज का नहीं। लोकलस्टोरेज XSS के प्रति संवेदनशील है - कोई भी इंजेक्टेड स्क्रिप्ट सभी संग्रहीत टोकन को पढ़ सकती है और उन्हें बाहर निकाल सकती है। httpOnly कुकीज़ जावास्क्रिप्ट तक पहुंच योग्य नहीं हैं और सेमसाइट=स्ट्रिक्ट या सेमसाइट=लैक्स पर सेट होने पर अंतर्निहित सीएसआरएफ सुरक्षा प्रदान करती हैं। मोबाइल ऐप्स के लिए, प्लेटफ़ॉर्म सुरक्षित स्टोरेज (आईओएस किचेन, एंड्रॉइड कीस्टोर) का उपयोग करें।

JWT की समाप्ति कब तक होनी चाहिए?

अल्पकालिक एक्सेस टोकन (15-60 मिनट) को लंबे समय तक ताज़ा टोकन (दिनों से सप्ताहों) के साथ जोड़ा जाता है। उन टोकन से बचें जो समाप्त नहीं होते हैं - एक बार जारी होने के बाद, उन्हें ब्लैकलिस्ट बनाए रखने के बिना रद्द नहीं किया जा सकता है (जो जेडब्ल्यूटी के स्टेटलेस लाभ को खत्म कर देता है)। सामान्य पैटर्न: वेब ऐप्स के लिए 15-मिनट की पहुंच + 30-दिन का रिफ्रेश; मोबाइल ऐप्स के लिए 1 घंटे की पहुंच + 90 दिन का रिफ्रेश; उच्च-सुरक्षा अनुप्रयोगों के लिए 5-मिनट की पहुंच + टोकन रोटेशन।

JWT और OAuth2 के बीच क्या अंतर है?

OAuth2 एक प्राधिकरण प्रोटोकॉल है (ग्राहकों को अनुमति कैसे मिलती है); JWT एक टोकन प्रारूप है. OAuth2 JWTs को एक्सेस टोकन (आजकल सबसे आम) या अपारदर्शी टोकन (Microsoft के पुराने प्रवाह) के रूप में उपयोग कर सकता है। JWTs OAuth2 के बाहर भी काम करते हैं - प्रत्यक्ष एपीआई प्रमाणीकरण, मैजिक लिंक, पासवर्ड रीसेट टोकन के लिए। वे पूरक प्रौद्योगिकियाँ हैं, प्रतिस्पर्धी नहीं।

क्या मुझे HS256 या RS256 का उपयोग करना चाहिए?

वितरित प्रणालियों के लिए आरएस256 (असममित आरएसए) जहां कई सेवाएं टोकन सत्यापित करती हैं - उनमें से प्रत्येक के पास सार्वजनिक कुंजी हो सकती है, केवल जारीकर्ता को निजी कुंजी की आवश्यकता होती है। एकल-सेवा अनुप्रयोगों के लिए HS256 (सममित HMAC) जहां एक ही सेवा जारी और सत्यापित होती है - सरल कुंजी प्रबंधन। अधिकांश पहचान प्रदाता डिफ़ॉल्ट रूप से RS256 का उपयोग करते हैं। एल्गोरिथम का चुनाव आपकी सुरक्षा स्थिति का हिस्सा है।

अधिकतम JWT आकार क्या है?

तकनीकी रूप से असीमित, लेकिन व्यावहारिक सीमाएँ लागू होती हैं। HTTP हेडर सीमा (आमतौर पर कुल 8KB) प्राधिकरण हेडर के माध्यम से भेजे गए टोकन को बाधित करती है। कुकी आकार सीमा (~4KB प्रति कुकी) भंडारण को बाधित करती है। अधिकांश उत्पादन JWTs 500-2000 वर्णों के होते हैं। यदि आपका JWT 4KB से अधिक है, तो आपके पास बहुत सारे कस्टम दावे हैं - इसके बजाय केवल उप का उपयोग करके डेटाबेस से उपयोगकर्ता विवरण प्राप्त करने पर विचार करें।

सामान्य गलतियां जिनसे बचना है

▾

!सत्यापन के साथ डिकोड करना भ्रमित करने वाला है - यह उपकरण केवल डिकोड करता है; हस्ताक्षर सत्यापन के लिए क्रिप्टोग्राफ़िक कुंजी की आवश्यकता होती है और इसे JWT लाइब्रेरी के साथ सर्वर-साइड किया जाना चाहिए।
!सुरक्षा निर्णयों में असत्यापित JWT सामग्री पर भरोसा करना - कोई भी वैध दिखने वाला टोकन बना सकता है; सत्यापन के बिना कभी भी अधिकृत न करें.
!संवेदनशील डेटा के साथ JWTs को लोकलस्टोरेज में संग्रहीत करना - XSS हमलों के प्रति संवेदनशील; उत्पादन ब्राउज़र ऐप्स के लिए httpOnly सुरक्षित कुकीज़ का उपयोग करें।
!घड़ी की विषमता को संभालना भूल जाना - वितरित सर्वरों के बीच exp/nbf तुलना पर 30-60 सेकंड की सहनशीलता की अनुमति दें।
!रोटेशन के बिना लंबे समय तक चलने वाले जेडब्ल्यूटी का उपयोग करना - एक बार जारी होने के बाद, जेडब्ल्यूटी को आसानी से रद्द नहीं किया जा सकता है; अल्पकालिक पहुंच का उपयोग करें + टोकन रोटेशन पैटर्न को ताज़ा करें।

💡

विशेष टिप

उत्पादन में रीफ्रेश टोकन रोटेशन का उपयोग करें - प्रत्येक रीफ्रेश एक नई जोड़ी जारी करता है और पुराने को अमान्य कर देता है। यदि ताज़ा टोकन चोरी हो जाता है तो यह ब्लास्ट त्रिज्या को सीमित कर देता है और जब चोरी हुआ पुराना टोकन रोटेशन के बाद उपयोग करने का प्रयास करता है तो टोकन चोरी का पता लगाता है। प्रमुख प्रदाता (Auth0, Okta, Cognito) इस पैटर्न का समर्थन करते हैं।

⭐

क्या आप जानते हैं?

JWT विनिर्देश (RFC 7519) को कई वर्षों के मसौदा संशोधनों के बाद मई 2015 में अंतिम रूप दिया गया था। यह माइक्रोसॉफ्ट में SWT (सिंपल वेब टोकन) और IETF में JOSE (JSON ऑब्जेक्ट साइनिंग और एन्क्रिप्शन) सहित पहले के प्रयासों से विकसित हुआ। 'eyJ' उपसर्ग जो लगभग हर JWT से शुरू होता है, वह '{"' का बेस 64url एन्कोडिंग है - किसी भी JSON ऑब्जेक्ट का उद्घाटन। यह पैटर्न JWT को एक नज़र में पहचानने योग्य बनाता है।

संदर्भ

📖कठिनाई:मध्यम

Mathematically verified

Reviewed October 2026

Our methodology

साप्ताहिक गणित युक्तियाँ प्राप्त करें

12,000+ सब्सक्राइबर्स से जुड़ें जिन्हें हर हफ्ते कैलकुलेटर टिप्स मिलते हैं।

🔒

100% मुफ़्त

कोई साइनअप नहीं

✓

सटीक

सत्यापित सूत्र

⚡

तत्काल

तुरंत परिणाम

📱

मोबाइल अनुकूल

सभी उपकरण