Base64 Decode for JWT Tokens and Kubernetes Secrets

Two of the most common reasons to decode Base64: checking what is inside a JWT token and reading Kubernetes secret values. This guide covers both with step-by-step examples.

Decoding JWT Tokens

A JWT (JSON Web Token) looks like this:

eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyIjoiam9obiIsInJvbGUiOiJhZG1pbiJ9.signature

Three segments separated by dots:

1. Header (algorithm, type)
2. Payload (claims: user data, expiration, permissions)
3. Signature (verification, needs the secret key)

You can decode segments 1 and 2 without any key. They are just Base64url-encoded JSON.

Quick Method

1. Copy the middle segment: eyJ1c2VyIjoiam9obiIsInJvbGUiOiJhZG1pbiJ9
2. Paste into the Base64 Decoder
3. Click Decode
4. Read the JSON: {"user":"john","role":"admin"}

For a full JWT breakdown with all three segments parsed and formatted, use the JWT Decoder.

What You Find Inside

Claim	Example	Meaning
sub	12345	Subject (user ID)
exp	1712345678	Expiration (Unix timestamp)
iat	1712340000	Issued at time
role	admin	User role/permissions
email	[email protected]	User email
iss	auth.example.com	Token issuer

Check the exp claim to see if a token has expired. Convert the Unix timestamp with the Timestamp Converter.

Decoding Kubernetes Secrets

When you get a Kubernetes secret:

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
data:
  username: YWRtaW4=
  password: czNjcjN0UEBzc3cwcmQ=

The values are Base64. Decode them:

• YWRtaW4= → admin
• czNjcjN0UEBzc3cwcmQ= → s3cr3tP@ssw0rd

From the Terminal

• kubectl get secret db-credentials -o jsonpath='{.data.password}' | base64 -d
• Or decode all at once: kubectl get secret db-credentials -o json | jq -r '.data | to_entries[] | "\(.key): \(.value | @base64d)"'

Why Kubernetes Uses Base64

YAML is a text format. Binary values (certificates, keys) cannot be stored directly. Base64 converts them to text. But Base64 is NOT security. Anyone with kubectl access can decode the values. Use Sealed Secrets, SOPS, Vault, or external secret managers for real protection.

Security Reminder

Both JWTs and Kubernetes secrets use Base64 for format compatibility, not security. A Base64-encoded password is not a protected password. Always:

• Use HTTPS when transmitting JWTs
• Verify JWT signatures server-side before trusting claims
• Use RBAC to restrict who can read Kubernetes secrets
• Consider encrypting secrets at rest with a secrets manager

Related: JWT Decoder, Hash Generator, URL Encoder.