Free Online JWT Decoder — Decode & Verify Tokens In Your Browser

Free Online JWT Decoder — Decode & Verify Tokens In Your Browser

📅 April 9, 2026 · 10 min read ·
← All posts

Free Online JWT Decoder — Decode & Verify Tokens In Your Browser

You're stuck debugging an authentication flow. Your frontend gets a 401, the backend says the token is expired, and you have a wall of base64-looking gibberish staring back at you. You need to see inside that JWT
now
— but here's the thing most developers don't think about:
every time you paste a production JWT into a random website, you might be leaking user credentials, email addresses, tenant IDs, and session secrets to an unknown third party.

This guide explains how JWTs work, why server-side JWT decoders are a real security risk, and why a
free online JWT decoder that runs 100% client-side
— like the one on
Goosekit
— is the only safe way to decode JWT tokens in your browser.

What is a JWT?

JSON Web Token (JWT)
, defined in
RFC 7519
, is a compact, URL-safe token format used to securely transmit claims between two parties. Every JWT has three parts separated by dots:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 . eyJzdWIiOiIxMjM0NTY3ODkwIn0 . SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

← HEADER (base64url) →

← PAYLOAD (base64url) →

← SIGNATURE (binary data, base64url-encoded) →

Each part is base64url-encoded JSON (except the signature, which is raw binary data encoded as base64url). Let's look at each piece in detail.

1. The Header

The header is a JSON object that declares two things:

alg
— the signing algorithm (e.g.,
HS256
,
RS256
,
ES256
)

typ
— the token type, always
"JWT"

Typical decoded header:

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

The algorithm field is critical. It tells the verifier
how
to validate the signature. Mismatches between the declared algorithm and the key material are a common source of vulnerabilities and debugging headaches.

1. The Payload (Claims)

The payload contains
claims
— statements about an entity (usually the user). There are three types:

Registered claims
: standard fields like
iss
(issuer),
sub
(subject),
aud
(audience),
exp
(expiration time),
nbf
(not before),
iat
(issued at),
jti
(unique token ID).

Public claims
: custom fields you define, like
email
,
role
,
tenant_id
.

Private claims
: application-specific data agreed between parties.

Typical decoded payload:

{
"sub": "1234567890",
"email": "[e-mail]",
"role": "admin",
"tenant_id": "acme-corp",
"iat": 1712620800,
"exp": 1712707200
}

⚠️ Critical security note:
The JWT payload is
NOT encrypted
. It's only base64url-encoded. Anyone who obtains the token can read every claim inside it. Never put sensitive data (passwords, credit card numbers, SSNs) in a JWT payload.

1. The Signature

The signature is computed by signing the encoded header and encoded payload with a secret key or private key. For
HS256
:

HMACSHA256(
base64UrlEncode(header) + "." + base64UrlEncode(payload),
your-256-bit-secret
)

The signature proves that the token was created by someone who knows the signing key and that nobody has modified it since. If even one character in the payload changes, the signature verification fails.

HS256 vs RS256 vs ES256 — What's the difference?

Algorithm

Type

Key Material

Best For

HS256

Symmetric

Single shared secret

Single-service apps, quick prototypes

RS256

Asymmetric (RSA)

Private key (sign) + public key (verify)

Microservices, OIDC, Auth0, AWS Cognito

ES256

Asymmetric (ECDSA)

ECDSA private/public key pair

Apple Sign-In, mobile apps, smaller keys

None

Unsigned

No key

⚠️ Not for authentication

HS256
is the simplest — one secret signs and verifies. But that same secret must live on every server that validates tokens, which makes key rotation a pain at scale.

RS256
separates concerns. The auth server holds the private key (used to sign), and every service only needs the public key (used to verify). That's why Auth0, Okta, AWS Cognito, and Firebase all default to RS256 for OIDC flows.

ES256
uses elliptic curve cryptography. Shorter signatures, smaller keys, and faster verification than RSA. Apple's Sign-In implementation uses ES256 by default.

Regardless of which algorithm your JWT uses, the
decode process is identical
— the headers and payloads are always just base64url-encoded JSON. The algorithm only matters when you want to
verify the signature
.

Why Decoding JWT Tokens Online Is a Security Risk

Here's the uncomfortable truth: most free online JWT decoders are server-side tools. You paste your token, it gets
uploaded to their server
, decoded there, and the results sent back. That means:

