§

I-paste ang iyong JWT

Parehong pag-parse at signature verification ay tumatakbo nang lokal. Walang anumang tungkol sa token ang ipinapadala sa server.
§

Header

json
§

Payload

json
§

Mag-verify ng signature

Maglagay ng secret para ma-verify ang signature.

Ang mga JSON Web Token ay sentro sa digital banking at e-wallet ecosystem ng Pilipinas. Ang mga sistema ng GCash, Maya (PayMaya), at UnionBank Online ay gumagamit ng JWT para sa authentication sa ilalim ng mga BSP-regulated na API pattern para sa InstaPay at PESONet transactions. Ang mga developer na nagtatayo ng mga Open Finance Pilipinas integration ay regular na naga-inspect ng JWT header at payload para ma-validate ang mga `iss`, `aud`, at `exp` claim ng BSP-accredited na mga institusyon. Ang decoder na ito ay nagse-split ng tatlong Base64URL segment sa loob ng browser, nagpapakita ng header, payload, at signature, at dino-decode ang mga standard na claim tulad ng `exp`, `iat`, at `nbf` — nang hindi lumalabas ang iyong bearer token sa tab.

// Mga Kaugnay na Tool

./base64-decoder
Base64 Decoder
Mag-inspect ng base64url-encoded header at payload segment sa labas ng JWT envelope.
→
./url-decoder
URL Decoder
Kunin ang mga JWT mula sa percent-encoded query string at redirect URL.
→
./json-formatter
JSON Formatter
Mag-pretty-print at mag-validate ng decoded payload bilang standalone na JSON.
→
./
Lahat ng Tool
I-browse ang buong koleksyon ng mga online tool ng Ultim8Soft.
→

Ano ang JSON Web Token?

Ang isang JSON Web Token (JWT) ay isang compact, URL-safe envelope para sa isang maliit na claims payload. Ito ang standard na credential format para sa mga stateless na web session, OAuth/OIDC ID token, machine-to-machine API auth, at mga signed magic link. Ang isang JWT ay palaging tatlong base64url segment na pinagsama ng mga tuldok: header.payload.signature. Ang header at payload ay JSON; ang signature ay isang binary MAC o digital signature sa unang dalawang segment.

Paano gumagana ang mga JWT?

Kapag na-decode ng tool na ito ang isang token, sinusundan nito ang parehong tatlong hakbang na sinusundan ng bawat JWT library:

  1. Hatiin ang token sa mga tuldok sa eksaktong tatlong hindi walang laman na segment. Ang anumang iba pang hugis ay malformed.
  2. Base64url-decode ang mga segment 0 at 1, pagkatapos ay JSON.parse ang bawat isa. Ang header ay nagdadala ng algorithm (alg) at token type (typ). Ang payload ay nagdadala ng mga claim (sub, exp, iat, mga custom na key).
  3. Kung may ibinigay na secret, muling kalkulahin ang MAC sa <segment0>.<segment1> gamit ang algorithm sa header. Ikumpara ang mga byte laban sa ikatlong segment.
  4. Ipakita ang resulta ng verification kasama ang mga decoded na claim, kabilang ang isang human-readable na expiry indicator na kinakalkula mula sa exp claim.

Bakit mag-decode ng JWT sa browser?

Ang pag-paste ng isang tunay, ginagamit na JWT sa isang remote debugger ay nagle-leak ng kredensyal sa mga log ng serbisyong iyon, observability stack, at anumang kasosyo na pinapadala ng serbisyo ng data. Kahit na sinasabing hindi nagla-log ng mga token ang third-party site, wala kang paraan para ma-verify ito. Ang tool na ito ay ginawa para hindi mo na kailangang gawin ang kompromisong iyon:

  • Zero network: ang runtime ay walang tawag ng fetch, XMLHttpRequest, o sendBeacon. Buksan ang DevTools habang nag-de-decode at nag-ve-verify — mananatiling tahimik ang Network panel.
  • Native Web Crypto: gumagamit ang HMAC verification ng crypto.subtle.importKey at crypto.subtle.sign, ang parehong primitive na tatawagan ng iyong runtime.
  • Static na deploy: ang bawat pahina ay isang single static HTML file na walang server endpoint na maaaring ikompromiso. Walang token na maaaring ma-leak dahil walang server na magle-leak nito.

Ano ang bini-verify ng tool na ito, at ano ang hindi?

Ang Bersyon 1 ng tool na ito ay nagve-verify ng HMAC-SHA family signature lamang. Konkretamente:

  • Sinusuportahan: HS256, HS384, HS512. Ibigay ang shared secret at muling kalkulahin at ikukumpara ng tool ang MAC.
  • Hindi pa sinusuportahan: RS256/384/512 (RSA), ES256/384/512 (ECDSA), EdDSA, at PS256/384/512 (RSA-PSS). Nangangailangan ang mga ito ng public key sa PEM o JWK form at sinadyang ipinagpaliban sa isang follow-up na release.
  • Tinanggihan: alg: "none". Na-decode ng tool ang token ngunit hayagang binabandera ito bilang hindi ligtas — walang signature validation na nangyayari, at ang anumang production system na tumatanggap ng gayong token ay may seryosong kahinaan.

Ano ang hitsura ng isang halimbawa ng JWT decoding?

I-paste ang canonical RFC 7519 example token sa input field sa itaas:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Ang header ay nag-de-decode sa {"alg":"HS256","typ":"JWT"} at ang payload sa {"sub":"1234567890","name":"John Doe","iat":1516239022}. Ilagay ang your-256-bit-secret sa verify panel at ang signature check ay nagbabalik ng valid. Baguhin ang isang character ng secret at nagbabalik ito ng invalid. Walang anuman sa ito ang lumalabas sa iyong browser.

Ito ang JWT decoder na gusto sana naming mayroon nang una namin kailangang mag-debug ng token sa production: privacy-respecting, mabilis, at ginawa sa parehong primitive na ginagamit ng runtime.