JWT Decoder

JWT ڈی کوڈر / اینکوڈر

کسی بھی JSON Web Token کو ڈی کوڈ کریں اور اس کا header، payload، اور signature دیکھیں — یا HS256/384/512 کے ساتھ نیا ٹوکن سائن کریں۔ HMAC سگنیچرز مقامی طور پر تصدیق کرتا ہے۔ 100% آپ کے براؤزر میں۔

JWT ڈی کوڈر / اینکوڈر — TL;DR

کسی بھی JSON Web Token کو ڈی کوڈ کریں اور اس کا header، payload، اور signature دیکھیں — یا HS256/384/512 کے ساتھ نیا ٹوکن سائن کریں۔ HMAC سگنیچرز مقامی طور پر تصدیق کرتا ہے۔ 100% آپ کے براؤزر میں۔

نہیں۔ پورا ٹول اس صفحے کے اندر JavaScript ہے۔ ٹوکن پیسٹ کریں، ڈی کوڈنگ آپ کے براؤزر میں ہوتی ہے، بائٹس کبھی ٹیب سے باہر نہیں جاتیں۔ DevTools → Network کھول کر دیکھیں — ڈی کوڈ یا verify کے دوران کوئی request نہیں بھیجی جاتی۔ یہ حقیقی کسٹمر یا پروڈکشن ٹوکنز پیسٹ کرنا محفوظ بناتا ہے۔

یہ ثابت کرتا ہے کہ ٹوکن کسی ایسے شخص نے سائن کیا جس کے پاس secret (HMAC) یا private key (RSA/ECDSA) ہے۔ یہ payload کو encrypt نہیں کرتا — header اور payload صرف base64url-encoded JSON ہیں، ٹوکن رکھنے والا کوئی بھی شخص انہیں پڑھ سکتا ہے۔ signature صرف چھیڑ چھاڑ روکتا ہے: اگر آپ payload کا ایک بائٹ بھی بدلیں تو signature میل نہیں کھاتا۔

JWT اکثر صارف ID، ای میل، scopes، اور کبھی کبھی session cookies کے مساوی لے جاتا ہے — بالکل وہ ڈیٹا جو آپ کو کسی اجنبی کے سرور میں پیسٹ نہیں کرنا چاہیے۔ iKit کا ڈی کوڈر JavaScript کے طور پر چلتا ہے جو پہلے سے آپ کے براؤزر ٹیب میں لوڈ ہے۔ DevTools → Network میں قابل تصدیق: ڈی کوڈ یا verify کے دوران کوئی fetch، کوئی XHR، کوئی beacon نہیں۔

Header

Payload

Signature

معیاری claims


            

HMAC سگنیچر کی تصدیق کریں

HS256/384/512 ٹوکنز کے لیے، signing secret ٹائپ کریں تاکہ سگنیچر کی مقامی طور پر تصدیق ہو۔ RS256/ES256 (RSA/ECDSA) کے لیے سرور سائیڈ لائبریری استعمال کریں — public-key تصدیق کے لیے PEM فائل درکار ہوتی ہے جسے ہم یہاں قبول نہیں کرتے۔

iKit JWT ڈی کوڈر کیوں؟

JWT ڈیبگ کرنے کا تیز ترین طریقہ — کوئی اپ لوڈ نہیں، کوئی سائن اپ نہیں، آپ اور آپ کے ٹوکن کے درمیان کوئی تیسرا فریق نہیں۔

تین پینلز، ایک پیسٹ

JWT پیسٹ کریں، ڈی کوڈ شدہ header، payload، اور signature کو ساتھ ساتھ دیکھیں۔ معیاری claims (iss، sub، aud، exp، iat) ٹائم سٹیمپ اور لیبل کے ساتھ ظاہر ہوتے ہیں۔

مقامی HMAC تصدیق

HS256/384/512 ٹوکنز کے لیے، secret ٹائپ کریں تاکہ براؤزر کے Web Crypto API کے ذریعے سگنیچر کی تصدیق ہو۔ secret کبھی آپ کے ٹیب سے باہر نہیں جاتا۔

اپنے ٹوکن خود سائن کریں

Encode موڈ پر سوئچ کریں، header اور payload کو JSON کے طور پر ایڈٹ کریں، algorithm منتخب کریں، secret ٹائپ کریں، اور فوراً سائن شدہ ٹوکن حاصل کریں۔

ڈیزائن کے لحاظ سے پرائیویسی

JWT payloads میں صارف IDs، ای میلز، کبھی کبھی scopes ہوتے ہیں — انہیں کبھی سرور ٹول میں پیسٹ نہ کریں۔ iKit کا ڈی کوڈر آپ کے براؤزر میں JavaScript کے طور پر چلتا ہے۔ DevTools → Network میں قابل تصدیق ہے۔

