logo
GeekFormat

JWT टूल

Encoded Token172 chars2026-07 में अपडेट किया गया
header
payload
signature
Valid JWTHS256
Secret38 chars
Header
{
  "alg": "HS256",
  "typ": "JWT"
}
Payload
{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iat": 1516239022
}
Claims details4 items
sub· विषय1234567890
name· NameJohn Doe
admin· Admintrue
iat· जारी किया गया151623902218/01/2018, 09:30:22
Header details2 items
algHS256HMAC (सममित)
typ· TypeJWT
All operations run locally in your browser; the Token and key are never sent to any server.

JWT Token डिकोड, वेरिफाई और जनरेट ऑनलाइन करें। Header, Payload और सिग्नेचर इन्फॉर्मेशन व्यू करें, API ऑथेंटिकेशन डिबगिंग के लिए आदर्श।

संबंधित सुझाव

JWT HS256 साइनिंग के लिए HMAC-SHA256 Secret जनरेट करें

JWT HS256 HMAC प्लस Base64URL है — पहले HMAC सीखें, फिर JWT

वह Base64URL एन्कोडिंग समझें जो JWT आंतरिक रूप से उपयोग करता है

JWT का Header, Payload और Signature सभी Base64URL-एन्कोडेड हैं

तीन JWT सेगमेंट्स में से प्रत्येक को Base64URL में डिकोड करें

JWT को विभाजित करने के बाद, प्लेन-टेक्स्ट पढ़ने के लिए सेगमेंट्स को Base64URL में डिकोड करें

Payload को एन्क्रिप्ट करने की आवश्यकता होने पर JWE या AES का उपयोग करें

JWT Payload डिफॉल्ट रूप से प्लेन-टेक्स्ट होता है; संवेदनशील payload को JWE / AES का उपयोग करना चाहिए

वह SHA-256 हैश समझें जिस पर HS256 बना है

HS256 HMAC प्लस SHA-256 है — पहले SHA-256 समझें

अभी-अभी जनरेट किए गए JWT के साथ अपने API को सीधे हिट करें

JWT को डिबग करने के बाद, API को टेस्ट करने के लिए इसे Authorization: Bearer में पेस्ट करें

Regex टेस्टर

उपयोग के मामले

  • JWT को ऑनलाइन डिकोड करें: OAuth 2.0 / OIDC लॉगिन डिबगिंग के दौरान टोकन को तेजी से अलग करके Header एल्गोरिदम और Payload Claims की जाँच करें
  • JWT सिग्नेचर वेरिफाई करें: रियल-टाइम में टोकन सिग्नेचर वेरिफाई करने के लिए Secret / पब्लिक की का उपयोग करें और तय करें कि 401 'बैड सिग्नेचर', 'एक्सपायर्ड' या 'एल्गोरिदम मिसमैच' है
  • इंटीग्रेशन के दौरान टेस्ट JWT जनरेट करें: टोकन जारी करने के लिए बैकएंड को अस्थायी रूप से कोड बदलने की जरूरत के बिना, ब्राउज़र में टेस्ट की-पेयर के साथ JWT जारी करें
  • PEM ↔ JWK कन्वर्जन: OIDC IdP ने आपको JWK दिया लेकिन सर्वर को PEM चाहिए (या इसके विपरीत) — OpenSSL स्क्रिप्ट लिखने के बजाय जगह पर कन्वर्ट करें
  • 401 Unauthorized को डायगनोज करें: एक्सपायरी, alg-गेटवे मैच, की मैच और PEM फॉर्मेटिंग को स्टेप-बाय-स्टेप चेक करें
  • RS256 बनाम PS256 की तुलना करें: कई OIDC प्रोवाइडर डिफॉल्ट रूप से RS256 का उपयोग करते हैं जबकि AWS SigV4 PS256 को प्राथमिकता देता है — उसी RSA की-पेयर के साथ एल्गोरिदम स्विच करें और नतीजों की तुलना करें
  • JWT के आंतरिक कामकाज को सीखें: alg बदलें, Payload एडिट करें, ब्राउज़र में की बदलें और देखें कि सिग्नेचर रियल-टाइम में कैसे टूटता है — RFC पढ़ने से बहुत तेज

