Skip to content

JWT Decoder

Dekode token JWT online dengan dekoder JWT gratis kami. Periksa header, payload, tanda tangan, kedaluwarsa, dan klaim secara instan. 100% browser — token Anda tidak meninggalkan perangkat. Tanpa pendaftaran, tanpa pelacakan.

Tanpa Pelacakan Berjalan di Browser Gratis
Token JWT
Ditinjau untuk kepatuhan RFC 7519 dan jaminan privasi — Go Tools Security Team · Apr 22, 2026

Apa Itu JWT?

JSON Web Token, atau JWT (dibaca 'jot'), adalah format token ringkas dan URL-safe untuk membawa klaim antara dua pihak. Ia didefinisikan dalam RFC 7519 dan merupakan format kredensial dominan yang dipakai access token OAuth 2.0, ID token OpenID Connect, API key di penyedia auth modern (Auth0, Okta, Clerk, Supabase, Firebase), serta token antar layanan di arsitektur microservice.

"JSON Web Token (JWT) is a compact claims representation format intended for space-constrained environments such as HTTP Authorization headers and URI query parameters." — RFC 7519, Section 1

JWT adalah tiga objek JSON ber-encode Base64URL yang digabungkan dengan titik: header.payload.signature. Header menjelaskan bagaimana token ditandatangani (klaim alg — misalnya HS256 atau RS256 — dan klaim typ, biasanya 'JWT'). Payload membawa klaim: klaim terdaftar seperti iss, sub, aud, exp, iat, ditambah klaim kustom apa pun yang dibutuhkan issuer (role, scope, email, tenant ID). Tanda tangan adalah bukti kriptografis, yang dihitung dari header dan payload dengan secret atau private key issuer, yang memungkinkan penerima mendeteksi manipulasi.

Penting dicatat, JWT di-encode, bukan dienkripsi. Siapa pun yang memegang token bisa membaca payload-nya — mendekodenya hanya butuh parsing Base64URL dan JSON. Jaminan keamanan datang dari tanda tangan: penyerang bisa membaca JWT, tetapi tidak bisa memproduksi JWT berbeda yang lolos verifikasi tanda tangan tanpa signing key. Itulah mengapa JWT aman dikirim lewat jaringan, tetapi tidak aman diisi dengan rahasia.

JWT decoder menunjukkan dengan tepat apa yang dikandung sebuah token — algoritma, klaim, kedaluwarsa — tanpa menyentuh tanda tangan. Ini cara tercepat untuk menjawab 'apakah token ini kedaluwarsa?', 'apa role pengguna ini?', 'issuer mana yang mencetak token ini?', atau 'apakah ini token alg:none yang harus saya tolak?'. Semua decoding di alat ini berjalan secara lokal di browser Anda, sehingga menempel token production aktif pun aman.

Pekerjaan dengan JWT sering berpasangan dengan alat developer lain. Anda mungkin perlu mendekode segmen yang terbungkus Base64URL saat menelusuri token yang rusak, mendekode URL dari header Authorization setelah menangkapnya dari proxy, atau mengonversi klaim exp ke tanggal yang dibaca manusia secara manual. Untuk penjelasan mendalam tentang bagaimana JWT ditandatangani, diverifikasi, dan dirotasi di production, lihat panduan dasar Base64 kami — Base64URL adalah fondasi yang menopang setiap JWT.

// Decode a JWT in the browser — header & payload only
function decodeJwt(token) {
  const [h, p, s] = token.split('.');
  const pad = (seg) => seg + '==='.slice((seg.length + 3) % 4);
  const decode = (seg) => JSON.parse(
    atob(pad(seg).replace(/-/g, '+').replace(/_/g, '/'))
  );
  return { header: decode(h), payload: decode(p), signature: s };
}

const { header, payload } = decodeJwt(token);
console.log(header);   // → { alg: 'HS256', typ: 'JWT' }
console.log(payload);  // → { sub: 'user_123', exp: 1999999999, ... }

// Expiration check
const expired = payload.exp * 1000 < Date.now();

