Libreng Converter
JWT Token Decoder
I-decode ang header at payload ng JWT (JSON Web Token) kaagad sa iyong browser. Libre, pribado, at panig ng kliyente — walang data na ipinadala sa anumang server.
I-decode ang header at payload ng JWT (JSON Web Token) kaagad sa iyong browser. Libre, pribado, at panig ng kliyente — walang data na ipinadala sa anumang server.
Ang JSON Web Tokens (JWT) ay isang compact, URL-safe na format para sa pagpapadala ng mga claim sa pagitan ng dalawang partido, na tinukoy ng RFC 7519. Ang JWT ay tatlong base64url-encoded segment na pinaghihiwalay ng mga tuldok: header (algorithm at token type), payload (claims), at signature (cryptographic proof of authenticity). Ang header at payload ay JSON, base64url-encoded para sa kaligtasan ng URL; ang lagda ay gumagamit ng isa sa ilang mga algorithm (HS256, RS256, ES256, at iba pa) sa ibabaw ng naka-encode na header at payload.
Ang pag-decode ng JWT — paghahati-hati nito sa mga segment at base64-decoding bawat isa — ay hindi nangangailangan ng anumang lihim. Maaaring basahin ng sinumang may token text ang header at payload nito. Ang lagda, gayunpaman, ay maaari lamang ma-verify gamit ang sikreto (HMAC) o pampublikong susi (asymmetric). Ang pag-decode ay para sa inspeksyon; ang pagpapatunay ay ang nagpapatunay ng pagiging tunay.
Hinahati ng decoder na ito ang token, bina-decode ng base64 ang bawat segment, pina-parse ang header at payload bilang JSON, at ipinapakita ang resulta. Hindi nito sinusubukan ang pag-verify ng lagda dahil nangangailangan iyon ng sikreto o pampublikong susi, na wala ang decoder. Ang na-decode na output ay read-only na inspeksyon — kapaki-pakinabang para sa pag-debug ng mga token ngunit hindi isang kapalit para sa wastong pag-verify sa application code.
Ang pag-debug sa mga isyu sa pagpapatotoo ay halos palaging nagsasangkot ng pagsisiyasat ng mga token. Ang isang token na mukhang wasto sa code ay maaaring may mga maling claim, isang hindi inaasahang algorithm, isang nag-expire na exp timestamp, o hindi pagkakatugma ng audience. Ang pag-decode ng token ay nagpapakita kung ano mismo ang ginawa ng nagbigay.
Nakakatulong din ang pag-inspeksyon sa mga token sa panahon ng integration work. Kapag kumokonekta sa isang third-party na API o provider ng pagkakakilanlan, ang aktwal na mga pangalan ng claim, format, at istraktura ay pinakamahusay na nauunawaan sa pamamagitan ng pag-decode ng mga sample na token sa halip na umasa sa dokumentasyong maaaring luma na.
Idikit ang token, kunin ang mga na-parse na nilalaman.
Ang format ng JWT ay tatlong segment na pinagsama ng mga tuldok. Ang bawat segment ay base64url-encoded — ang URL-safe na variant ng base64 na gumagamit ng - at _ sa halip na + at /, kung minsan ay inalis ang padding. Ang pag-decode ay nangangailangan ng pag-undo sa mga pamalit na ligtas sa URL, padding sa segment, at base64-decoding.
Ang header at payload ay JSON pagkatapos mag-decode. Ang signature segment ay binary (raw signature bytes) at hindi nababasa ng tao; kailangan nito ang verification key upang maging kapaki-pakinabang.
Mga karaniwang claim na tinukoy sa RFC 7519: iss (issuer), sub (subject identifier), aud (audience), exp (expiration as Unix epoch seconds), nbf (not-before timestamp), iat (issued-at timestamp), jti (natatanging token ID). Maaaring lumabas ang mga claim na partikular sa application kasama ang anumang pangalan.