विशेषताएं

  • एक ही जगह पर डिकोड + वेरिफाई + जनरेट: टोकन पेस्ट करके Header/Payload/Signature अलग करें, सिग्नेचर वेरिफाई करने के लिए एल्गोरिदम और की बदलें, नया टोकन बनाने के लिए Claims एडिट करके फिर से साइन करें — पूरे JWT ट्रबलशूटिंग चेन को कवर करता है
  • सभी 13 एल्गोरिदम सपोर्टेड: HS256/HS384/HS512 (HMAC), RS256/RS384/RS512 (RSA-PKCS1-v1_5), ES256/ES384/ES512 (ECDSA), PS256/PS384/PS512 (RSA-PSS), EdDSA — OAuth 2.0, OIDC, JWS, API गेटवे और एंटरप्राइज SSO को कवर करता है
  • PEM और JWK फॉर्मेट: RSA, ECDSA और Ed25519 कीज PEM स्ट्रिंग्स (-----BEGIN PUBLIC KEY----- हेडर्स के साथ) और JWK JSON (kid/kty/n/e फील्ड्स) स्वीकार करती हैं — OIDC /.well-known/jwks.json आउटपुट सीधे पेस्ट करें
  • HMAC Secret की कई इनपुट फॉर्म्स: कच्ची UTF-8 स्ट्रिंग, हेक्स बाइट्स या Base64/Base64URL एन्कोडेड — एक क्लिक में स्विच करें, ताकि 'दिखने में एक जैसा है लेकिन सिग्नेचर फेल हो जाता है' कभी न हो
  • ऑटोमेटिक की-पेयर जनरेशन: RSA-2048, RSA-4096, P-256, P-384 और Ed25519 की-पेयर ब्राउज़र में जनरेट होती हैं, तुरंत टेस्ट यूज़ के लिए PEM और JWK फॉर्मेट में प्रस्तुत की जाती हैं
  • Claims की सेमेंटिक हाइलाइटिंग: exp / iat / nbf स्वचालित रूप से पढ़ने योग्य समय में कन्वर्ट होते हैं, एक्सपायर्ड / अभी-अमान्य / जारी किया गया स्टेटस हाइलाइट के साथ; Header में alg / typ / kid अलग-अलग लेबल किए जाते हैं
  • 100% क्लाइंट-साइड, जीरो अपलोड: हर पार्स, वेरिफाई और साइन ब्राउज़र के नेटिव Web Crypto API के जरिए चलता है — टोकन, कीज और payload कभी ब्राउज़र नहीं छोड़ते, 'प्रोडक्शन टोकन को कभी भी रैंडम ऑनलाइन टूल्स में पेस्ट न करें' सुरक्षा सिद्धांत का पालन करते हुए
  • वन-क्लिक कॉपी: Header, Payload, Signature और नया जनरेट किया गया टोकन स्वतंत्र रूप से कॉपी करने योग्य हैं; डॉक्यूमेंटेशन, टिकट और curl कमांड्स के लिए

उपयोग कैसे करें

  1. टोकन पेस्ट करें या टाइप करें: JWT स्ट्रिंग को इनपुट फील्ड में रखें; टूल स्वचालित रूप से Header, Payload और Signature को अलग करता है और प्रत्येक को फॉर्मेट किए गए JSON के रूप में प्रदर्शित करता है
  2. एल्गोरिदम चुनें: HS256 / RS256 / ES256 / PS256 / EdDSA के बीच स्विच करें; टूल Header.alg से अनुमान लगाता है और किसी भी मिसमैच को फ्लैग करता है
  3. एक की इम्पोर्ट करें: HMAC Secret, PEM स्ट्रिंग या JWK JSON पेस्ट करें; असममित एल्गोरिदम के लिए, तुरंत टेस्ट की पाने के लिए 'की-पेयर जनरेट' पर क्लिक करें
  4. वेरिफाई करें या फिर से साइन करें: Decode मोड में, पब्लिक की से वेरिफाई करें और '✅ सिग्नेचर वैध / ❌ सिग्नेचर अमान्य' देखें; Encode मोड में, Claims एडिट करें और नया टोकन बनाने के लिए प्राइवेट की से साइन करें

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

JWT के तीन हिस्से क्या हैं?

JWT स्ट्रिंग `Header.Payload.Signature` रूप में होती है, प्रत्येक सेगमेंट Base64URL-एन्कोडेड होता है। Header एल्गोरिदम (जैसे HS256, RS256) और टोकन प्रकार (typ: JWT) को घोषित करता है; Payload उपयोगकर्ता Claims (घोषणाएं) ले जाता है, आम फील्ड्स हैं sub (उपयोगकर्ता ID), iat (जारी करने का समय), exp (समाप्ति समय), nbf (not-before), aud (दर्शक), iss (जारीकर्ता); Signature पहले दो सेगमेंट्स को की के साथ साइन करने का परिणाम है, उद्देश्य 'टैम्परिंग डिटेक्शन' है 'लीक-प्रिवेंशन' नहीं।

क्या मैं डिकोड करने के बाद Payload एडिट कर सकता हूं?

