JWT Decoder

JWT Decoder / Encoder

ถอดรหัส JSON Web Token ใดก็ได้เพื่อดู header, payload และ signature — หรือเซ็นโทเคนใหม่ด้วย HS256/384/512 ตรวจสอบลายเซ็น HMAC ในเครื่อง ทำงานในเบราว์เซอร์ทั้งหมด

JWT Decoder / Encoder — TL;DR

ถอดรหัส JSON Web Token ใดก็ได้เพื่อดู header, payload และ signature — หรือเซ็นโทเคนใหม่ด้วย HS256/384/512 ตรวจสอบลายเซ็น HMAC ในเครื่อง ทำงานในเบราว์เซอร์ทั้งหมด

ไม่ครับ เครื่องมือทั้งหมดเป็น JavaScript ในหน้านี้ วางโทเคน การถอดรหัสเกิดในเบราว์เซอร์ ข้อมูลไม่ออกจากแท็บ เปิด DevTools → Network แล้วดูได้ — ไม่มี request ใดถูกส่งระหว่างถอดรหัสหรือตรวจสอบ ปลอดภัยพอที่จะวางโทเคนของลูกค้าจริงหรือ production ได้

มันพิสูจน์ว่าโทเคนถูกเซ็นโดยผู้ที่ถือ secret (HMAC) หรือ private key (RSA/ECDSA) มันไม่ได้เข้ารหัส payload — header และ payload เป็นแค่ JSON ที่เข้ารหัสแบบ base64url ใครมีโทเคนก็อ่านได้ Signature เพียงป้องกันการดัดแปลง: หากเปลี่ยน payload แม้แต่ไบต์เดียว signature จะไม่ตรงกันอีกต่อไป

JWT มักพก user ID, อีเมล, scopes และบางครั้งก็เทียบเท่า session cookie — เป็นข้อมูลที่คุณไม่ควรวางลงในเซิร์ฟเวอร์ของคนแปลกหน้าเด็ดขาด เครื่องมือถอดรหัสของ iKit ทำงานเป็น JavaScript ที่โหลดไว้ในแท็บเบราว์เซอร์ของคุณแล้ว ตรวจสอบได้ใน DevTools → Network: ไม่มี fetch, XHR หรือ beacon ระหว่างการถอดรหัสหรือตรวจสอบ

Header

Payload

Signature

Claims มาตรฐาน


            

ตรวจสอบลายเซ็น HMAC

สำหรับโทเคน HS256/384/512 ให้พิมพ์ secret ที่ใช้เซ็นเพื่อตรวจสอบลายเซ็นในเครื่อง สำหรับ RS256/ES256 (RSA/ECDSA) ให้ใช้ไลบรารีฝั่งเซิร์ฟเวอร์ — การตรวจสอบด้วย public key ต้องใช้ไฟล์ PEM ซึ่งเครื่องมือนี้ไม่รับ

ทำไมต้อง iKit JWT Decoder

วิธีดีบัก JWT ที่เร็วที่สุด — ไม่ต้องอัปโหลด ไม่ต้องสมัคร ไม่มีบุคคลที่สามคั่นกลางระหว่างคุณกับโทเคน

สามช่อง วางครั้งเดียว

วาง JWT แล้วเห็น header, payload และ signature ที่ถอดรหัสแล้วเรียงข้างกัน Claims มาตรฐาน (iss, sub, aud, exp, iat) จะถูกแปลงเวลาและติดป้ายให้

ตรวจสอบ HMAC ในเครื่อง

สำหรับโทเคน HS256/384/512 พิมพ์ secret เพื่อตรวจสอบลายเซ็นด้วย Web Crypto API ของเบราว์เซอร์ Secret ไม่ออกจากแท็บของคุณ

เซ็นโทเคนของคุณเอง

สลับไปโหมด Encode แก้ header และ payload เป็น JSON เลือกอัลกอริทึม พิมพ์ secret แล้วได้โทเคนที่เซ็นแล้วทันที

ออกแบบมาเพื่อความเป็นส่วนตัว

Payload ของ JWT มี user ID, อีเมล และบางครั้งก็ scopes — อย่าวางลงในเครื่องมือฝั่งเซิร์ฟเวอร์เด็ดขาด เครื่องมือของ iKit ทำงานเป็น JavaScript ในเบราว์เซอร์ ตรวจสอบได้ใน DevTools → Network

