Giải mã JWT

Phân tích JSON Web Token trong trình duyệt. Header, payload, expiry. Không cần key, không gửi dữ liệu.

encoding

JWT Decoder

Paste a JWT to decode.

Decoded in your browser. Never store or send JWTs that contain secrets to third-party tools.

What next?

How it works

JWT thực ra là gì

JSON Web Token (RFC 7519) là ba đoạn Base64URL nối bằng dấu chấm:

<header>.<payload>.<signature>

Hai đoạn đầu là JSON object. Đoạn thứ ba là chữ ký nhị phân chứng minh hai đoạn đầu đến từ người giữ key ký. Ai cũng có thể bỏ JWT vào decoder — kể cả tool này — và đọc header với payload. Chỉ người có verification key mới xác nhận được chữ ký.

Coi JWT đã decode là input user không tin được trừ khi bạn cũng đã verify chữ ký. Tool này chỉ decode — chủ ý không hỏi key, vì paste HMAC secret production lên website lạ là ác mộng bảo mật.

Header chứa gì

Thường hai field:

  • alg — thuật toán ký (HS256, RS256, ES256, v.v.).
  • typ — thường là "JWT".

Đôi khi sẽ thấy kid (key ID) khi issuer rotate key, hoặc x5t khi liên quan X.509. Khác đi là implementation-specific.

Payload chứa gì (các claim)

Payload chỉ là một object. RFC 7519 dành một số tên field chuẩn:

| Claim | Ý nghĩa | |---|---| | iss | Issuer (ai tạo token) | | sub | Subject (user hoặc thực thể token đại diện) | | aud | Audience (token dành cho ai) | | exp | Expiration (Unix timestamp giây) | | iat | Issued-at (Unix timestamp giây) | | nbf | Not-before (token không hợp lệ trước thời điểm này) | | jti | Token ID (cho revocation list) | | scope / scp | OAuth scope |

Ngoài ra issuer thoải mái thêm claim tùy ý: user ID, role, plan tier, gì cũng được. Tool này highlight các claim chuẩn và hiển thị trạng thái expiry ngay đầu.

Thảm họa alg=none

Lịch sử, các library JWT chấp nhận token với "alg": "none" và coi như đã được xác thực. Kết hợp việc ai cũng tạo header được, attacker có thể forge token bỏ qua verification hoàn toàn.

Library hiện đại từ chối none mặc định, nhưng bài học còn nguyên: luôn verify với algorithm mong đợi rõ ràng, đừng tin algorithm khai trong header. Nếu library có option algorithms: ['RS256'], set nó.

HS256 vs RS256

HS256 là đối xứng — cùng secret để ký và verify. Nhanh, đơn giản, nhưng verifier phải có secret, nghĩa là cũng có thể forge token. Dùng cho service first-party tin tưởng hoàn toàn nhau.

RS256 (và ES256) là bất đối xứng — private key ký, public key verify. Verifier chỉ nhận public key nên không forge được. Dùng cho token vượt biên giới tin tưởng (API thứ ba, distributed service).

Use case phổ biến

  • Token xác thực sau login (thường qua OAuth2 / OIDC).
  • Token truy cập API cho gọi service-to-service stateless.
  • Magic link cho passwordless email login.
  • Verify emailreset password.
  • Webhook signature (ít gặp hơn; HMAC trần thông dụng hơn).

Quyền riêng tư trên trang này

Tool decode trong browser qua Base64URL + JSON.parse. Chúng tôi không lưu token, không log request, không có server endpoint để gửi tới. Mở DevTools Network và xem — zero traffic.

Nếu token chứa secret production thật, ưu tiên decode local bằng CLI như jq. Decoder công khai (kể cả cái này) tiện nhưng không phù hợp cho credential live.

Công cụ liên quan

  • Base64 Encode — xem từng segment trông như thế nào trước/sau.
  • Hash Generator — tính HMAC thủ công để verify HS256.

FAQ

Paste JWT vào decoder có an toàn không?

Decode header và payload an toàn theo nghĩa chúng vốn được thiết kế để đọc được. Nhưng nếu token cấp quyền tới thứ gì đó thật, coi hành động paste vào tool thứ ba như credential bị lộ — giả định operator của tool (hoặc ai có network access giữa bạn và họ) giờ có nó. Decode token production bằng jq hoặc IDE của bạn thay thế.

Vì sao tool này không verify chữ ký?

Để verify, chúng tôi cần signing key (HS256) hoặc public key (RS256). Hỏi key trong tool browser là cờ đỏ to. Verification thuộc về code ứng dụng dùng library đã được kiểm chứng, không phải trang web công khai.

Vì sao token của tôi có ký tự =?

Không nên — JWT dùng Base64URL bỏ padding. Nếu thấy =, token có lẽ đã được re-encode đâu đó dưới dạng Base64 chuẩn. Hầu hết decoder (tool này included) khoan dung, nhưng JWT đúng spec không nên có.

Lỗ hổng alg=none là gì?

Library cũ chấp nhận token khai báo "alg": "none" ở header và bỏ qua verify chữ ký hoàn toàn. Attacker khai thác bằng cách forge payload bất kỳ. Cách fix là validate với danh sách algorithm cho phép rõ ràng trong verifier — đừng tin field alg trong header.

HS256 hay RS256?

Đối xứng (HS256) khi cả hai bên tin nhau hoàn toàn và share secret được. Bất đối xứng (RS256/ES256) khi không muốn verifier có khả năng forge, hoặc key vượt biên giới tin tưởng.

Revoke JWT thế nào?

Không thể trực tiếp — JWT stateless. Cách workaround: giữ token ngắn hạn và dùng refresh token; duy trì blocklist server-side theo jti; hoặc dùng opaque token với session server-side thay vì JWT.

exp và nbf khác nhau gì?

exp là thời điểm muộn nhất token hợp lệ (sau đó expire). nbf là thời điểm sớm nhất hợp lệ (trước đó không nên chấp nhận). Cả hai là Unix timestamp giây. iat là thời điểm issue token — thông tin.