JWT Decoder

Paste a JSON Web Token (JWT) and get more than a decode: a security health report, annotated claims, a live expiry timeline, and a tamper playground. Everything runs in your browser.

Paste a token to decode it

100% client-side: nothing stored, nothing sent

Decoding, the health report, the playground, and every signature check run as JavaScript in this tab. The page keeps no history and writes nothing to localStorage; once it has loaded, it works with your network switched off. Try it.

Encoded JWT

every token tells a story

Paste any JWT above, or start with the sample to see the full read: header, payload, signature, and everything hiding in the claims.

Security health report Live expiry timeline Tamper playground Signature checks

100% local, works offline Decoding runs in this tab. Nothing stored, nothing sent; try it with your network off.

Token health report A security lint on every decode: algorithm, expiry, audience, size, and more.

Tamper playground Edit the payload and watch the signature break, exactly as a server would see it.

JWKS signature check Paste a JWKS or public key and verify RS256/ES256 signatures, fully in-browser.

Token diff Compare two tokens side by side: added, removed, and changed claims highlighted. Open compare → JWT encoder Mint test tokens with HS256 or a browser-generated RS256 key, then verify them here. Open encoder →

New here?

The Bridge issues tokens like these

This decoder inspects tokens; The Bridge is the platform that mints them. A login, hosted or in your own UI, ends with a signed JWT your services verify locally. And the token is just the start: users, plans, flags, and billing live on the same platform.

Every sign-in method

Email, passkeys, magic link, and Google all end the same way: a signed JWT with the user inside.
Login
Verification stays yours

Public keys are published as a JWKS, so each of your services verifies tokens locally, the same way this page's JWKS panel does.
JWT
Claims that carry authorization

Tenant, role, and plan ride the token, so your API authorizes straight from the payload this decoder pretty-prints.
RBAC
Sessions managed for you

Tokens issued, renewed, and revoked centrally. Block a user and they are out on the next request.
Control
User management built in

Profiles, workspaces, invites, and roles in one dashboard. The sub claim above points at a real, managed user.
Users
Login, your way

Hosted pages to ship today, or components in your own UI. Same tokens either way.
UI
Feature flags on the user

Flags ride the same user object the token carries, so gating by plan or role reads one source.
Flags
Billing engine included

Plans and payments wired to the user. The plan claim in the payload is the same one billing reads.
Billing

And of course

First-class SDKs for every stack

Type-safe, batteries-included SDKs with drop-in components, and the same clean user object everywhere.

Next.js

Svelte

Astro

Node

FastAPI

Laravel

Flutter

React

Angular

Nuxt

Deno

Python

Rust

Ruby

Kotlin

Vue

SolidJS

Remix

Bun

Django

PHP

.NET

NestJS

…and 24+ frameworks & languages supported. Hover to pause, drag or swipe to explore.

Common questions

Is it safe to paste a JWT here?

This decoder runs entirely in your browser: the token is split and base64url-decoded by a script on this page, nothing is stored, and no request carries the token anywhere. The one optional network call is fetching a JWKS URL you explicitly provide, and it sends only that URL. Even so, the safe habit is to treat every production token as a live credential and experiment with sample or expired tokens, here or in any tool.

Why can I read a JWT without the key?

Because a standard JWT is signed, not encrypted. The header and payload are base64url encoded, which is a reversible text encoding, not cryptography. The signing key is only needed to create a valid signature or to check one; reading the claims takes one line of code anyone can run. That is also why secrets never belong in a JWT payload.

Does decoding verify the token?

No. Decoding only reverses the base64url encoding; it proves nothing about who created the token or whether it was altered. Verification is a cryptographic check of the signature against the issuer's key. This page can run that check locally, with a pasted HS256 secret or a JWKS, but in production it is the step your application's JWT library must perform before trusting any claim. How verification, key sets, and rotation fit together is covered in the JWT authentication guide.

Is this a JWT validator?

It validates what can be validated in a browser: the health report lints the token against common security mistakes (alg none, missing expiry, long lifetimes, missing audience, oversized tokens, sensitive data in the payload), the timeline checks the time claims, and the signature checks confirm HS256 or JWKS-published keys. Your application's verifier remains the final authority, because only it knows which issuer, audience, and algorithms it should accept.

Can this decoder verify RS256 or ES256 signatures?

Yes, locally. Paste the issuer's JSON Web Key Set, the public-key document most issuers serve at a well-known URL, or a single public JWK. The tool picks the key matching the token's kid header, imports it with the browser's Web Crypto API, and checks the signature without any server involved. RS256/384/512, PS256/384/512, and ES256/384/512 are supported.

What does the tamper playground demonstrate?

The property that makes JWTs work: the signature covers the header and payload, so changing a single character breaks it. Edit any claim in the decoded payload and the signature status flips to red, which is exactly what a server sees when it verifies a tampered token. If you hold the HS256 secret you can re-sign the edited payload, demonstrating the other half: only the key holder can mint a valid token.

Can I create a JWT with this tool?

Yes. The encoder section mints tokens locally: edit the header and payload JSON and the token re-signs as you type, either with HS256 and a secret you supply or with an RS256 keypair generated inside your browser. The RS256 path also shows the matching public key as a JWKS document, so you can verify your own token in the JWKS panel. Minted tokens are for testing and learning; production tokens should only ever come from your auth server.

What are registered claims?

The seven claim names reserved by RFC 7519: iss (issuer), sub (subject), aud (audience), exp (expiration time), nbf (not before), iat (issued at), and jti (token id). They are standardized so every JWT library reads them the same way. This decoder annotates each one it finds, renders the time claims as dates, and also explains provider-specific claims from common issuers.