Cloudesk

JWT Encoder & Decoder

Create, decode, and verify JSON Web Tokens signed with HMAC algorithms

Generate JWT Token

Encoding vs Encryption

  • •JWT tokens are Base64Url-encoded, NOT encrypted. Anyone who holds the token can read the header and payload — never store passwords, private keys, or other sensitive data in a JWT payload.
  • •HMAC (HS256/HS384/HS512) creates a digital signature that proves the token was issued by the secret holder. The payload is still plaintext; the signature only ensures integrity.
  • •If you need to hide the payload, use JSON Web Encryption (JWE) as defined in RFC 7516. JWE wraps the token contents in a fully encrypted envelope — only the key holder can read it.
  • •One-line summary: Encoding = everyone can read; Signing (JWS) = everyone can read but only the secret holder can create; Encryption (JWE) = only the key holder can read.

Understanding JSON Web Tokens

Part 1 — Header

Specifies the token type (typ: JWT) and the signing algorithm (alg: HS256). This object is Base64Url-encoded to form the first segment of the token.

Part 2 — Payload (Claims)

Contains claims — statements about the entity (user) and additional metadata. Claims can be registered (standardised), public, or private. The payload is Base64Url-encoded but not encrypted.

Part 3 — Signature

Computed as HMAC(algorithm, base64url(header) + "." + base64url(payload), secret). Modifying even a single character in the header or payload produces a completely different signature, invalidating the token.

Common Registered Claims (RFC 7519)

  • •sub (Subject) — Identifies the principal that is the subject of the JWT, typically a user ID.
  • •iat (Issued At) — Unix timestamp of when the token was issued. Used for age checks.
  • •exp (Expiration Time) — Unix timestamp after which the token MUST NOT be accepted. Clients and servers should reject expired tokens.
  • •iss (Issuer) — Identifies the principal that issued the JWT, e.g. "https://auth.example.com".
  • •aud (Audience) — Identifies the intended recipients. A server should reject tokens where it is not listed as the audience.

Encoding vs Encryption

  1. 1JWT tokens are Base64Url-encoded, NOT encrypted. Anyone who holds the token can read the header and payload — never store passwords, private keys, or other sensitive data in a JWT payload.
  2. 2HMAC (HS256/HS384/HS512) creates a digital signature that proves the token was issued by the secret holder. The payload is still plaintext; the signature only ensures integrity.
  3. 3If you need to hide the payload, use JSON Web Encryption (JWE) as defined in RFC 7516. JWE wraps the token contents in a fully encrypted envelope — only the key holder can read it.
  4. 4One-line summary: Encoding = everyone can read; Signing (JWS) = everyone can read but only the secret holder can create; Encryption (JWE) = only the key holder can read.

Related Tools

Base64 Encoder/Decoder

Encode and decode Base64 strings

SHA-256 Checksum Calculator

Calculate the SHA-256 hash of any text or file using the native Web Crypto API

URL Encoder/Decoder

Encode and decode URLs using Full URL (encodeURI) or URL Component (encodeURIComponent) modes