Avkoda ett JWT och Inspektera Claims SäKert
Quick Answer
En JWT är tre Base64URL-strängar sammanfogade med punkter: header.payload.signature. Avkoda header och payload med Base64URL-avkodning för att inspektera claims —men avkodning läser bara data, den verifierar inte äkthet. Verifiera alltid signature på servern. Använd vår JWT Decoder.
Introduction
Ett JSON Web Token (JWT, RFC 7519) är ett kompakt, URL-säkert token-format använt för autentisering och auktorisering. Det har tre Base64URL-kodade delar separerade med punkter: header.payload.signature. Header beskriver algoritmen, payload bär claims (user id, roles, expiry) och signature bevisar att token utfärdats av en betrodd part. Avgörande: header och payload är kodade, inte krypterade —vem som helst kan läsa dem.
Step by Step
-
Split the token into three parts
A JWT looks like xxxxx.yyyyy.zzzzz. Split on the dot character to get the header (part 0), payload (part 1), and signature (part 2). If there are not exactly three parts, the token is malformed.
-
Base64URL-decode the header
The header is a Base64URL-encoded JSON object like {"alg":"HS256","typ":"JWT"}. Base64URL uses - and _ instead of + and / and omits padding. Decode it, then JSON.parse to read the algorithm and type. Our JWT Decoder does this automatically.
-
Base64URL-decode the payload (claims)
The payload is a JSON object of claims. Registered claims include iss (issuer), sub (subject), aud (audience), exp (expiry), nbf (not-before), iat (issued-at), and jti (token id). Private claims are application-specific (e.g. role, email). Decode and inspect, but do not trust until verified.
-
Check the expiry and not-before claims
exp and nbf are Unix timestamps (seconds). If the current time is past exp, the token is expired and must be rejected. If the current time is before nbf, the token is not yet valid. Check these client-side for UX, but enforce them server-side for security.
-
Verify the signature on the server (never client-side)
The signature is HMAC-SHA256(secret, header.payload) for HS256, or RSA/ECDSA signature for RS256/ES256. Verification requires the secret or public key, which must never reach the browser. Use a library like jsonwebtoken (Node) or jose to verify —never write your own crypto.
Examples
A typical JWT (three parts)
Input: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpmeJf36POk6yJV_adQssw5c
Output: Header: {"alg":"HS256","typ":"JWT"} Payload: {"sub":"1234567890","name":"John Doe","iat":1516239022}
Decoded payload with standard claims
Input: Payload of a real auth token
Output: {"sub":"user-42","iss":"freeonlinetoolsgo.com","exp":1767229200,"iat":1767225600,"role":"admin"}
Expired token detection
Input: exp: 1609459200 (2021-01-01) checked at 2026-08-28
Output: Token is expired —current time (1767225600) > exp (1609459200). Reject and prompt re-login.
Common Problems
- Treating decode as verify: anyone can craft a JWT with any claims and a fake signature. Decoding reads the payload but proves nothing. Always verify the signature with the secret/public key on the server before trusting claims.
- Using 'none' algorithm: the JWT spec allows alg: none for unsecured tokens. If your verifier accepts alg: none, an attacker can forge tokens. Configure your library to reject none and whitelist expected algorithms.
- Storing JWTs in localStorage: XSS can read localStorage and exfiltrate tokens. Prefer httpOnly, Secure, SameSite=Strict cookies for session tokens, or short-lived in-memory tokens with a refresh-token cookie.
- Not checking exp/aud/iss: a stolen token is valid until it expires. Always check exp (expiry), aud (intended audience), and iss (issuer) on every request to prevent token replay across services.
Tips
- Use short-lived access tokens (15 minutes) plus long-lived refresh tokens —this limits the window if an access token is stolen.
- Prefer RS256 (asymmetric) over HS256 (symmetric) when multiple services verify tokens: each service gets the public key, and only the issuer has the private key.
- Use our JWT Decoder during development to inspect what the server is issuing —it shows the decoded header, payload, and a human-readable claim summary without sending the token anywhere.
- Never put sensitive data (passwords, PII) in a JWT payload —it is Base64-encoded, not encrypted, and anyone who intercepts the token can read every claim.