A JSON Web Token (JWT) is a compact, URL-safe token format defined in RFC 7519. It consists of three Base64URL-encoded parts separated by dots: header.payload.signature. JWTs are widely used for authentication and information exchange — when you log into a web app, the server typically returns a JWT that your browser sends with every subsequent request to prove your identity.

Is my JWT token sent to a server?

No. The JWT Decoder processes your token entirely in your browser using JavaScript Base64 decoding. Your token — including any session secrets, user IDs, or PII in the payload — never leaves your device. This is critical for security: unlike jwt.io and similar online decoders, you can safely debug production tokens here.

What does the JWT header contain?

The header typically contains two fields: "alg" (the signing algorithm, such as HS256, RS256, ES256, or HS384) and "typ" (the token type, always "JWT"). The algorithm tells you how the signature was created — HS256 means a shared secret, RS256 means an RSA private key. Mismatched algorithms between header and actual signing indicate a potential security issue.

How do I check if a JWT is expired?

The payload contains an "exp" claim (expiration time) as a Unix timestamp in seconds. The decoder converts this to a human-readable date and compares it to the current time. If the token is expired, a red "EXPIRED" badge appears. The payload may also contain "iat" (issued at) and "nbf" (not before) timestamps for full lifecycle validation.

Can this tool verify the JWT signature?

The tool decodes and displays the signature but does not cryptographically verify it — verification requires the secret key (for HMAC) or public key (for RSA/ECDSA), which only the issuing server possesses. However, the tool flags suspicious conditions: weak algorithms (none, HS256 with short keys), expired tokens, and missing required claims.

🔐

JWT Decoder / Debugger

Decode JWT header and payload locally. No token leaves your browser.

100% LOCAL100% localHS256/RS256Expire checkNo upload

Saved Tokens· Auto-save on

▾

Paste JWT

Next Steps

Generate a hash

Need to verify data integrity? Generate MD5, SHA-256, and more

Hash generator →

Base64 encode/decode

JWT uses Base64 — encode or decode any Base64 data

Base64 tool →

Data Source & Legal Disclaimer

Effective: Current

Sources: RFC 7519 — JSON Web Token (JWT)

⚠️ Decoding runs 100% locally in your browser — your JWT is never uploaded. Never paste production access tokens or sensitive credentials into any online tool. This decoder only reads the header and payload; it does NOT verify signatures and must not be used to trust token contents.

See all data sources & update policy →

Comment ça marchePage 2

↩ Retour à la calculatrice

What a JSON Web Token actually is — illustrated

A JWT (RFC 7519) is a compact, URL-safe string of three dot-separated segments: a header that names the signing algorithm, a payload of claims about the user, and a signature that cryptographically binds the two. Each segment is JSON that has been Base64URL-encoded (URL-safe base64 with the padding stripped). This decoder reads the first two segments locally and checks the exp claim against the current time — it never verifies the signature, because that requires the server's secret key.

header.payload.signature — three segments, one token

Left: the two JSON segments are Base64URL-encoded so the token survives URLs, cookies and Authorization headers. Right: the signature is HMAC-SHA256 (or RSA/ECDSA) computed over the encoded header.payload with a secret only the server holds — that is what proves the token was not tampered with.

Debugging an expired access token

Maya, a backend engineer, gets a 401 Unauthorized from an API. She pastes the token from the Authorization header into this decoder to see exactly what the server was complaining about.

Paste the token:All three segments arrive as one string, straight from the 401 response
Header reads:{"alg":"HS256","typ":"JWT"} — so the server signs with HMAC-SHA256
Payload claims:sub: user 1234, iat: issued-at, exp: expiry — decoder shows EXPIRED when exp is in the past
Signature caveat:Verification needs the secret key, so decoding only inspects — it never trusts — the claims

↩ Back to decoder

FAQ et détailsPage 3

↩ Retour à la calculatrice

A JWT has three parts: header.payload.signature. Paste your JWT to decode the base64 header and payload, check expiry, and inspect claims — all locally in your browser.

FreeToolHub JWT Decoder is a free browser-based tool that decodes JWT tokens to inspect header and payload, no signup, no upload.

À propos de cet outil

Qu'est-ce que cet outil ?

Décodez et examinez l'en-tête et le payload de vos tokens JWT instantanément. Le token ne quitte jamais votre navigateur.

100% localHS256/RS256Expire checkNo upload

Qu'est-ce que le JWT Decoder ?

Le JWT Decoder divise tout JSON Web Token en ses trois parties séparées par des points et affiche chacune sous une forme lisible : l'en-tête montrant l'algorithme et l'ID de clé, le payload avec toutes les revendications décodées, et la section de signature. Au-delà du simple décodage, il effectue des vérifications pratiques dont les développeurs ont réellement besoin — détection d'algorithme parmi HS256, HS512, RS256, ES256, et plus encore, un compte à rebours d'expiration convertissant les dates numériques exp et iat en timestamps lisibles par un humain, et un marquage instantané des tokens expirés, pas encore valides ou présentant une malformation suspecte. Tout est décodé localement dans votre navigateur, ce qui est crucial car les JWT sont des informations d'identification : en coller un dans un service web aléatoire revient à remettre une clé de session.

Qui devrait utiliser cet outil ?

