Browser 106

no file limit

Inspector security/jwt-verify

JWT Verifiëren

Overview

Paste a JSON Web Token and its header and payload are decoded and shown straight away — that needs no secret, so this works on a token you were handed and hold no key for. Supply the shared secret and the HMAC signature is checked as well, for HS256, HS384 or HS512. The two verdicts stay apart on purpose: whether the signature is genuine and whether the token has expired answer different questions, and collapsing them into one 'valid' hides which of the two actually failed. Verification runs on the browser's own Web Crypto, so the token and the secret never reach a server, which makes it usable for debugging an auth problem with the real values rather than a redacted copy.

Pinning Down an Auth FailurePaste the token a service rejected and see at a glance which fact is wrong: the signature, the expiry, or neither — in which case the problem is elsewhere in the request.
Reading Claims Without a KeyInspect the subject, issuer, issued-at time and any custom claims in a token from a system whose secret you do not have and should not have.
Checking What Staging IssuesConfirm that tokens coming out of a staging environment carry the algorithm and claim structure you expect before the same code ships.
Reviewing Token HygieneCheck that the header names a real HMAC algorithm rather than 'none', and that an expiry claim is present and short enough to be worth having.
Seeing How a Token Is BuiltWatch a real token split into header, payload and signature, and see that only the third part depends on a key — the point most explanations of JWTs skip.

Set

Beveiligingstools 26

Neighbours

01 AES Bestand & Tekst Encryptor 02 Base64 Decoderen 03 Base64 Coderen 04 CSR Generator 05 DER naar PEM Converter 06 Hash Generator

Specification

Command: security.jwt_verify
Set: Security
Input: text
Output: —
Max. bestand: no limit
Batch: single file

Runtime

Engine: WebCrypto · OpenPGP.js
Threads: single
Isolated: —
WebGPU: —
Memory: —

Transport 0 B

The file is opened, worked on and written back inside this tab. No upload step exists in this tool — there is nowhere for the bytes to go.

Keys

Zoeken: ⌘K
Panels: ⌘1 · ⌘2
Full width: F
All keys: ⌘/

How it works

Paste the token

The header and payload are decoded and shown straight away. Reading what is inside a token needs no secret, so this works even when you do not have one.

Add the secret for the signature

Enter the shared secret and the signature verdict appears. Without one, the decoded header and payload above stay exactly as they were — the two do not depend on each other.

Read expiry separately

Whether the token has expired is reported as its own fact, apart from the signature, because they answer different questions: a correctly signed token can be long out of date, and an in-date one can be forged.

Frequently asked

What does verification actually check?

Two separate things, reported separately. The signature check recomputes the HMAC over the header and payload with the secret you supply and compares it with the one in the token, which tells you whether the claims were edited after signing. The expiry check reads the 'exp' claim against the current time. A correctly signed token can be long out of date, and an in-date token can be forged, so neither answer stands in for the other.

Why is my verification failing?

Usually the secret is not the one the token was signed with, the token was copied with a character missing or a line break inserted, or the service signs with a different HMAC digest than the one selected here. Because expiry is reported on its own row, an expired token still shows whether its signature is genuine, which narrows this down quickly.

Can I decode a token without verifying it?

Yes, and that happens by default. The header and payload are decoded and shown the moment you paste, with no secret involved — reading what is inside a token needs no key. The secret only adds the signature verdict; the decoded claims above it do not change.

Is it safe to paste a real token here?

The token and the secret are used in your browser and are not sent anywhere. A token is still a credential while it is valid, so the usual care applies to where you copied it from and who is looking at your screen — but nothing here transmits or stores it.

What information is in a JWT payload?

Typically a subject ('sub'), an expiry ('exp'), an issued-at time ('iat') and an issuer ('iss'), plus whatever custom claims the application added. None of it is encrypted; Base64url is an encoding, not a secret, which is why anything genuinely confidential does not belong in a token.

Keys

Zoeken: ⌘K
Panels: ⌘1 · ⌘2
Full width: F
All keys: ⌘/

Gerelateerd · Beveiligingstools