आप देख और एडिट कर सकते हैं, लेकिन **फर्जी नहीं बना सकते**। जैसे ही आप Header या Payload बदलते हैं, मूल Signature अमान्य हो जाता है और सर्वर वेरिफिकेशन को अस्वीकार कर देता है। संशोधित टोकन को फिर से वैध बनाने के लिए, आपको उसी एल्गोरिदम और उसी की के साथ **फिर से साइन** करना होगा — यही कारण है कि यह टूल एक ही जगह पर 'डिकोड + एडिट + जनरेट' प्रदान करता है: देखने के लिए डिकोड करें, बदलें और तुरंत टेस्ट के लिए नया टोकन जनरेट करें, ताकि आपको हर बार बैकएंड से टोकन जारी करने के लिए कोड अस्थायी रूप से बदलने का अनुरोध न करना पड़े।

HS256, RS256, ES256, PS256 और EdDSA में क्या अंतर है?

HS256 साझा Secret के साथ HMAC का उपयोग करता है (सममित), तेज लेकिन secret प्रबंधन महत्वपूर्ण है। RS256 RSA प्राइवेट/पब्लिक कीज का उपयोग करता है (असममित), जारीकर्ता प्राइवेट के साथ साइन करता है, वेरिफायर पब्लिक का उपयोग करता है। ES256 एलिप्टिक कर्व ECDSA का उपयोग करता है (P-256), छोटा सिग्नेचर। PS256 RSA-PSS का उपयोग करता है, RS256 से अधिक सुरक्षित। EdDSA (आमतौर पर Ed25519) तेज और नियतिवादी है, OAuth 2.1 के लिए अनुशंसित।

मेरा JWT क्यों लगातार 'Invalid Signature' दिखा रहा है?

आमतौर पर इसलिए क्योंकि की, Secret फॉर्मेट, एल्गोरिदम या Base64URL एन्कोडिंग बिल्कुल मेल नहीं खाते। एक अतिरिक्त स्पेस, गलत PEM नई लाइन या Base64 और Base64URL के बीच भ्रम पर्याप्त है। बाइट-दर-बाइट मेल की जांच करें और पुष्टि करें कि Header.alg चुने गए एल्गोरिदम से मेल खाता है।

क्या एक ही RSA की RS256 और PS256 को क्रॉस-वेरिफाई कर सकती है?

नहीं। RS256 RSASSA-PKCS1-v1_5 का उपयोग करता है, PS256 RSA-PSS का उपयोग करता है। एक ही RSA की के साथ भी, वे क्रॉस-वेरिफाई नहीं कर सकते। साइनर और वेरिफायर को एक ही एल्गोरिदम का उपयोग करना चाहिए।

alg:none अटैक क्या है?

एक हमलावर Header को `{"alg":"none"}` (कोई सिग्नेचर नहीं) में बदलता है या RS256 को HS256 से बदलता है (पब्लिक की का उपयोग HMAC Secret के रूप में करता है)। सर्वर को एल्गोरिदम व्हाइटलिस्ट लागू करनी चाहिए और कभी टोकन को यह तय करने न दें कि कौन सा एल्गोरिदम उपयोग करना है।

मैं PEM और JWK के बीच कैसे कन्वर्ट करूं?

PEM BEGIN/END लाइनों के साथ क्लासिक OpenSSL नोटेशन है। JWK JSON है और OAuth/OIDC में आम है। OIDC प्रोवाइडर अक्सर `/.well-known/jwks.json` के माध्यम से पब्लिक कीज प्रकाशित करते हैं। यह टूल सीधे PEM और JWK फॉर्मेट्स को संसाधित कर सकता है।

क्या ब्राउज़र सीधे JWT सिग्नेचर वेरिफाई कर सकता है?

हां। ब्राउज़र का नेटिव Web Crypto API (`window.crypto.subtle`) तीसरे पक्ष की लाइब्रेरी के बिना HMAC, RSA, ECDSA, RSA-PSS और Ed25519 साइनिंग और वेरिफिकेशन का समर्थन करता है। यह टूल प्रत्येक वेरिफिकेशन के लिए फ्रंट-एंड पर `crypto.subtle.importKey` और `crypto.subtle.verify` का उपयोग करता है, इसलिए कभी आपके टोकन या कीज नहीं भेजता। नोट: Web Crypto केवल सुरक्षित संदर्भों में उपलब्ध है: **HTTPS** या `localhost`।

क्या मेरा टोकन सर्वर पर भेजा जाता है?

