Back to All Tools

JWT Decoder

Decode a JSON Web Token to inspect its header and payload. Everything runs in your browser — your token is never uploaded.

Complete Guide

About the JWT Decoder

Paste a JSON Web Token and see its header and payload decoded into readable, pretty-printed JSON instantly — including issued-at and expiry claims converted from Unix epoch seconds into your local time, with expired tokens flagged in red. Decoding runs entirely in your browser, so production tokens containing user identifiers or permissions are never uploaded. A sample token is one click away if you just want to see how the format works.

Three dot-separated segments

Every JWT is three Base64URL-encoded parts joined by dots: header, payload, signature. This tool decodes the first two — the header names the signing algorithm and token type, while the payload carries the claims: subject identifiers, roles, issued-at, expiry, and whatever custom data your service embeds. The signature segment stays as-is because it is binary, and decoding it visually tells you nothing. Note that neither decoded part is encrypted; JWTs are signed, not sealed, so anyone holding the token can read every claim inside it.

Decoding is not verification

Stated plainly, because it trips people up: this tool reads the token, it does not validate it. Anyone can edit a payload's claims and re-encode the segments — the changes show up perfectly decoded here even though the signature no longer matches. Genuine verification recomputes the signature from header and payload using the secret key (symmetric algorithms) or checks it against the public key, and only your backend has those. Treat decoded output as documentation of what the token claims, never proof that the claims are true.

Debugging exp and other timestamps

The claims that cause the most confusion are numeric epoch timestamps: seconds since January 1st, 1970 UTC. The decoder converts iat, exp, and nbf into human-readable local dates and compares expiry against your system clock — a red Expired chip means the timestamp has passed, though whether access is actually revoked is always the server's call, since some services refresh tokens rather than rejecting them outright. Keep clock skew in mind too: a token that looks valid on your machine can be expired by a server whose clock differs by minutes, which is why authentication systems build small leeway windows around exp checks. When a session mysteriously dies, checking whether exp passed is usually step one.

Where JWTs come from

You will typically fish them out of the Authorization header, where they follow the word Bearer, or from browser storage where single-page applications park their session tokens. Tokens also surface in callback URLs and WebSocket connection strings. Wherever yours came from, pasting it here is safe: parsing is pure local computation with no network requests, so the token never leaves the tab — but as with any shared clipboard, avoid pasting live credentials into screenshare recordings.

Video slot: jwt-decoder-walkthrough.mp4

Pasting a sample token, walking through header and payload claims, and demonstrating the expiry conversion with an expired versus active token.

Coming soon
Simple Step-by-Step Guide

How to Use JWT Decoder Online

Follow these simple steps to use JWT Decoder securely in your web browser.

  1. 1

    Paste JWT Token

    Paste or enter your encoded JWT token string into the decoder input area.

    01-jwt-decoder-paste-jwt-token.png

    Replace with a real capture

  2. 2

    Select and Decode Claims

    Click to select and inspect color-coded decoded JSON for Header and Payload claims.

    02-jwt-decoder-select-and-decode-claims.png

    Replace with a real capture

  3. 3

    Check and Convert Timestamps

    Click timestamps to convert and view human-readable dates for iat, exp, and nbf claims.

    03-jwt-decoder-check-and-convert-timestamps.png

    Replace with a real capture

Technical Specs

Features & Specifications

Format Standard

RFC 7519 JSON Web Token

Decoding Engine

Base64URL Unicode Parsing

Validation

Expiration & Token Integrity Inspection

Privacy Status

100% In-Browser Local Processing

100% Free & Private In-Browser Processing

Rupix operates on a zero-upload architecture. All computations, file parsing, and transformations occur locally inside your web browser. No document bytes, sensitive text, or personal data are ever uploaded or transmitted to remote servers.

Highlights

Why use Rupix JWT Decoder?

Syntax Highlighted Claims

Color-coded viewer for token headers, claims, and signature structure.

Expiration & Timestamps

Converts Unix epoch timestamps into human-readable local dates.

100% Client-Side Privacy

Tokens are decoded locally; sensitive auth credentials never leave your browser.

Q&A

Frequently Asked Questions

Yes. Decoding is entirely client-side and makes zero network requests — the token exists only in your browser's memory.
No. It inspects header and payload claims; signature verification requires the backend's secret or public key and belongs server-side.
The numeric exp claim is interpreted as Unix epoch seconds, rendered as a human-readable local date, and compared against your current system time.
No. Standard signed tokens (JWS) decode fully; encrypted tokens hide their payload behind encryption and require the private key.
Yes — editing and re-encoding the payload is trivial. Only signature verification by the service that owns the key establishes authenticity.
It names the signing algorithm, such as HS256 or RS256. Your verifier must enforce which algorithm it accepts, since blindly trusting the header enables known downgrade attacks.
Enforcement belongs to the server. Some APIs accept slightly stale tokens pending a silent refresh, so treat the indicator as informational about the claim itself.
An unsigned token using the alg none variant omits the third segment. Most production systems reject these, but they occasionally appear in local development setups.