JWT Decoder

Introduction

JSON Web Tokens appear in every OAuth flow, API gateway, and single sign-on integration — yet they arrive as opaque base64url strings that hide their contents until decoded. When a token expires unexpectedly, a claim is missing from your authorization logic, or a support ticket includes a JWT from a failing mobile session, you need to inspect the header and payload without sending that credential to an unknown server.

Certoflow's JWT Decoder splits a token into its three segments, decodes the header and payload from Base64URL, and displays the JSON claims in readable form. Decoding happens entirely in your browser. The token never uploads to Certoflow — essential when payloads contain email addresses, tenant IDs, or session identifiers subject to privacy regulations.

What this tool does

Paste a JWT string (the familiar eyJ... format) and receive structured output:

Output section	Contents
Header	Algorithm (alg), type (typ), key ID (kid), custom fields
Payload	Registered claims (iss, sub, exp, aud) and custom claims
Signature	Raw signature segment (not verified in decode-only mode)

The decoder performs structural parsing and Base64URL decoding — not cryptographic signature verification. Treat decoded output as inspection aid, not trust establishment.

Toolbar actions include paste, copy individual sections, load examples, and clear fields.

How it works

A JWT consists of three dot-separated segments:

<base64url(header)>.<base64url(payload)>.<base64url(signature)>

Client-side processing steps:

1. Split on . — expect exactly three parts for standard JWS compact serialization.
2. Decode header — Base64URL decode first segment → UTF-8 JSON → parse.
3. Decode payload — same process for second segment.
4. Display signature — third segment shown as encoded bytes reference; verification requires the issuer's public key or secret.

Base64URL differs from standard Base64:

Character	Standard Base64	Base64URL
62nd char	+	-
63rd char	/	_
Padding	= often present	often omitted

Example decoded header:

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "2024-01-rotation"
}

Example decoded payload:

{
  "sub": "user_8f3a2b",
  "email": "dev@example.com",
  "iat": 1719230400,
  "exp": 1719234000,
  "scope": "read:orders write:orders"
}

Timestamps iat (issued at) and exp (expiration) are Unix seconds — convert mentally or with a date tool to local time.

No network calls. Decoding completes in milliseconds.

Real-world examples

Debugging "Token expired" errors

Mobile app reports 401. Paste the access token, check exp against current UTC. If expired, trace refresh token flow — not authorization server misconfiguration.

Verifying OAuth scopes before API call

Your backend rejects a request for insufficient scope. Decode the bearer token; confirm scope or custom permission claims include admin:users before blaming the API route.

Inspecting Auth0 or Cognito token shape

Identity providers embed namespaced claims:

{
  "https://app.example.com/roles": ["editor", "billing"]
}

Decoding reveals exact claim keys your middleware must read — typos in claim paths are a common integration bug.

Support ticket triage

Customer sends a redacted JWT with middle characters removed. If structure is intact, decode shows whether aud matches your API identifier — wrong audience causes valid-signature tokens to fail locally.

Learning JWT structure in workshops

Students paste example tokens to see how header algorithm choice relates to signature length and verification approach (symmetric HS256 vs asymmetric RS256).

Comparing ID token vs access token

OpenID Connect returns both. Decode each side by side: ID token carries profile claims (name, email); access token carries authorization data (scope, permissions).

Common mistakes

Treating decode as verification. Anyone can forge a payload and Base64URL-encode it. Without signature verification using the issuer's key, decoded claims are untrusted data.

Pasting production tokens into untrusted online tools. Certoflow processes locally; many competitors upload tokens. Always prefer client-side decoders for real credentials.

Ignoring clock skew on exp. Tokens may appear valid locally but fail server-side when clocks differ by 30–60 seconds. Check nbf (not before) as well.

Assuming all JWTs have three parts. JWE (encrypted tokens) use five parts. This decoder targets signed JWS compact format.

Misreading nested JSON in claims. Some providers stringify JSON inside a claim value. Decode shows a string, not an object — parse again in application code.

Sharing decoded tokens in screenshots. Payloads contain PII. Redact sub, email, and custom identifiers before posting in Slack.

Confusing Base64URL with standard Base64. Piping segments through base64 CLI without URL alphabet conversion produces garbage.

Use cases

Backend developers inspecting claim names and values during OAuth integration with Okta, Auth0, Azure AD, or custom issuers.

Frontend engineers debugging silent refresh failures and token storage in localStorage vs memory.

Security reviewers auditing token lifetime, algorithm choice (none alg attacks), and sensitive data exposure in claims.

DevOps engineers validating service-to-service tokens from Istio, AWS ALB, or Kubernetes service account JWTs in staging.

QA engineers confirming test user tokens carry expected roles before automated API test suites run.

Technical writers documenting claim schemas with decoded examples — using synthetic tokens, never production samples.

FAQ

Is my JWT sent to a server?

No. Splitting and Base64URL decoding run entirely in your browser.

Does this verify the signature?

No. Decoding displays header and payload only. Signature verification requires keys from the token issuer.

What if my token has more than three segments?

Likely a JWE encrypted token. This tool targets standard three-part JWS tokens.

Why does decode fail on my token?

Check for extra quotes, Bearer prefix (strip it), truncated copy-paste, or non-JWT strings.

How do I read exp timestamps?

Unix epoch seconds. 1719234000 converts to a UTC datetime. Compare against current time for expiry checks.

Can I decode unsigned tokens?

Structure may decode, but unsigned or alg: none tokens must be rejected by production verifiers.

What's the difference between JWT Decoder and JWT Parser?

Both inspect tokens. Decoder emphasizes human-readable claim display; Parser may emphasize field extraction, validation hints, or structured breakdown — use whichever matches your workflow.

Are refresh tokens JWTs?

Sometimes. Many refresh tokens are opaque strings. If it has three dot-separated Base64URL segments, try decoding.

Can I decode ID tokens from Google Sign-In?

Yes. Paste the credential JWT from the GIS callback for local inspection — do not log tokens in production apps.

Can I use this offline?

Yes, after initial page load.