میعاد سے آگاہی

exp، nbf، iat جیسے معیاری claims کو پڑھنے کے قابل تاریخوں اور واضح EXPIRED / valid بیج کے ساتھ نمایاں کیا جاتا ہے تاکہ آپ ایک نظر میں جان سکیں کہ ٹوکن ابھی بھی درست ہے یا نہیں۔

کھلا معیار، کھلا کوڈ

براؤزر کے native Web Crypto API اور JSON parser پر بنایا گیا — وہی algorithms جیسے OpenSSL، libjwt، jose۔ یہ رویہ ہر جدید JWT لائبریری سے میل کھاتا ہے۔

JWT ڈی کوڈنگ اصل میں کیسے کام کرتی ہے

JWT تین base64url-encoded JSON حصے ہیں جو نقطوں سے الگ ہوتے ہیں — بس اتنا ہی ہے۔

  1. 1

    دو نقطوں پر تقسیم کریں

    JWT اس طرح نظر آتا ہے aaa.bbb.ccc۔ ہم دو لفظی نقطوں پر تقسیم کرتے ہیں، جو encoded header، payload، اور signature دیتا ہے۔ اگر ہمیں بالکل تین حصے نہیں ملتے تو ٹوکن خراب ہے۔

  2. 2

    ہر حصے کو Base64URL-decode کریں

    Header اور payload base64url-encoded UTF-8 JSON ہیں۔ Base64URL = Base64 جس میں +//= کے بجائے -/_ ہے اور کوئی padding نہیں۔ ہم حروف واپس بدلنے کے بعد atob کرتے ہیں، پھر نتیجے میں آنے والی string کو JSON.parse کرتے ہیں۔

  3. 3

    ساخت کے ساتھ رینڈر کریں

    Header ہمیں algorithm (alg: HS256، RS256، وغیرہ) اور type بتاتا ہے۔ Payload میں claims ہوتے ہیں — معیاری (iss، sub، aud، exp، iat، nbf، jti) اور کوئی بھی custom فیلڈز۔ ہم ہر ایک کو لیبل والے سیکشن میں ظاہر کرتے ہیں۔

  4. 4

    تصدیق (صرف HMAC)

    HS256/384/512 کے لیے، ہم آپ کے ٹائپ کیے گئے secret کا استعمال کرتے ہوئے header.payload کا HMAC دوبارہ حساب کرتے ہیں اور تیسرے segment میں signature سے موازنہ کرتے ہیں۔ یہی HMAC(SHA-256, secret, signing_input) base64url-encoded ہے۔ میل = signature درست۔

عام JWT ڈیبگنگ کے کام

حقیقی صورتحال جہاں آپ JWT ڈی کوڈر کا استعمال کریں گے۔

اپنے auth provider سے ٹوکن کا معائنہ

Auth0، Firebase، Keycloak، AWS Cognito سب لاگ ان کے بعد JWTs واپس کرتے ہیں۔ access_token پیسٹ کریں اور دیکھیں کہ آپ کی ایپ اصل میں کون سے claims وصول کر رہی ہے — صارف ID کیا ہے، کیا scopes ہیں، یہ کب ختم ہو گا؟

401 Unauthorized کو ڈیبگ کرنا

API آپ کی request مسترد کر رہا ہے؟ ٹوکن کو ڈی کوڈ کر کے چیک کریں: کیا یہ ختم ہو چکا ہے (exp ماضی میں)؟ کیا audience claim (aud) وہی ہے جو API کو متوقع ہے؟ کیا issuer (iss) صحیح tenant ہے؟

webhook signature کی تصدیق

Stripe، GitHub Apps، Slack webhook payloads JWTs کے طور پر سائن کر کے بھیجتے ہیں۔ ایک وصول کرنے کے بعد، اسے Decode موڈ میں مشترکہ secret کے ساتھ پیسٹ کریں تاکہ تصدیق کریں کہ request واقعی ان سے آئی ہے۔

ٹیسٹ ٹوکن بنانا

انٹیگریشن ٹیسٹ کے لیے تازہ سائن شدہ JWT چاہیے؟ Encode موڈ پر سوئچ کریں، payload ایڈٹ کریں (custom صارف ID، custom expiry)، HS256 + اپنا ٹیسٹ secret منتخب کریں، ملی سیکنڈز میں ٹوکن حاصل کریں۔ کوئی backend round-trip نہیں۔

مقامی JWT ڈی کوڈنگ کیوں اہم ہے