Fitur Utama

Dekode JWT Secara Instan

Tempel dan lihat JWT didekode secara real-time — header, payload, dan tanda tangan di-parse saat itu juga. Tanpa tombol Decode, tanpa perjalanan bolak-balik ke server.

Deteksi Kedaluwarsa

Otomatis membaca klaim exp dan menampilkan badge merah saat token kedaluwarsa, lengkap dengan tanggal kedaluwarsa persis di zona waktu lokal Anda.

Agnostik Terhadap Algoritma

Mendekode setiap algoritma JWS — HS256/384/512, RS256/384/512, PS256/384/512, ES256/384/512, EdDSA, dan alg:none.

100% Lokal

Decoding berjalan di browser Anda lewat atob dan JSON.parse bawaan. Token Anda tidak pernah diunggah — aman untuk kredensial production.

Tampilan Sadar Klaim

Menyorot klaim terdaftar RFC 7519 (iat, exp, nbf, iss, aud, sub, jti) sehingga Anda bisa menangkap masalah auth sekali pandang.

Salin Sekali Klik

Salin JSON header, JSON payload, atau tanda tangan mentah ke clipboard Anda dengan sekali klik — pas untuk laporan bug dan test.

Contoh

Token HS256 (Valid)

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMyIsIm5hbWUiOiJBbGljZSIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTcxNTAwMDAwMCwiZXhwIjoxOTk5OTk5OTk5fQ.4NhxPjwoZxPNuxG-2C5ugGxaUsUJ0QyskAz7Ymz5Sg0
{
  "alg": "HS256",
  "typ": "JWT"
}

{
  "sub": "user_123",
  "name": "Alice",
  "role": "admin",
  "iat": 1715000000,
  "exp": 1999999999
}

Token yang ditandatangani dengan HMAC-SHA256, berisi subject, role, dan waktu kedaluwarsa di masa depan — konfigurasi JWT paling umum untuk autentikasi sesi.

Token RS256 (Kedaluwarsa)

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImtleS0yMDI1LTAxIn0.eyJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJhdWQiOiJhcGkuZXhhbXBsZS5jb20iLCJzdWIiOiI5MDA4NzE2NSIsImlhdCI6MTYwMDAwMDAwMCwiZXhwIjoxNjAwMDAzNjAwLCJzY29wZSI6InJlYWQ6dXNlciB3cml0ZTpwb3N0In0.signature_placeholder
{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "key-2025-01"
}

{
  "iss": "https://auth.example.com",
  "aud": "api.example.com",
  "sub": "90087165",
  "iat": 1600000000,
  "exp": 1600003600,
  "scope": "read:user write:post"
}

Access token bergaya OAuth yang ditandatangani dengan RSA — perhatikan kid (key ID) di header dan klaim exp yang menunjukkan token sudah kedaluwarsa.

ID Token OIDC

eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2FjY291bnRzLmdvb2dsZS5jb20iLCJzdWIiOiIxMTA1MDIyNTExNTU4OTkwNzY2Mzk1IiwiYXpwIjoiY2xpZW50LWlkIiwiYXVkIjoiY2xpZW50LWlkIiwiZW1haWwiOiJhbGljZUBleGFtcGxlLmNvbSIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJpYXQiOjE3MTUwMDAwMDAsImV4cCI6MTk5OTk5OTk5OSwibm9uY2UiOiJhYmMxMjMifQ.signature
{
  "alg": "ES256",
  "typ": "JWT"
}

{
  "iss": "https://accounts.google.com",
  "sub": "110502251155899076639",
  "azp": "client-id",
  "aud": "client-id",
  "email": "alice@example.com",
  "email_verified": true,
  "iat": 1715000000,
  "exp": 1999999999,
  "nonce": "abc123"
}

ID token OpenID Connect dengan tanda tangan ECDSA, klaim email, dan nonce untuk proteksi terhadap replay attack.

Token Alg: none (Tanpa Tanda Tangan)

eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJkZWJ1Zy11c2VyIiwiaWF0IjoxNzE1MDAwMDAwfQ.
{
  "alg": "none",
  "typ": "JWT"
}

{
  "sub": "debug-user",
  "iat": 1715000000
}

Token tanpa tanda tangan dengan alg:none. Menerima token seperti ini di production adalah kerentanan JWT klasik — selalu tolak alg:none di sisi server.

Cara Menggunakan

  1. 1

    Tempel JWT Anda untuk Didekode

    Tempel token lengkap yang akan didekode — termasuk tiga segmen yang dipisahkan titik — ke kotak input. Dekoder berjalan instan di browser Anda; Anda tidak perlu mengklik tombol.

  2. 2

    Baca Header, Payload & Status yang Didekode

    Baca algoritma dan tipe token di header yang didekode, klaim di payload yang didekode, serta chip kedaluwarsa / waktu penerbitan di bagian atas. Token kedaluwarsa ditandai warna merah.

  3. 3

    Salin Hasil yang Didekode

    Gunakan tombol Salin di setiap panel untuk menyalin JSON header yang didekode, JSON payload yang didekode, atau tanda tangan mentah. Token Anda tidak pernah dikirim ke mana pun — decoding terjadi secara lokal di browser Anda.

Common Errors

Menerima alg:none

JWT tanpa tanda tangan bisa dipalsukan siapa saja. Jangan pernah mengizinkan alg:none di production — selalu berikan daftar algoritma eksplisit ke panggilan verify Anda.

✗ Salah
jwt.verify(token, secret)  // library default may allow 'none'
✓ Benar
jwt.verify(token, secret, { algorithms: ['RS256'] })

Klaim exp Hilang

JWT tanpa exp akan berlaku selamanya. Jika suatu saat token bocor, tidak ada titik pencabutan alami. Selalu setel kedaluwarsa yang sesuai dengan tipe token.

✗ Salah
{ "sub": "user_123", "role": "admin" }  // no exp
✓ Benar
{ "sub": "user_123", "role": "admin", "exp": 1715003600 }

Menyimpan Rahasia di Payload

Payload JWT tidak dienkripsi — siapa pun yang memegang token bisa membacanya. Jangan pernah menaruh password, API key, atau PII utuh di dalam payload JWT.

✗ Salah
{ "sub": "user_123", "password": "hunter2" }
✓ Benar
{ "sub": "user_123", "role": "admin" }  // payload stays minimal

Kasus Penggunaan Umum

Dekode Token Authorization Bearer
Dekode token JWT dari header Authorization: Bearer untuk memverifikasi klaim, audience, dan kedaluwarsa yang diterima backend Anda.
Dekode Token OAuth 2.0 & OIDC
Dekode access token dan ID token yang dikembalikan server otorisasi (Auth0, Okta, Google, Keycloak) saat integrasi OAuth 2.0 dan OpenID Connect.
Diagnosis Sesi Kedaluwarsa
Pastikan dalam satu detik apakah token yang ditolak kedaluwarsa, memakai audience yang salah, atau bermasalah clock skew.
Pemeriksaan Key Rotation
Baca kid (key ID) di header untuk memverifikasi bahwa rotasi JWKS Anda menerbitkan token yang ditandatangani dengan key yang diharapkan.
Security Review
Tangkap token yang ditandatangani dengan alg:none, tanpa exp, atau membocorkan PII di payload saat code review dan pentest.
Inspeksi Token Microservice
Dekode token service-to-service di dalam mesh untuk melihat scope dan subject apa yang diotorisasi panggilan downstream.

Detail Teknis

Sesuai RFC 7519
Menangani token JWS yang sesuai RFC 7519 (JWT), RFC 7515 (JWS), dan RFC 7518 (JWA) — semua algoritma terdaftar didukung untuk decoding.
Decoding Base64URL
Memakai alfabet Base64 yang URL-safe (- dan _ menggantikan + dan /) seperti didefinisikan di RFC 4648, dengan parsing yang toleran terhadap padding.
Native Browser, Tanpa Dependensi
Dibangun di atas atob, TextDecoder, dan JSON.parse bawaan browser — tanpa library eksternal, tanpa panggilan jaringan, tanpa telemetri.