नहीं। इस टूल में सभी पार्सिंग, वेरिफिकेशन और साइनिंग नेटिव Web Crypto API के माध्यम से ब्राउज़र में चलता है। टोकन, Header, Payload, Signature, secret / प्राइवेट की और कोई भी जनरेट की गई की-पेयर कभी सर्वर पर नहीं भेजे जाते। अपने ब्राउज़र के DevTools Network टैब खोलें और आप टोकन सामग्री ले जाने वाला कोई आउटगोइंग अनुरोध नहीं देखेंगे। पेज लोड होने के बाद ऑफलाइन उपयोग किया जा सकता है।

क्या JWT संवेदनशील उपयोगकर्ता जानकारी के लिए सुरक्षित जगह है?

**नहीं।** JWT Payload डिफॉल्ट रूप से प्लेन-टेक्स्ट होता है — टोकन वाला कोई भी व्यक्ति इसे Base64URL में डिकोड करके सामग्री पढ़ सकता है। कोई एन्क्रिप्शन नहीं है। **कभी भी** पासवर्ड, राष्ट्रीय ID नंबर, क्रेडिट कार्ड नंबर, API कीज, एक्सेस टोकन या रिफ्रेश टोकन को JWT में प्लेन-टेक्स्ट के रूप में न रखें। यदि आपको एन्क्रिप्शन की आवश्यकता है, JWS के बजाय JWE (RFC 7516) का उपयोग करें। JWT गैर-संवेदनशील Claims (उपयोगकर्ता ID, भूमिका, समाप्ति, किरायेदार ID) के लिए उपयुक्त हैं; संवेदनशील डेटा को सर्वर-साइड पर `sub` का उपयोग करके क्वेरी किया जाना चाहिए।

JWT डिकोड, वेरिफाई और जनरेट क्या है?

JWT (JSON Web Token) IETF द्वारा RFC 7519 में परिभाषित एक ओपन स्टैंडर्ड है (RFC 7515 JWS सिग्नेचर फॉर्म का वर्णन करता है, RFC 7516 JWE एन्क्रिप्शन का वर्णन करता है, RFC 7517 JWK कीज को परिभाषित करता है) HTTP अनुरोधों, OIDC फ्लो और माइक्रोसर्विस कॉल्स के बीच 'घोषित' उपयोगकर्ता जानकारी को सुरक्षित रूप से स्थानांतरित करने के लिए। एक मानक JWT स्ट्रिंग Base64URL-एन्कोडेड तीन सेगमेंट से बनी होती है: Header (एल्गोरिदम और प्रकार), Payload (Claims, उपयोगकर्ता डेटा) और Signature (पहले दो पर की-आधारित सिग्नेचर)। तीन सेगमेंट एक डॉट `.` से जुड़े होते हैं, उदा. `eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c`।

**JWT एन्क्रिप्शन नहीं है।** यह सबसे आम गलतफहमी है। Payload डिफॉल्ट रूप से प्लेन-टेक्स्ट होता है — कोई भी इसे Base64URL में डिकोड करके सामग्री पढ़ सकता है। JWT **टैम्परिंग डिटेक्शन** प्रदान करता है, गोपनीयता नहीं: सर्वर साझा की के साथ Header.Payload को फिर से साइन करता है और टोकन के Signature से तुलना करता है। यदि वे मेल खाते हैं, टोकन ट्रांजिट में बदला नहीं गया है। यह 'एंटी-काउंटरफिट स्टैम्प वाला ट्रेन टिकट' का रूपक है: निरीक्षक को इससे मतलब है कि टिकट असली है या नहीं, QR कोड पढ़ने योग्य है या नहीं इससे नहीं।

JWT 13 एल्गोरिदम के बीच जिम्मेदारियों को साफ तौर पर बांटता है। **HMAC परिवार** (HS256/HS384/HS512) साइनिंग और वेरिफिकेशन के लिए सममित की का उपयोग करता है, तेज और सरल, एक सेवा या विश्वसनीय क्लस्टर के लिए उपयुक्त; secret कम से कम digest की लंबाई का होना चाहिए (उदा. HS256 के लिए ≥ 32 बाइट्स)। **RSA परिवार** (RS256/RS384/RS512) सबसे आम असममित स्कीम RSASSA-PKCS1-v1_5 का उपयोग करता है — साइनर के पास प्राइवेट की होती है, वेरिफायर के पास पब्लिक की होती है। **RSA-PSS परिवार** (PS256/PS384/PS512) मजबूत सुरक्षा गारंटी के साथ नए RSA-PSS पैडिंग का उपयोग करता है, AWS SigV4 और आधुनिक OIDC आइडेंटिटी प्रोवाइडर द्वारा प्राथमिकता दी जाती है। **ECDSA परिवार** (ES256/ES384/ES512) छोटे सिग्नेचर और बेहतर प्रदर्शन के साथ एलिप्टिक कर्व्स (क्रमशः P-256/P-384/P-521) का उपयोग करता है। **EdDSA** (मुख्य रूप से Ed25519) बेहद तेज और नियतिवादी है (वही संदेश + वही की = हर बार वही सिग्नेचर) और OAuth 2.1 और नए प्रोटोकॉल में अनुशंसित एल्गोरिदम है।