JWT اکثر صارف ID، ای میل، scopes، اور کبھی کبھی session cookies کے مساوی لے جاتا ہے — بالکل وہ ڈیٹا جو آپ کو کسی اجنبی کے سرور میں پیسٹ نہیں کرنا چاہیے۔ iKit کا ڈی کوڈر JavaScript کے طور پر چلتا ہے جو پہلے سے آپ کے براؤزر ٹیب میں لوڈ ہے۔ DevTools → Network میں قابل تصدیق: ڈی کوڈ یا verify کے دوران کوئی fetch، کوئی XHR، کوئی beacon نہیں۔

  • ڈی کوڈ یا verify کے دوران صفر نیٹ ورک requests — DevTools میں قابل تصدیق۔
  • تصدیق کے لیے ٹائپ کیا گیا secret براؤزر میموری میں رہتا ہے اور Clear / refresh پر مٹا دیا جاتا ہے۔
  • پروڈکشن ٹوکنز، کسٹمر access tokens، اور webhook secrets کے لیے محفوظ۔

متعلقہ گائیڈز

iKit بلاگ سے تفصیلی ٹیوٹوریلز اور ٹولز کا موازنہ۔

اکثر پوچھے گئے سوالات

کیا یہ محفوظ ہے؟ کیا میرے JWTs اپ لوڈ ہوتے ہیں؟

نہیں۔ پورا ٹول اس صفحے کے اندر JavaScript ہے۔ ٹوکن پیسٹ کریں، ڈی کوڈنگ آپ کے براؤزر میں ہوتی ہے، بائٹس کبھی ٹیب سے باہر نہیں جاتیں۔ DevTools → Network کھول کر دیکھیں — ڈی کوڈ یا verify کے دوران کوئی request نہیں بھیجی جاتی۔ یہ حقیقی کسٹمر یا پروڈکشن ٹوکنز پیسٹ کرنا محفوظ بناتا ہے۔

JWT signature اصل میں کس چیز کی تصدیق کرتا ہے؟

یہ ثابت کرتا ہے کہ ٹوکن کسی ایسے شخص نے سائن کیا جس کے پاس secret (HMAC) یا private key (RSA/ECDSA) ہے۔ یہ payload کو encrypt نہیں کرتا — header اور payload صرف base64url-encoded JSON ہیں، ٹوکن رکھنے والا کوئی بھی شخص انہیں پڑھ سکتا ہے۔ signature صرف چھیڑ چھاڑ روکتا ہے: اگر آپ payload کا ایک بائٹ بھی بدلیں تو signature میل نہیں کھاتا۔

میرا ڈی کوڈ شدہ payload ٹھیک نظر آتا ہے لیکن verification ناکام کیوں ہے؟

تین عام وجوہات: (1) غلط secret — JWT secrets case-sensitive ہوتے ہیں اور کوئی بھی whitespace کا فرق verification توڑ دیتا ہے۔ (2) Algorithm mismatch — header کہتا ہے HS256 لیکن secret اصل میں HS512 کے ساتھ استعمال ہوا تھا۔ (3) سائن کرنے کے بعد ٹوکن میں ترمیم کی گئی — ایک بائٹ بھی signature توڑ دیتا ہے۔ چیک کریں کہ header.alg وہی ہے جو آپ کو متوقع ہے۔

RS256، ES256، اور دیگر public-key algorithms کے بارے میں کیا؟

iKit فی الحال صرف HMAC verification (HS256/384/512) کو سپورٹ کرتا ہے۔ RS256 اور ES256 public-key cryptography استعمال کرتے ہیں — verification کے لیے issuer کی public key PEM فارمیٹ میں درکار ہے، جو زیادہ پیچیدہ UI ہے۔ فی الحال، ڈی کوڈنگ کام کرتی ہے (header/payload/signature حصے درست ظاہر ہوتے ہیں)، لیکن Verify بٹن آپ کو بتائے گا کہ یہ غیر معاون ہے۔ RSA/ECDSA verification منصوبہ بندی میں ہے۔

یہ jwt.io سے کیسے مختلف ہے؟

وہی خیال، مختلف defaults۔ iKit کا ڈی کوڈر مکمل طور پر آپ کے براؤزر میں چلتا ہے (jwt.io بھی ایسا کرتا ہے، لیکن iKit کا کوڈ view-source کے ذریعے دیکھا جا سکتا ہے اور ہمارے ڈومین پر کوئی تیسرے فریق کے trackers نہیں)۔ ہم exp claim کے لیے واضح EXPIRED / valid بیج، ساختی claim نوٹس (iat / nbf / iss / sub / aud / jti قابل پڑھ rows کے طور پر)، اور copy-everything-decoded بٹن شامل کرتے ہیں جو آپ کو bug رپورٹ میں پیسٹ کرنے کے لیے مکمل ساختی آؤٹ پٹ دیتا ہے۔