รู้สถานะการหมดอายุ

Claims มาตรฐานอย่าง exp, nbf, iat จะถูกไฮไลต์พร้อมวันที่ที่อ่านง่าย และป้าย EXPIRED / valid ที่ชัดเจน เพื่อให้รู้ทันทีว่าโทเคนยังใช้ได้หรือไม่

มาตรฐานเปิด โค้ดเปิด

สร้างบน Web Crypto API และตัวแปลง JSON ของเบราว์เซอร์ — อัลกอริทึมเดียวกับ OpenSSL, libjwt, jose พฤติกรรมตรงกับไลบรารี JWT สมัยใหม่ทุกตัว

การถอดรหัส JWT ทำงานอย่างไร

JWT คือสามส่วนของ JSON ที่เข้ารหัสแบบ base64url คั่นด้วยจุด — แค่นั้นเอง

  1. 1

    แยกที่จุดสองจุด

    JWT มีหน้าตาเหมือน aaa.bbb.ccc เราแยกที่จุดสองจุด ได้ header, payload และ signature ที่เข้ารหัสแล้ว ถ้าไม่ได้สามส่วนพอดี โทเคนจะถือว่าผิดรูปแบบ

  2. 2

    ถอดรหัส Base64URL แต่ละส่วน

    Header และ payload เป็น JSON UTF-8 ที่เข้ารหัสแบบ base64url Base64URL = Base64 ที่ใช้ -/_ แทน +//= และไม่มี padding เราใช้ atob หลังจากแทนที่อักขระกลับ แล้ว JSON.parse สตริงที่ได้

  3. 3

    แสดงผลแบบมีโครงสร้าง

    Header บอกอัลกอริทึม (alg: HS256, RS256, ฯลฯ) และประเภท Payload มี claims — มาตรฐาน (iss, sub, aud, exp, iat, nbf, jti) บวกกับฟิลด์กำหนดเองอื่น ๆ เราแสดงแต่ละส่วนในส่วนที่มีป้ายกำกับ

  4. 4

    ตรวจสอบ (HMAC เท่านั้น)

    สำหรับ HS256/384/512 เราคำนวณ HMAC ของ header.payload ใหม่ด้วย secret ที่คุณพิมพ์ แล้วเปรียบเทียบกับ signature ในส่วนที่สาม เหมือน HMAC(SHA-256, secret, signing_input) ที่เข้ารหัสแบบ base64url ตรงกัน = signature ถูกต้อง

งานดีบัก JWT ที่พบบ่อย

สถานการณ์จริงที่คุณจะหยิบ JWT decoder มาใช้

ตรวจดูโทเคนจาก auth provider

Auth0, Firebase, Keycloak, AWS Cognito ล้วนคืน JWT หลังล็อกอิน วาง access_token เพื่อดูว่าแอปได้รับ claims อะไรบ้าง — user ID อะไร scopes อะไร หมดอายุเมื่อไหร่?

ดีบัก 401 Unauthorized

API ปฏิเสธ request ของคุณ? ถอดรหัสโทเคนเพื่อตรวจสอบ: หมดอายุหรือยัง (exp เป็นอดีต)? Audience claim (aud) ตรงกับที่ API คาดหวังไหม? Issuer (iss) เป็น tenant ที่ถูกต้องไหม?

ตรวจสอบลายเซ็น webhook

Stripe, GitHub Apps, Slack ส่ง payload ของ webhook ที่เซ็นเป็น JWT หลังจากได้รับ ให้วางใน Decode mode พร้อม shared secret เพื่อยืนยันว่า request มาจากพวกเขาจริง

สร้างโทเคนสำหรับทดสอบ

ต้องการ JWT ใหม่ที่เซ็นแล้วสำหรับ integration test? สลับไปโหมด Encode แก้ payload (user ID กำหนดเอง, expiry กำหนดเอง) เลือก HS256 + secret สำหรับทดสอบ ได้โทเคนในไม่กี่มิลลิวินาที ไม่ต้องวิ่งไปหา backend

ทำไมการถอดรหัส JWT ในเครื่องจึงสำคัญ

