Angtool
Back to Blog
jwtsecuritydeveloper tools

How to Safely Decode JWT Tokens Offline Without Risking Secret Leakage

Angtool Team ·

Decoding JSON Web Tokens (JWT) is a daily task for many web developers. Whether you are debugging an authentication flow, inspecting a user’s claims, or verifying a token’s expiration, you need a reliable way to decode the payload. However, copying and pasting your session tokens into random online decoders exposes you to severe security risks that could compromise your entire application.

Understanding JWT Structure

A JSON Web Token consists of three parts separated by dots:

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jNvf7P4J3jNv
  1. Header: A Base64Url encoded JSON object containing the signing algorithm and token type
  2. Payload: A Base64Url encoded JSON object containing the claims (user data, permissions, expiration)
  3. Signature: A cryptographic signature generated from the header, payload, and a secret key

The critical insight is that the header and payload are not encrypted — they are only Base64Url encoded. Anyone with access to the token can decode and read them without knowing the secret key. This is by design: JWTs are signed, not encrypted.

The Problem with Online Decoders

Most online JWT decoding tools run on backend servers. When you paste your token, here is what happens:

  1. Your browser sends the token over the internet to the tool’s server
  2. The server receives the full token, including any sensitive claims
  3. The server decodes it and sends the result back
  4. The server may or may not log or store the token

Even if the connection is HTTPS (encrypted in transit), the server has full access to the decoded content. Consider what information a JWT payload might contain:

  • User ID and email address
  • Role and permission levels
  • Session ID and expiration time
  • Custom claims like department, tenant_id, or organization
  • Occasionally, personally identifiable information (PII)

If that token is for a production system and contains customer data or administrative credentials, you are potentially leaking critical access information.

Additional Risks of Server-Based Decoders

Beyond immediate token leakage, using online decoders poses subtler risks:

Credential Harvesting: Some malicious decoder sites are specifically designed to harvest tokens. They may look legitimate but are actually phishing for authentication tokens that can be used to hijack sessions.

Man-in-the-Middle Attacks: While HTTPS protects against basic interception, sophisticated attackers on compromised networks can still potentially intercept traffic before it is encrypted (e.g., through malicious browser extensions or proxies).

Data Aggregation: Even well-intentioned sites may aggregate decoded tokens for analytics, debugging, or “improving their service” — which is not something you want for your production authentication tokens.

The Client-Side Solution

The safest way to decode a JWT is to do it entirely within your browser. Since the header and payload are simply Base64Url encoded JSON, you do not need a server to decode them. The process is straightforward:

  1. Split the token by . to get the three parts
  2. Take the first two parts (header and payload)
  3. Convert Base64Url encoding to standard Base64
  4. Use the browser’s built-in atob() function to decode
  5. Parse the resulting JSON

This entire process can be done with a few lines of JavaScript, no server required. The decoded data never leaves your browser’s memory.

What About Signature Verification?

A common question is whether you can verify a JWT’s signature offline. The answer depends on the signing algorithm:

Symmetric (HS256): Requires the shared secret key. If you have the key, you can verify locally. If not, you cannot verify the signature without the key — which is actually a security feature, not a limitation.

Asymmetric (RS256/ES256): If you have the public key, you can verify the signature locally. Many applications expose their public keys via a JWKS (JSON Web Key Set) endpoint.

For most debugging purposes, decoding the payload without signature verification is sufficient. If you need signature verification, you can fetch the public key once and cache it locally for subsequent verifications.

Best Practices for Token Inspection

  1. Never paste production tokens into random websites. Use a local decoder every time.
  2. Use browser developer tools as a fallback. You can decode JWTs using atob() directly in the browser console: atob(token.split('.')[1]).
  3. Be mindful of token expiration. A token decoded offline might be expired — check the exp claim manually.
  4. Clear your clipboard after use. On most operating systems, copied text remains in the clipboard and can be accessed by other applications.

Try our Offline JWT Decoder which runs 100% locally in your browser. Your token never leaves your device. It automatically parses the header and payload, displays claims in a readable table, and highlights expiration dates and common fields for quick inspection.

The Bottom Line

Decoding JWTs is a routine task, but it does not have to be a security risk. By using a client-side decoder, you can inspect tokens freely without worrying about data leakage, credential harvesting, or server-side logging. Your authentication tokens and the data they contain stay under your control, exactly where they belong.