Les développeurs backend déboguant l'authentification inspectent quelles revendications un fournisseur d'identité a réellement émises — rôles, portées, locataires — au lieu de ce que la documentation promettait. Les ingénieurs frontend traçant pourquoi un utilisateur s'est déconnecté vérifient le timing exp par rapport au décalage d'horloge. Les intégrateurs d'API vérifiant les tokens webhook et OAuth confirment le bon public et émetteur avant de créer des tickets de support. Les apprenants en sécurité étudient la structure réelle des tokens en toute sécurité, et toute personne examinant un token avant de le coller dans des journaux peut d'abord supprimer ou inspecter les revendications sensibles.

Comment ça fonctionne ?

(1) Collez le token — l'outil détecte automatiquement la forme JWT et sépare au niveau des points. (2) L'en-tête se décode depuis base64url, révélant les champs alg, typ et kid. (3) Le payload se décode avec chaque revendication standard annotée : sub, iss, aud, exp, iat, nbf, plus les revendications personnalisées affichées telles quelles. (4) Les timestamps se convertissent dans votre fuseau horaire local avec un compte à rebours en direct ; les tokens expirés deviennent rouges avec le temps écoulé depuis l'expiration. Le segment de signature est affiché mais pas vérifié, car la vérification nécessite la clé secrète ou publique, qui ne devrait jamais être collée dans des outils web.

Que signifient les revendications JWT standard ?

Les revendications enregistrées du payload portent la sémantique : sub identifie le sujet, généralement l'ID utilisateur ; iss est l'émetteur, le serveur d'authentification qui a créé le token ; aud liste les destinataires prévus et ce que les API vérifient pour rejeter les tokens externes ; exp et nbf délimitent la fenêtre de validité, et iat enregistre le temps de création. Au-delà de celles-ci, les fournisseurs ajoutent leurs propres — rôles, permissions, email_verified, locataire — et les lire est souvent la façon la plus rapide de déboguer la logique d'autorisation. Une note de sécurité qui façonne la manière dont vous traitez tout token décodé : décoder n'est pas vérifier. Le payload est en base64, pas chiffré, donc tout le monde peut lire ou falsifier des revendications ; seule la signature, vérifiée contre le secret par votre backend, prouve l'authenticité. C'est pourquoi cet outil décode localement et ne demande jamais de clés.

Questions fréquentes

Qu'est-ce qu'un JWT ?

Un JSON Web Token (JWT) est un format de token compact et sûr pour les URL défini dans RFC 7519. Il se compose de trois parties encodées en Base64URL séparées par des points : header.payload.signature. Les JWT sont largement utilisés pour l'authentification et l'échange d'informations — lorsque vous vous connectez à une application web, le serveur renvoie généralement un JWT que votre navigateur envoie avec chaque requête suivante pour prouver votre identité.

Mon token JWT est-il envoyé à un serveur ?

Non. Le JWT Decoder traite votre token entièrement dans votre navigateur en utilisant le décodage Base64 en JavaScript. Votre token — y compris tous les secrets de session, IDs utilisateur ou PII dans le payload — ne quitte jamais votre appareil. Ceci est crucial pour la sécurité : contrairement à jwt.io et autres décodeurs en ligne, vous pouvez déboguer en toute sécurité des tokens de production ici.

Que contient l'en-tête JWT ?

L'en-tête contient généralement deux champs : "alg" (l'algorithme de signature, tel que HS256, RS256, ES256, ou HS384) et "typ" (le type de token, toujours "JWT"). L'algorithme vous indique comment la signature a été créée — HS256 signifie un secret partagé, RS256 signifie une clé privée RSA. Des algorithmes non concordants entre l'en-tête et la signature réelle indiquent un problème de sécurité potentiel.

Comment vérifier si un JWT est expiré ?

Le payload contient une revendication "exp" (temps d'expiration) sous forme de timestamp Unix en secondes. Le décodeur convertit cela en une date lisible par un humain et la compare à l'heure actuelle. Si le token est expiré, un badge "EXPIRED" rouge apparaît. Le payload peut également contenir les timestamps "iat" (émis à) et "nbf" (pas avant) pour une validation complète du cycle de vie.

Cet outil peut-il vérifier la signature JWT ?

L'outil décode et affiche la signature mais ne la vérifie pas cryptographiquement — la vérification nécessite la clé secrète (pour HMAC) ou la clé publique (pour RSA/ECDSA), qui n'est détenue que par le serveur émetteur. Cependant, l'outil signale les conditions suspectes : algorithmes faibles (none, HS256 avec des clés courtes), tokens expirés, et revendications requises manquantes.

Est-il sûr de décoder un token JWT dans cet outil ?

Oui. Décoder un JWT ne fait que parser l'en-tête et le payload en base64 — il n'envoie pas votre token nulle part. Le traitement s'effectue entièrement en JavaScript sur votre machine locale avec zéro requête réseau. Contrairement à jwt.io (qui charge des analytics tierces), cet outil n'a pas de suivi, pas de cookies, et pas de dépendances externes.

Is it safe to decode a JWT token in this tool?

Yes. Decoding a JWT only base64-parses the header and payload sections—it does not transmit your token anywhere. Processing runs entirely in JavaScript on your local machine with zero network requests. Unlike jwt.io (which loads third-party analytics), this tool has no tracking, no cookies, and no external dependencies.

Can it verify a JWT signature?

It decodes and displays the header (algorithm, type), payload (claims, expiration, issuer), and signature. For HS256 tokens, you can paste the secret to verify signature integrity locally. It supports RS256, ES256, and HS256 algorithms—the three most common in production OAuth 2.0 and OpenID Connect implementations.

Autres noms de cet outil

Cet outil est aussi connu sous ces tâches — chaque lien ouvre le même outil avec un guide ciblé :

decode JWT token — JWT Decoder — Read the Payload, Check the Claims