Your production tokens leave your machine.
They travel to someone else's infrastructure, sit in their server memory, and quite possibly get written to their logs.

JWTs contain identifiable data.
User IDs, email addresses, tenant IDs, roles, session scopes — often directly from your production environment.

Some tools store tokens "for convenience."
Browser history, server-side databases, analytics pipelines — it's all plausible, and most tools don't disclose what they do with the data.

A data breach turns your tokens into attack vectors.
Even unexpired tokens that contain session identifiers can be replayed. Even expired tokens leak information about your infrastructure.

Compliance violations.
If your JWTs contain any data covered by GDPR, HIPAA, or SOC 2, sending them to a third-party server without a DPA is a compliance failure.

The rule of thumb:
If a JWT decoder requires your browser to make a network call with the token data, it is
not
safe to use with production tokens. A client-side JWT decoder runs the decoding logic in JavaScript inside your browser — the token never makes a round-trip to any server.

The Safe Way: 100% Client-Side JWT Decoding

The Goosekit JWT Decoder
runs entirely in your browser using standard Web APIs. Here's how it works:

Input
: You paste or upload your JWT token into a text field.

Decode
: JavaScript splits the token on
.
, decodes each segment with
atob()
(base64url), and parses the resulting JSON.

Display
: The header, payload, and signature validity are displayed as formatted JSON with color-coding — no network request made.

Verify
(optional): You can paste a secret key (HS256) or public key (RS256/ES256) and the signature is verified locally using the
Web Crypto API
(SubtleCrypto).

Zero data leaves your browser.
No fetch calls, no webhooks, no analytics payloads with your token. The tool is a self-contained web application that works offline once loaded.

Security comparison: client-side vs server-side JWT decoders

Feature

Client-Side (Goosekit ✅)

Server-Side Tools

Token stays in your browser

✅ Yes

❌ Uploaded to server

Works offline

✅ Yes

❌ Requires internet

No data stored on servers

✅ Guaranteed

❓ Depends on provider

No signup required

✅ Yes

Often no (but many gate features)

HS256 / RS256 / ES256 verify

✅ Yes (SubtleCrypto)

✅ Yes

GDPR / SOC 2 safe

✅ Yes — no data leaves device

⚠️ Only if provider has a DPA

Free without account

✅ Yes

⚠️ Some features paywalled

When Do You Need to Decode a JWT?

Debugging Authentication Flows

You're building an app with NextAuth, Auth0, or custom JWT middleware. Something's broken — maybe the
Authorization: Bearer
header isn't getting the right claims, or a role-based middleware is rejecting admin users. Dropping the token into a decoder instantly shows you exactly what claims are being issued, what the expiration time is, and whether the
iss
and
aud
values match what your backend expects.

Troubleshooting "401 Unauthorized" Errors

The single most common production support ticket. The user is logged in but getting 401s. When you decode the JWT, you'll usually find one of these:

Expired token
: the
exp
claim is in the past — the refresh token flow isn't working properly.

Wrong issuer
: the
iss
claim doesn't match — you changed auth providers or domains without updating validation.

Missing claims
: a new backend check is looking for a
tenant_id
that old tokens don't have.

Algorithm mismatch
: the backend switched from HS256 to RS256 and some service is using the old config.

Security Audits

During a security review, auditors need to verify JWT configuration:

Are tokens short-lived? (check
exp
)

Are there
nbf
(not before) claims preventing replay?

Do tokens carry more data than necessary? (PII in JWT payloads)

Is the signing algorithm appropriate? (RS256 or ES256 preferred over HS256 for multi-tenant apps)

Are
aud
and
iss
claims validated server-side?

Interoperability Testing

When integrating with a third-party identity provider (Auth0, Okta, Firebase, AWS Cognito), you'll receive JWTs from their token endpoint. Decoding them lets you confirm that the claims match your expectations before writing the validation logic.

Education and Learning

There's no better way to understand JWT structure than to actually decode real tokens. Seeing the header's
alg
value, the payload's claims, and understanding how the signature ties them together cements the concept far better than any diagram.

Common JWT Vulnerabilities to Watch For

The
alg: none
Attack

An attacker crafts a JWT with
"alg": "none"
in the header and an empty signature. If your backend accepts
none
as a valid algorithm (which many did before this became well-known), the token passes verification without any signature check.
Always explicitly reject the "none" algorithm in your JWT validation library.

