How to Decode a JWT Without a Third-Party Tool

You can decode a JWT locally without using jwt.io or any third-party tool — paste the token into brevio JWT Decoder or use a one-liner in your browser DevTools console: JSON.parse(atob(token.split('.')[1])).

JWT (JSON Web Tokens) are used for authentication, API calls, and secure data transmission. When debugging, you often need to see what's inside a token — the claims, expiration, user ID, permissions, etc. Many developers paste tokens into jwt.io or similar sites, but this creates a security risk: you're sending your authentication token to a third-party server where it may be logged or stored.

A safer approach: decode JWTs locally in your browser without uploading them anywhere. Your tokens stay on your device.

Understanding JWT Structure

A JWT looks like this: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U

It has three parts separated by dots:

1. Header (first part): Algorithm and token type (e.g., HS256).
2. Payload (second part): Your claims — user ID, email, permissions, expiration, etc. This is what you want to read.
3. Signature (third part): A cryptographic signature proving the token wasn't tampered with. Only the server (with the secret key) can verify this.

The header and payload are Base64-encoded, not encrypted. Anyone can decode them to read the contents. The signature ensures the token hasn't been modified.

How to Decode a JWT Locally

1. Go to a client-side JWT decoder like brevio JWT Decoder.
2. Paste your JWT token. Copy the entire token (all three parts) and paste it into the decoder. Don't worry about the format — the tool handles it.
3. View the decoded payload. The tool decodes and displays the header and payload as readable JSON. The signature is not decoded — only verified or displayed as Base64.
4. Check the expiration. Look for the exp claim — it's a Unix timestamp. If it's in the past, the token is expired. If it's in the future, the token is still valid.

How to verify brevio doesn't send your token anywhere

If you're handling a production token or one containing sensitive claims, you can prove for yourself that no data leaves your browser. This takes about 30 seconds in DevTools.

1. Open DevTools — press F12 on Windows/Linux or ⌘⌥I on Mac.
2. Go to the Network tab, filter to "Fetch/XHR", and check the "Disable cache" checkbox. This ensures every request is captured, including any that might otherwise be served from cache.
3. Paste your JWT into brevio JWT Decoder and let the decoder process it.
4. No POST requests will appear. All decoding happens via atob() and JSON.parse() running directly in your browser tab — zero network activity occurs with your token data. The Network tab will remain empty of any outbound requests carrying your token.

This is the standard verification technique for any tool that claims to be client-side. If a POST request fires when you interact with the tool, your data left the browser.

JWT decoder comparison

Not all JWT decoders offer the same privacy guarantees. Here's how common options compare:

What You Can Learn From a Decoded JWT

• User ID / Subject: sub claim typically contains the user ID or username.
• Expiration: exp claim is a Unix timestamp. If expired, the server will reject the token.
• Issued At: iat claim shows when the token was created.
• Permissions / Roles: Custom claims (varies by app) might include user roles, scopes, or access levels.
• Audience: aud claim specifies which service/app the token is for.

Real JWT example: what each claim means

A typical JWT payload decoded from a production application might look like this:

{
  "sub": "user_12345",
  "email": "[email protected]",
  "roles": ["admin", "user"],
  "iat": 1718150400,
  "exp": 1718236800,
  "aud": "https://api.yourapp.com",
  "iss": "https://auth.yourapp.com"
}

What each field means:

• sub — Subject: the user's unique identifier (user ID). This is what the server uses to look up the account.
• email — The user's email address. This is a custom claim added by your auth provider. It's also why pasting a production token into an external service is a privacy risk.
• roles — A custom claim for authorization. The API checks this to determine what the user can do.
• iat — Issued At: Unix timestamp (seconds since January 1, 1970) of when the token was created. 1718150400 = June 12, 2024 at 00:00 UTC.
• exp — Expiry: Unix timestamp of when the token expires. If this value is less than the current time, the server will reject the token as expired.
• aud — Audience: the intended recipient of this token. A token issued for https://api.yourapp.com should be rejected by any other service.
• iss — Issuer: the URL of the authentication server that created the token. The API validates this to ensure it trusts the issuer.

Why Not Use jwt.io?

jwt.io is operated by Auth0, which was acquired by Okta. It's convenient and widely used in tutorials, but the security implications for production tokens are significant:

• When you paste a token into jwt.io, it is sent to their servers for signature verification. Your token appears in their server access logs including the full Base64-encoded payload.
• If your token contains a user email, user ID, organization ID, or custom claims with personally identifiable information, those values are now in Auth0/Okta's log infrastructure.
• Even if they don't intentionally store tokens, their CDN and reverse proxy infrastructure generates access logs that typically retain request payloads for days to weeks.
• Many company security policies explicitly prohibit pasting credentials into external web tools — jwt.io is specifically called out in some internal security guidelines at companies that have audited this workflow.
• The safer alternative: use the browser console one-liner for decode-only operations, or brevio for a visual interface. Neither sends your token anywhere.

Command-line alternatives

For developers who prefer the terminal, there are several local options that keep your token off the network entirely:

# Decode JWT payload with base64 + jq (macOS/Linux)
echo "eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyXzEyMyJ9.signature" | cut -d'.' -f2 | base64 -d | jq .

# Using Node.js (no packages required)
node -e "const t='YOUR_JWT'; console.log(JSON.parse(Buffer.from(t.split('.')[1], 'base64').toString()))"

For a full-featured CLI with pretty-printing, expiry checks, and algorithm display, install jwt-cli via npm: npm install -g jwt-cli. It decodes locally and supports all standard JWT claims. The base64 -d | jq . pipeline is the quickest option when you already have both tools available — no package installation needed.

Can a Decoded JWT Be Used to Impersonate Someone?

No. Reading a JWT reveals its claims but doesn't let you forge a new token. The server verifies the signature using a secret key that only it knows. If you modify the decoded token and re-encode it, the signature won't match and the server will reject it as invalid.

The only way to create a valid JWT is to know the server's secret key — which you shouldn't have.

Debugging Token Issues

• Token is expired? Compare the exp value to the current Unix timestamp. If exp is less than the current time, the token has expired and the server will reject it.
• Wrong permissions? Check custom claims for roles or scopes. The app may require specific permissions you don't have.
• Wrong audience? If aud is set, you may be using a token intended for a different service.
• Signature verification failed? The token payload was modified after creation. Don't use it.

Browser Compatibility

Works in all modern browsers (Chrome, Firefox, Safari, Edge). Client-side JWT decoders only need JavaScript enabled — no special APIs required.

For other tools that process credentials without uploading, see How to Format JSON Without Uploading and brevio JSON Formatter.

Other ways to do this

You don’t need a web tool for this at all — these options also keep your files on your own machine:

• Built-in command-line tools cover most of this: base64, shasum -a 256, openssl, uuidgen.
• Every programming language ships these in its standard library (e.g. Python’s base64 and hashlib).
• Browser DevTools expose btoa/atob, crypto.subtle, and TextEncoder for quick checks.

The browser tool is just the no-install, cross-platform option for when you would rather not set any of these up.