सुरक्षा वह जगह है जहां JWT प्रोडक्शन में ठोकर खाता है। OWASP JWT Cheat Sheet कम से कम चार सख्त नियमों को सूचीबद्ध करता है: (1) Payload में कभी भी पासवर्ड, राष्ट्रीय पहचान दस्तावेज, कार्ड नंबर या API कीज को प्लेन-टेक्स्ट के रूप में न रखें; (2) सर्वर को **टोकन के Header में घोषित alg फील्ड पर कभी भरोसा नहीं करना चाहिए** — हार्ड-कोडेड एल्गोरिदम के साथ वेरिफाई करना चाहिए, अन्यथा `alg: none` में हेडर को फिर से लिखने वाला हमलावर सब कुछ बायपास कर देता है (यह CVE-2015-9235 जैसे ऐतिहासिक CVE का स्रोत है); (3) HMAC secrets यादृच्छिक होने चाहिए और कम से कम 32 बाइट्स लंबे होने चाहिए, कभी छोटी स्ट्रिंग्स नहीं; (4) वेरिफिकेशन केवल सिग्नेचर चेक्स से अधिक है — आपको `exp` (समाप्ति), `nbf` (not-before), `iss` (जारीकर्ता) और `aud` (दर्शक) को भी मान्य करना चाहिए। यह टूल इनमें से प्रत्येक Claims को UI में हाइलाइट करता है ताकि आप तुरंत बता सकें कि विफलता सिग्नेचर समस्या है, समय समस्या है या Claims समस्या है।

JWT सत्रों का विकल्प नहीं है। सत्रें उपयोगकर्ता की स्थिति को सर्वर पर संग्रहित करती हैं (Redis या डेटाबेस); JWT स्थिति को टोकन में पैक करता है। माइक्रोसर्विस आर्किटेक्चर, स्टेटलेस API, मोबाइल क्लाइंट और बहुत अधिक CORS वाले सेटअप JWT से लाभान्वित होते हैं; पारंपरिक एंटरप्राइज सिस्टम और तत्काल रद्दीकरण की आवश्यकता वाले फ्लो (उदा. 'इस उपयोगकर्ता को अभी निकालो') अभी भी सत्रों द्वारा बेहतर सेवा प्राप्त करते हैं। यह टूल शुद्ध JWT डिबगिंग के साथ-साथ सत्र से JWT माइग्रेशन के टोकन पार्स / सिग्नेचर वेरिफिकेशन / Payload एडिटिंग स्टेप्स को भी कवर करता है।

Code Examples

50 lines of Node.js: hand-written HS256 sign and verify

javascript

Distills JWT's core mechanism: encode Header and Payload in Base64URL, then HMAC-SHA256 the `header.payload` string. In production, use a library like jsonwebtoken or jose — this snippet exists to make signature failures debuggable.

const crypto = require('node:crypto')