JWT มักพก user ID, อีเมล, scopes และบางครั้งก็เทียบเท่า session cookie — เป็นข้อมูลที่คุณไม่ควรวางลงในเซิร์ฟเวอร์ของคนแปลกหน้าเด็ดขาด เครื่องมือถอดรหัสของ iKit ทำงานเป็น JavaScript ที่โหลดไว้ในแท็บเบราว์เซอร์ของคุณแล้ว ตรวจสอบได้ใน DevTools → Network: ไม่มี fetch, XHR หรือ beacon ระหว่างการถอดรหัสหรือตรวจสอบ

  • ไม่มี request เครือข่ายระหว่างถอดรหัสหรือตรวจสอบ — ตรวจสอบได้ใน DevTools
  • Secret ที่คุณพิมพ์เพื่อตรวจสอบจะอยู่ในหน่วยความจำเบราว์เซอร์ และถูกล้างเมื่อกด Clear / รีเฟรช
  • ปลอดภัยสำหรับโทเคน production, access token ของลูกค้า และ secret ของ webhook

คู่มือที่เกี่ยวข้อง

บทความเชิงลึกและการเปรียบเทียบเครื่องมือจากบล็อก iKit

คำถามที่พบบ่อย

ปลอดภัยไหม JWT ของฉันถูกอัปโหลดหรือเปล่า?

ไม่ครับ เครื่องมือทั้งหมดเป็น JavaScript ในหน้านี้ วางโทเคน การถอดรหัสเกิดในเบราว์เซอร์ ข้อมูลไม่ออกจากแท็บ เปิด DevTools → Network แล้วดูได้ — ไม่มี request ใดถูกส่งระหว่างถอดรหัสหรือตรวจสอบ ปลอดภัยพอที่จะวางโทเคนของลูกค้าจริงหรือ production ได้

Signature ของ JWT ตรวจสอบอะไรกันแน่?

มันพิสูจน์ว่าโทเคนถูกเซ็นโดยผู้ที่ถือ secret (HMAC) หรือ private key (RSA/ECDSA) มันไม่ได้เข้ารหัส payload — header และ payload เป็นแค่ JSON ที่เข้ารหัสแบบ base64url ใครมีโทเคนก็อ่านได้ Signature เพียงป้องกันการดัดแปลง: หากเปลี่ยน payload แม้แต่ไบต์เดียว signature จะไม่ตรงกันอีกต่อไป

ทำไม payload ที่ถอดรหัสดูปกติ แต่การตรวจสอบล้มเหลว?

สาเหตุที่พบบ่อยมีสามข้อ: (1) secret ผิด — secret ของ JWT แยกตัวพิมพ์เล็ก-ใหญ่ และช่องว่างที่ไม่ตรงจะทำให้ตรวจสอบล้มเหลว (2) อัลกอริทึมไม่ตรงกัน — header ระบุ HS256 แต่ secret ถูกใช้กับ HS512 ตอนแรก (3) โทเคนถูกแก้ไขหลังเซ็น — แม้แต่ไบต์เดียวก็ทำให้ signature เสีย ตรวจสอบว่า header.alg ตรงกับที่คาดไว้

แล้ว RS256, ES256 และอัลกอริทึม public-key อื่น ๆ ล่ะ?

ตอนนี้ iKit รองรับการตรวจสอบ HMAC (HS256/384/512) เท่านั้น RS256 และ ES256 ใช้คริปโตแบบ public-key — การตรวจสอบต้องใช้ public key ของผู้ออกในรูปแบบ PEM ซึ่งต้องการ UI ที่ซับซ้อนกว่า ตอนนี้การถอดรหัสยังใช้งานได้ (ส่วน header/payload/signature แสดงถูกต้อง) แต่ปุ่ม Verify จะแจ้งว่าไม่รองรับ การตรวจสอบ RSA/ECDSA อยู่ในแผนพัฒนา

ต่างจาก jwt.io อย่างไร?

แนวคิดเดียวกัน แต่ค่าเริ่มต้นต่างกัน เครื่องมือของ iKit ทำงานในเบราว์เซอร์ทั้งหมด (jwt.io ก็เช่นกัน แต่โค้ดของ iKit เปิดให้ดูผ่าน view-source และโดเมนของเราไม่มี tracker ของบุคคลที่สาม) เราเพิ่มป้าย EXPIRED / valid ที่ชัดเจนสำหรับ exp claim, บันทึก claim แบบมีโครงสร้าง (iat / nbf / iss / sub / aud / jti เป็นแถวที่อ่านง่าย) และปุ่มคัดลอกทั้งหมดที่ถอดรหัสแล้ว เพื่อให้คุณวางลงในรายงานบั๊กได้