Algorithm Confusion (RS256 → HS256)

An attacker changes the algorithm from RS256 to HS256 and signs the token using the RSA public key (which is often publicly available). If the backend naively uses the "key" from the header to decide the algorithm, it will use the public key as an HMAC secret — which the attacker knows.
Always fix the expected algorithm server-side, never trust the token's header.

Token Expiration Not Checked

A common misconfiguration: the backend validates the signature but forgets to check the
exp
claim. This means a captured token is valid
forever
. Always validate expiration, and use short-lived access tokens (5-15 minutes) with separate refresh tokens.

Storing Sensitive Data in JWTs

Remember: JWT payloads are
visible to anyone
. Storing passwords, API keys, or PII inside a JWT is equivalent to publishing them in plain text. Use JWTs for identity claims, not secrets.

How to Use the Free JWT Decoder on Goosekit

The
JWT Decoder on Goosekit
is designed to be the fastest, safest way to decode JWT tokens online. Here's the workflow:

Paste your JWT
into the input field — it auto-detects valid JWT format.

View decoded header, payload, and signature info
instantly — formatted JSON with collapsible sections.

Verify the signature
(optional) by selecting the algorithm and pasting your secret (HS256) or public key (RS256/ES256).

Export or copy
individual sections for use in documentation, bug reports, or security tickets.

Everything runs in your browser. The token never leaves your device. No account needed, no email to provide, no tracking beyond basic privacy-respecting analytics.

Decode JWT tokens — 100% in your browser

Free. No signup. No server uploads. Supports HS256, RS256, ES256, and more.

Open JWT Decoder →

Frequently Asked Questions

What is a JWT token?

A JWT (JSON Web Token) is a compact, self-contained token composed of a header (signing algorithm), a payload (claims like user ID and expiration), and a cryptographic signature. It's used for authentication and authorization across web applications and APIs.

Is it safe to use a free online JWT decoder?

Only if the decoder runs entirely client-side. Server-side tools require you to upload your token to their servers, exposing potentially sensitive data. A browser-based decoder like
Goosekit's JWT Decoder
keeps everything local — your token never leaves your device.

Can I decode a JWT without a secret key?

Yes. The header and payload are base64url-encoded, not encrypted. Anyone can read them. The signature requires a secret (HS256) or public key (RS256/ES256) to verify, but reading the claims requires only decoding.

What's the difference between HS256 and RS256?

HS256 uses a symmetric shared secret — the same key signs and verifies. RS256 uses asymmetric RSA key pairs — a private key signs, a public key verifies. RS256 is preferred for distributed systems and identity providers like Auth0 and Firebase because the public key can be shared openly.

How do I verify a JWT token is valid?

Validation requires: (1) checking the signature with the correct key, (2) verifying the
exp
(expiration) hasn't passed, (3) confirming the
iss
(issuer) matches your auth provider, (4) validating the
aud
(audience) includes your application, and (5) checking that the token hasn't been revoked via a blocklist.

Do JWT decoders need an internet connection?

A client-side decoder works completely offline once the page is loaded. No token data needs to be sent over the network. A server-side decoder, on the other hand, requires an active connection to transmit and return results.

Can I decode a JWT in the browser console?

Yes. You can manually decode a JWT in any browser's DevTools console:

const jwt = "your.token.here";
const [header, payload] = jwt.split('.').map(
part => JSON.parse(atob(part.replace(/-/g,'+').replace(/_/g,'/')))
);
console.log(header, payload);

This works because JWT headers and payloads are simply base64url-encoded JSON. But it doesn't verify the signature, doesn't validate expiration, and doesn't detect tampering — which is exactly why a dedicated tool like
Goosekit's JWT Decoder
is more practical for real-world debugging.

Conclusion

JWTs are everywhere in modern web development — authentication, API authorization, microservice-to-microservice communication. Being able to decode and inspect them quickly is a core debugging skill. The key insight:
your decoding tool should never see your token over the network.

Choose a client-side JWT decoder, keep your production tokens on your own machine, and use the right tool for the job.
Goosekit's free JWT Decoder
does exactly that — no uploads, no signups, no risk. Just open the page, paste the token, and see what's inside.

Decode & verify JWT tokens — safely

100% client-side. Free. No signup. Supports HS256, RS256, ES256.

Try the JWT Decoder →