function b64url(input) {
  return Buffer.from(input)
    .toString('base64')
    .replace(/\+/g, '-')
    .replace(/\//g, '_')
    .replace(/=+$/, '')
}

function hmacSign(data, secret) {
  return b64url(crypto.createHmac('sha256', secret).update(data).digest())
}

function sign(payload, secret) {
  const header = b64url(JSON.stringify({ alg: 'HS256', typ: 'JWT' }))
  const body = b64url(JSON.stringify(payload))
  const signature = hmacSign(`${header}.${body}`, secret)
  return `${header}.${body}.${signature}`
}

function verify(token, secret) {
  const [h, p, s] = token.split('.')
  const expected = hmacSign(`${h}.${p}`, secret)
  const a = Buffer.from(s)
  const b = Buffer.from(expected)
  return a.length === b.length && crypto.timingSafeEqual(a, b)
}

const SECRET = 'my-super-secret-key'
const payload = { userId: 42, role: 'admin', exp: Math.floor(Date.now() / 1000) + 3600 }
const token = sign(payload, SECRET)

console.log(token)
console.log(verify(token, SECRET))       // true
console.log(verify(token, 'wrong-key'))  // false

Browser-side: Web Crypto API for HMAC signing

html

The core idea of this tool's front-end: use the browser's native crypto.subtle for HMAC, RSA, ECDSA, RSA-PSS and Ed25519 verification — no third-party library needed. Drop this into any HTML page to mint HS256 tokens.

<!doctype html>
<html>
  <body>
    <pre id="out"></pre>
    <script>
      const out = document.getElementById('out')

      const b64url = buf =>
        btoa(String.fromCharCode(...new Uint8Array(buf)))
          .replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')

      const b64urlStr = str => b64url(new TextEncoder().encode(str))

      async function sign(payload, secret) {
        const header = b64urlStr(JSON.stringify({ alg: 'HS256', typ: 'JWT' }))
        const body = b64urlStr(JSON.stringify(payload))
        const data = new TextEncoder().encode(`${header}.${body}`)

        const key = await crypto.subtle.importKey(
          'raw',
          new TextEncoder().encode(secret),
          { name: 'HMAC', hash: 'SHA-256' },
          false,
          ['sign']
        )

        const sig = await crypto.subtle.sign('HMAC', key, data)
        return `${header}.${body}.${b64url(sig)}`
      }

      ;(async () => {
        const token = await sign({ user: 'alice', role: 'admin' }, 'browser-demo-secret')
        out.textContent = token
      })()
    </script>
  </body>
</html>

Node.js: verify RS256 with jose (the right way)

javascript

Use a mature library like jose, jsonwebtoken, or PyJWT in production — never roll your own. This snippet shows how jose verifies an RS256 token, prints the failure reason on error (alg mismatch, bad signature, expired, kid not found, etc).

import { jwtVerify, importSPKI } from 'jose'
import { readFile } from 'node:fs/promises'

const token = 'eyJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.payload.signature'
const publicKeyPem = await readFile('public.pem', 'utf8')

try {
  const { payload, protectedHeader } = await jwtVerify(
    token,
    await importSPKI(publicKeyPem, 'RS256'),
    {
      issuer: 'https://idp.example.com',
      audience: 'my-app',
      algorithms: ['RS256'],     // critical: algorithm whitelist blocks alg:none and HS256-substitution attacks
    }
  )
  console.log('alg =', protectedHeader.alg)
  console.log('sub  =', payload.sub)
} catch (err) {
  console.error('verify failed:', err.code, err.message)
  // common: ERR_JWT_EXPIRED / ERR_JWS_INVALID / ERR_JWS_SIGNATURE_VERIFICATION_FAILED
}

Python: parse a token and print its Claims with PyJWT

python

The most common way to debug JWT on the Python side. PyJWT's decode() validates exp / nbf / iat by default and returns the result as a plain dict.

import jwt

token = 'eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxw'

# Parse (no signature check, just look at Header and Payload)
print(jwt.get_unverified_header(token))
# {'alg': 'HS256', 'typ': 'JWT'}

print(jwt.decode(token, options={'verify_signature': False}))
# {'sub': '1234'}

# Full verification
claims = jwt.decode(
    token,
    'my-super-secret-key',
    algorithms=['HS256'],
    audience='my-app',
    issuer='my-service',
)
print(claims['sub'])

Supported Video Formats

FormatMIMEBrowser supportWhen to use
HS256 / HS384 / HS512HMAC + SHA-256/384/512UniversalSymmetric key algorithm: वही Secret साइन और वेरिफाई दोनों करता है। यह सरल और तेज है, इसलिए trusted boundary के भीतर चलने वाले service cluster के लिए अच्छा है। Secret कम से कम HS256 के लिए 32 bytes, HS384 के लिए 48 bytes और HS512 के लिए 64 bytes होना चाहिए।
RS256 / RS384 / RS512RSASSA-PKCS1-v1_5 + SHA-2Web Crypto APIसबसे आम asymmetric algorithm। private key से sign किया जाता है और public key से verify किया जाता है। अधिकतर OIDC providers, API gateways और enterprise SSO में यही default विकल्प होता है।
PS256 / PS384 / PS512RSA-PSS + SHA-2Web Crypto APIRSA-PSS, RS256 का नया और अधिक सुरक्षित विकल्प है। AWS SigV4, AWS Cognito और modern OIDC providers अक्सर इसे प्राथमिकता देते हैं। verification match कराने के लिए saltLength साफ़ तौर पर सेट करना ज़रूरी है।
ES256 / ES384 / ES512ECDSA + P-256/P-384/P-521Web Crypto APIElliptic-curve signatures। Signature छोटा होता है (ES256 सिर्फ 64 bytes), performance अच्छी रहती है और JWT छोटा बनता है। Sign in with Apple default रूप से ES256 इस्तेमाल करता है।
EdDSA (Ed25519)Ed25519 / Ed448Web Crypto APIनई पीढ़ी का high-performance signature algorithm। Signatures deterministic होते हैं (same message + same key = same signature), nonce reuse का जोखिम नहीं रहता और नए protocols के लिए यह अच्छा विकल्प है।

Output Example

A real MP3 file encoded to a Data URI — copy-ready:

Header (Base64URL): eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
Payload (Base64URL): eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNzE2MjM5MDIyfQ
Signature: kZJfaYjK3iCkVFL5EL9zGRZ5SmD8_x2h6B5c7pVFfVGo

Privacy & Security

यह JWT वर्कबेंच आपके ब्राउज़र में 100% चलता है, ब्राउज़र के नेटिव Web Crypto API द्वारा समर्थित। आप जो टोकन पेस्ट करते हैं, Header, Payload, Signature, HMAC Secret, कोई भी RSA/ECDSA प्राइवेट की, कोई भी जनरेट की गई की-पेयर और हर सिग्नेचर/वेरिफिकेशन गणना आपके डिवाइस पर रहती है — वे कभी सर्वर पर नहीं जाते, कभी लॉग नहीं होते, कभी विश्लेषित नहीं होते और कभी कैश नहीं होते। पेज लोड होने के बाद ऑफलाइन उपयोग किया जा सकता है। सर्वोत्तम अभ्यास: कभी भी लंबे समय तक चलने वाले प्रोडक्शन टोकन या प्रोडक्शन प्राइवेट कीज को इस सहित किसी भी ऑनलाइन टूल में पेस्ट न करें। यह टूल डिबगिंग, इंटीग्रेशन टेस्टिंग, सीखने और टेस्ट टोकन जनरेशन के लिए उपयुक्त है — प्रोडक्शन secrets और प्राइवेट कीज को नियंत्रित, स्थानीय वातावरण में संसाधित किया जाना चाहिए।

Authoritative References

Troubleshooting

Invalid Signature: 'signature is invalid'

टोकन और वेरिफिकेशन की मेल नहीं खाते। आम कारण: (1) सर्वर की और टूल में पेस्ट की गई की अलग हैं (सबसे आम); (2) की में अदृश्य अक्षर हैं (अंत में स्पेस, नई लाइन, शून्य-चौड़ाई अक्षर); (3) Base64 और Base64URL मिश्रित हैं; (4) गलत एल्गोरिदम चुना गया है (Header HS256 कहता है, सर्वर RS256 के रूप में वेरिफाई करता है या इसके विपरीत)। पहले जांचें कि की बाइट-दर-बाइट मेल खाती है: PEM की अंत की नई लाइनों, HMAC Secret के अंत के स्पेस और JWK `k` मानों पर ध्यान दें जो URL द्वारा गलत तरीके से डिकोड किए गए हो सकते हैं। पुष्टि करें कि टूल में एल्गोरिदम टोकन के Header.alg से मेल खाता है। सटीक त्रुटि को पुन: पेश करने और 'डिकोड सफल' और 'वेरिफिकेशन विफल' के बीच होने की पुष्टि करने के लिए इस टूल के decode-plus-verify का उपयोग करें।

HTTP 401 Unauthorized: Token Expired या iat भविष्य में

सिग्नेचर वेरिफिकेशन पास हो गया लेकिन `exp` अतीत में है (Token Expired), `nbf` अभी भी भविष्य में है (Not Before) या `iat` सर्वर के वर्तमान समय के बाद है (अक्सर घड़ी सिंक ड्रिफ्ट के कारण)। एक और आम मामला मेल न खाने वाला `aud` (दर्शक) है: टोकन ऐप A के लिए जारी किया गया था लेकिन ऐप B द्वारा वेरिफाई किया जा रहा है। exp / nbf / iat स्टेटस तुरंत देखने के लिए इस टूल में हाइलाइट किए गए Claims क्षेत्र का उपयोग करें। लाल exp = समाप्त, फिर से जारी करें। लाल nbf = अभी अमान्य, जांचें कि iat भविष्य का समय है या नहीं। लाल aud = गलत दर्शक, जांचें कि सर्वर सही दर्शक के साथ कॉन्फ़िगर है या नहीं।

PEM या JWK इम्पोर्ट त्रुटि

PEM में अतिरिक्त खाली लाइनें हैं या हेडर/फुटर मार्कर गायब हैं (`-----BEGIN PUBLIC KEY-----`); JWK में आवश्यक फील्ड गायब हैं (`kty` / `n` / `e` / `kid`); JWK `k` मान Base64URL पैडिंग से रहित है (`=` से पैड किया जाना चाहिए या सख्ती से `=` के बिना); RSA प्राइवेट की को पब्लिक की के रूप में इम्पोर्ट किया जा रहा है; Ed25519 प्राइवेट की (32-बाइट सीड) 64 बाइट्स के रूप में प्रदान की जा रही है। `openssl rsa -in key.pem -pubout -outform PEM` या `openssl ec -in key.pem -pubout` के साथ मानक PKIX PEM को फिर से निर्यात करें; JWK के लिए, मैन्युअल रूप से एन्कोड करने के बजाय OIDC Discovery एंडपॉइंट `/.well-known/jwks.json` से कच्चा आउटपुट उपयोग करें। यह टूल स्वचालित रूप से PEM हेडर्स, गायब पैडिंग और गायब JWK फील्ड्स का पता लगाता है और संकेत देता है।

RS256 बनाम PS256 भाषाओं के बीच सिग्नेचर विफलताएं

RS256 RSASSA-PKCS1-v1_5 का उपयोग करता है, PS256 RSA-PSS का उपयोग करता है। ये दोनों **क्रॉस-वेरिफाई नहीं कर सकते** — एक निश्चित RSA की के साथ RS256 में साइन किया गया टोकन हमेशा PS256 वेरिफिकेशन में विफल होगा, और सिग्नेचर लंबाई में कुछ बाइट्स से भिन्न हो सकता है। सुनिश्चित करें कि साइनर और वेरिफायर एक ही एल्गोरिदम का उपयोग करते हैं। AWS SigV4 PS256 का उपयोग करता है, अधिकांश OIDC IdP RS256 का उपयोग करते हैं। RSA-PSS में `saltLength` पैरामीटर भी होता है — OpenSSL डिफॉल्ट 32, jose डिफॉल्ट 32, Go का `rsa.PSSOptions{SaltLength: rsa.PSSSaltLengthEqualsHash}` सही समकक्ष है। भाषाओं के बीच इंटीग्रेशन टेस्टिंग से पहले इसे लॉक करें।

alg:none अटैक और HS256 की रिप्लेसमेंट अटैक

सर्वर टोकन के Header में घोषित alg के आधार पर वेरिफिकेशन एल्गोरिदम चुनता है। एक हमलावर हेडर को `alg: none` (कोई सिग्नेचर नहीं) में फिर से लिखता है या RS256 टोकन को HS256 में फिर से लिखता है (पब्लिक की का उपयोग साझा HMAC Secret के रूप में करता है) और वेरिफिकेशन को बायपास करता है। CVE-2015-9235 (jsonwebtoken) और CVE-2022-23529 (कई Node लाइब्रेरी) जैसे ऐतिहासिक CVE इसी पैटर्न से उत्पन्न होते हैं। सर्वर को एल्गोरिदम व्हाइटलिस्ट लागू करनी चाहिए — उदाहरण `algorithms: ['RS256']` — और कभी टोकन को यह तय करने न दें कि कौन सा एल्गोरिदम उपयोग करना है। इस टूल का UI दोनों Header.alg और आपके द्वारा वास्तव में चुने गए एल्गोरिदम को दिखाता है, और मिसमैच को फ्लैग करता है: यह 'क्लाइंट को Header.alg पर भरोसा नहीं करना चाहिए' का लाइव डेमो है।

AES एन्क्रिप्ट और डिक्रिप्टऑडियो को Base64 में बदलेंBase32 एन्कोड / डिकोडBase58 एन्कोड / डिकोडBase64 बैच डिकोडBase64 बैच एन्कोडBase64 कैरेक्टर क्लीनरData URL कन्वर्टरBase64 डिकोडBase64 तुलनाकर्ताBase64 एन्कोडिंगBase64 फ़ॉर्मेटBase64-Hex कनवर्टरBase64 मर्जरBase64 MIMEBase64 पैडिंग प्रबंधकBase64 स्प्लिटरBase64 लंबई स्टैटिस्टिक्सBase64 से ऑडियोBase64 से फ़ाइलBase64 से HexBase64 से इमेजBase64 से टेक्स्टBase64 से वीडियोBase64 URL SafeBase64 फ़ॉर्मेट वैलिडेशनBase85 कोडेकबाइनरी रूपांतरणसीज़र सिफरDES एन्क्रिप्शन डिक्रिप्शनफ़ाइल हैश कैलकुलेटरफ़ाइल से Base64हेक्साडेसिमलHMAC जनरेशन और वेरिफिकेशनHTML एन्टिटी एन्कोड और डिकोडइमेज से Base64जावा ऑबफस्केशनJS ऑब्फस्केटJWT टूलMD5 हैशमोर्स कोडPBKDF2 की डेरिवेशनPHP ऑब्फस्केटPython ऑब्फस्केटSHA-1 हैश वैल्यूSHA-256 हैशSHA-512 हैश वैल्यूसेफ स्ट्रिंग कंपैरिजनटेक्स्ट से Base64Unicode एस्केपURL एन्कोडिंगवीडियो से Base64