Praktik Terbaik

Jangan Pernah Percaya Tanpa Verifikasi
Decoder menampilkan klaim; ia tidak membuktikannya. Selalu verifikasi tanda tangan di sisi server terhadap key issuer sebelum mempercayai klaim apa pun.
Tolak alg:none di Production
Konfigurasikan library JWT Anda dengan allowlist algoritma yang eksplisit. Jangan pernah menerima alg:none, dan curigai ketidakcocokan alg pada rotasi key.
Jaga Payload Tetap Ramping
Taruh identifier dan klaim berumur pendek di JWT; simpan data besar di balik session ID opaque. Token besar memakan bandwidth di setiap request.

Pertanyaan yang Sering Diajukan

Bagaimana cara mendekode token JWT secara online?
Tempelkan JWT lengkap — ketiga segmen yang dipisahkan titik (header.payload.signature) — ke dekoder di atas. Proses dekode berlangsung instan di browser Anda: header dan payload didekode dari Base64URL menjadi JSON yang bisa dibaca, dan tanda tangan ditampilkan sebagai string mentah. Baris status memunculkan algoritma tanda tangan, waktu penerbitan, dan kedaluwarsa, sehingga Anda bisa langsung mengenali token yang kedaluwarsa. Untuk mendekode JWT secara manual, pecah token berdasarkan titik, dekode dua segmen pertama dengan Base64URL, lalu parse sebagai JSON — siapa pun yang memegang token bisa membaca klaim-nya karena payload di-encode, bukan dienkripsi. Dekoder ini aman dipakai dengan token production karena tidak ada data yang keluar dari perangkat Anda: tanpa permintaan jaringan, tanpa pencatatan, tanpa pelacakan.
Apa itu JWT (JSON Web Token)?
JSON Web Token (JWT) adalah kredensial ringkas dan URL-safe yang membawa klaim antara dua pihak. Didefinisikan dalam RFC 7519, JWT terdiri dari tiga bagian ber-encode Base64URL yang dipisahkan titik: header (algoritma dan tipe token), payload (klaim — data tentang pengguna dan token itu sendiri), dan tanda tangan (bukti kriptografis bahwa token diterbitkan oleh pihak tepercaya). JWT adalah cara standar untuk merepresentasikan access token di OAuth 2.0 dan ID token di OpenID Connect.
Apakah token saya aman saat menggunakan JWT decoder ini?
Ya. Semua proses decoding berjalan di browser Anda menggunakan JavaScript bawaan (atob dan TextDecoder). Token Anda tidak pernah dikirim ke server, tidak pernah dicatat, tidak pernah disimpan, dan tidak pernah dipakai untuk analitik. Tidak ada cookie dan tidak ada pelacakan. Ini penting karena JWT bisa berisi access token aktif — menempelkannya ke debugger jarak jauh sama saja dengan menyerahkan kredensial. Alat kami aman dipakai dengan token production.
Bagaimana cara kerja JWT decoder?
JWT decoder memecah token berdasarkan titik menjadi tiga bagian, mendekode header dan payload dari Base64URL, lalu mem-parse keduanya sebagai JSON. Tanda tangan dibiarkan sebagai string Base64URL apa adanya karena memverifikasinya membutuhkan secret atau public key dari issuer — sesuatu yang tidak bisa dilakukan decoder sisi klien dengan aman. Artinya, decoding berlangsung instan dan menampilkan klaim, tetapi Anda harus memverifikasi tanda tangan di sisi server dengan key yang benar sebelum mempercayai isinya.
Apakah alat ini bisa memverifikasi tanda tangan JWT?
Tidak, dan ini memang disengaja. Verifikasi tanda tangan membutuhkan secret issuer (untuk HMAC) atau public key (untuk RSA/ECDSA/EdDSA), yang tidak pernah boleh ditempel ke alat web publik. Verifikasi harus terjadi di server Anda, di middleware auth, atau di dalam SDK yang memiliki akses ke endpoint JWKS Anda. Decoder ini dibuat untuk memeriksa apa yang diklaim sebuah token — bukan untuk membuktikan bahwa token tersebut asli atau tidak diubah-ubah.
Apa itu iat, exp, nbf, iss, aud, sub, dan jti?
Ini adalah klaim terdaftar (registered claims) dari RFC 7519. iat (issued at) adalah timestamp Unix saat token dibuat. exp (expiration) adalah kapan token berhenti valid — alat ini mengonversinya ke tanggal yang bisa dibaca manusia dan menandai token sebagai kedaluwarsa jika exp sudah lewat. nbf (not before) adalah waktu paling awal token bisa digunakan. iss (issuer) mengidentifikasi siapa yang membuat token. aud (audience) menyebutkan penerima yang dituju. sub (subject) mengidentifikasi principal — biasanya ID pengguna. jti adalah ID token unik untuk mencegah replay. Klaim khusus aplikasi (role, scope, email, name) hidup berdampingan dengan klaim-klaim ini.
JWT saya sudah kedaluwarsa — kenapa decoder tetap mendekodenya?
Mendekode tidak sama dengan memvalidasi. JWT decoder membaca konten terlepas dari status kedaluwarsa, sehingga Anda bisa memeriksa token yang kedaluwarsa atau tidak valid untuk menelusuri kenapa ia ditolak. Badge 'Kedaluwarsa' di alat ini membandingkan klaim exp dengan jam lokal Anda dan menandai token yang exp-nya sudah lewat. Server autentikasi sebenarnya akan langsung menolak token tersebut — tetapi decoder yang menolak menampilkan token kedaluwarsa akan sia-sia untuk debugging.
Apa perbedaan JWT, JWS, dan JWE?
JWT adalah konsep umum — objek JSON yang di-encode sebagai token ringkas. JWS (RFC 7515) adalah JWT yang ditandatangani: payload bisa dibaca siapa saja yang mendekodenya, dan tanda tangan membuktikan bahwa ia tidak dimanipulasi. Ini adalah JWT paling umum yang akan Anda temui. JWE (RFC 7516) adalah JWT yang dienkripsi: payload-nya sendiri berupa ciphertext dan tidak bisa didekode tanpa key dekripsi. Alat ini mendekode token JWS. Token JWE hanya akan terdekode sampai header — payload terenkripsi tidak bisa dibaca tanpa key.
Kenapa alg:none berbahaya?
JWT dengan alg:none tidak punya tanda tangan — siapa pun bisa membuatnya, mengaku sebagai pengguna mana saja. Library JWT awal menerima alg:none secara default, sehingga muncul celah autentikasi terkenal: penyerang menghapus tanda tangan, menyetel alg ke none, dan memalsukan token admin. Kini semua library JWT yang matang menolak alg:none kecuali diizinkan secara eksplisit, dan Anda tidak boleh pernah menerimanya untuk request terautentikasi. Decoder ini tetap akan menampilkan token alg:none karena memeriksanya saat debugging itu sah — tetapi perlakukan token seperti itu yang diterima di production sebagai hostile.
Algoritma apa saja yang didukung JWT decoder ini?
Mendekode header dan payload berhasil untuk setiap algoritma, karena decoding hanya butuh parsing Base64URL dan JSON — sifatnya agnostik terhadap algoritma. Alat ini membaca dengan benar token yang ditandatangani dengan HS256, HS384, HS512 (HMAC), RS256, RS384, RS512 (RSA + SHA), PS256, PS384, PS512 (RSA-PSS), ES256, ES384, ES512 (ECDSA), EdDSA (Ed25519/Ed448), dan token tanpa tanda tangan (alg:none). Hanya verifikasi tanda tangan yang spesifik per algoritma, dan alat ini tidak melakukan verifikasi.
Sebaiknya simpan JWT di localStorage atau cookie?
Pilih cookie HttpOnly, Secure, SameSite=Strict untuk token sesi. Token di localStorage bisa dibaca JavaScript apa pun yang berjalan di halaman, sehingga satu celah XSS saja membocorkan seluruh sesi aktif. Cookie HttpOnly tidak terlihat oleh JavaScript, yang mempersempit dampak XSS pada apa yang bisa dilakukan penyerang di dalam halaman hidup — bukan token yang dicuri dan bisa mereka putar ulang berhari-hari. Jika Anda harus pakai localStorage (misalnya untuk aplikasi lintas domain), jaga masa aktif access token tetap singkat (menit, bukan jam) dan pakai refresh token terpisah di cookie HttpOnly.
Bagaimana cara mendekode JWT di Node.js, Python, atau Go?
Node.js: jsonwebtoken.decode(token) untuk read-only, jsonwebtoken.verify(token, key) untuk verifikasi. Python: PyJWT.decode(token, options={'verify_signature': False}) untuk membaca, berikan key untuk verifikasi. Go: jwt.ParseUnverified(token, claims) untuk read-only, jwt.Parse(token, keyFunc) untuk verifikasi. Di bahasa apa pun, jangan pernah memverifikasi dengan options={'verify_signature': False} di kode production — itu yang dilakukan alat web ini secara sengaja untuk debugging, dan hanya aman saat Anda memeriksa, bukan mengautentikasi.
Berapa ukuran maksimum sebuah JWT?
Standar JWT tidak menetapkan batas keras, tetapi header di sebagian besar web server default sekitar 8 KB. Jaga token di bawah 4 KB agar nyaman masuk di header Authorization dan cookie. Jika token Anda lebih besar dari itu, kemungkinan Anda memasukkan terlalu banyak klaim ke payload — pindahkan data besar ke balik session ID opaque dan ambil dari backend saat dibutuhkan. JWT yang terlalu besar juga mahal di setiap request karena ikut terkirim di setiap panggilan API.
Saya menempel token dan muncul 'Format JWT tidak valid' — apa masalahnya?
JWT yang valid punya tepat tiga bagian yang dipisahkan titik: header.payload.signature. Penyebab umum: (1) Anda tidak sengaja hanya menyalin bagian payload, (2) spasi atau baris baru ikut tertempel di tengah, (3) token terpotong saat transit (sering terjadi karena wrapping terminal), (4) token sebenarnya JWE yang formatnya header.encryptedKey.iv.ciphertext.tag (lima bagian), atau (5) token ter-URL-encode dan Anda perlu mendekode URL-nya dulu. Periksa nilai mentah yang dikembalikan API Anda — kebanyakan editor menampilkan karakter tersembunyi saat di-hover.
Bisakah saya mendekode JWT tanpa secret key?
Bisa — header dan payload di-encode Base64URL, bukan dienkripsi. Siapa pun yang memegang token bisa membaca klaimnya tanpa key apa pun. Ini memang disengaja: payload dibuat agar bisa dibaca supaya penerima bisa mengambil keputusan otorisasi darinya. Secret atau public key hanya dibutuhkan untuk memverifikasi bahwa token tidak dimanipulasi. Karena itulah Anda tidak boleh pernah menaruh data sensitif (password, private key, PII yang belum diketahui penerima) di dalam payload JWT.
JWT saya jalan di Postman tapi ditolak backend — bagaimana cara debugging-nya?
Dekode token di sini lalu cek: (1) exp — apakah masih di masa depan relatif terhadap jam server? Clock skew server sering jadi biang kerok. (2) iss / aud — apakah persis cocok dengan yang diharapkan backend? Ketidakcocokan pada aud adalah false-negative paling umum. (3) alg — apakah kode verifikasi Anda mengizinkan algoritma itu? Token HS256 akan gagal pada library yang dikonfigurasi hanya untuk RS256. (4) kid — jika Anda memakai key rotation, apakah key ID di header ada di JWKS Anda? (5) signature — apakah Anda sudah menempel secret/public key yang benar? Decoder ini menampilkan (1), (2), (3), dan (4) di tampilan header dan payload supaya Anda bisa cepat mengeliminasinya.