Hoppa till huvudinnehåll
FreeOnlineTools Go
Svenska
explanation

Vad Är ett JWT? En Komplett Förklaring av JSON Web Tokens

By FreeOnlineTools Team · Updated 2026-09-02

Quick Answer

En JWT är en sträng med tre Base64URL-kodade delar separerade med punkter: header.payload.signature. Header specificerar algoritmen, payload innehåller claims (user ID, roles, expiration) och signature bevisar äkthet. Använd vår gratis JWT Decoder.

Introduction

Ett JWT (JSON Web Token) är ett kompakt, URL-säkert token-format definierat av RFC 7519 för säker överföring av information mellan parter som ett JSON-objekt. JWT:er används ofta för autentisering i webbapplikationer: efter inloggning utfärdar servern en JWT som klienten inkluderar i efterföljande requests. JWT:er är stateless —servern behöver inte slå upp token i en databas; token själv innehåller användarens claims och en signature.

Step by Step

  1. Understand the three-part structure

    A JWT has three parts: header (algorithm and type), payload (claims), and signature (proves integrity). Each part is Base64URL-encoded and separated by dots: eyJhbGciOi...J9.eyJzdWIi...J9.signature. The first two parts are readable by anyone with the token; only the signature requires the secret key.

  2. Learn the standard claims

    The payload contains claims — statements about the subject. Standard claims: 'sub' (subject/user ID), 'iat' (issued at timestamp), 'exp' (expiration), 'nbf' (not before), 'iss' (issuer), 'aud' (audience). Custom claims can include roles, permissions, or any other data.

  3. Understand signing algorithms

    JWTs use symmetric (HS256 — shared secret) or asymmetric (RS256, ES256 — public/private key pair) signing. The signature prevents tampering: changing any part of the token invalidates the signature. Only the holder of the secret/private key can create valid tokens.

  4. Use JWTs for authentication

    After login, the server creates a JWT and sends it to the client. The client includes the JWT in the Authorization header (Bearer token) for subsequent requests. The server verifies the signature and checks expiration — no database lookup needed.

Examples

JWT structure

Input: A typical JWT

Output: eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyMSIsImV4cCI6MTY5MzYxMjgwMH0.signature

Decoded header

Input: First part decoded

Output: {"alg": "HS256", "typ": "JWT"}

Decoded payload

Input: Second part decoded

Output: {"sub": "user1", "name": "Alice", "iat": 1693526400, "exp": 1693612800}

Common Problems

  • Decoding vs verifying —decoding a JWT (reading its contents) does NOT prove it is authentic. Always verify the signature server-side with the secret key before trusting claims.
  • Storing JWTs in localStorage —this makes them accessible to JavaScript, vulnerable to XSS attacks. Store in httpOnly cookies for better security.
  • Long-lived tokens —if a token is stolen, it remains valid until expiration. Use short-lived access tokens (15-60 min) with refresh tokens for long sessions.
  • Sensitive data in payload —the payload is readable by anyone with the token (it is Base64, not encrypted). Never put passwords, credit cards, or secrets in the payload.

Tips

  • Always verify the JWT signature server-side before trusting any claims —decoding alone is not authentication.
  • Use short-lived access tokens (15-60 minutes) with refresh tokens for long sessions to minimize damage from token theft.
  • Store JWTs in httpOnly, Secure, SameSite cookies rather than localStorage to prevent XSS attacks.
  • Use our JWT Decoder to inspect token contents for debugging —your token never leaves your browser.

Related Tools

Related Guides

References