shadcn.io is not affiliated with official shadcn/ui
JWT Debug Login Block for React
A panel that decodes a pasted JWT in the page, with its header and payload in a tree, its claims set out and an HS256 signature really checked against a typed sample secret.
Installation
Overview
Let people see what a sign-in token says before they trust it, with this JWT debug login block for React with Base UI. It's a debugger from Vouchlane, an authentication platform: a short header with a sample picker over one framed panel with a plus mark on each corner. A Textarea takes the token and a strip of three cells counts its parts; the header and payload are decoded in the page as you type, base64url and JSON, and shown in a JSON Tree View; a Data List sets out the claims (subject, issuer, audience, issued and expires in UTC) and says whether the token is expired against the demo's own "now", never the clock. An HS256 signature is checked for real: the HMAC-SHA256 of the header and payload is worked out in the page under a typed sample secret, so editing the payload or the secret changes the verdict, and a token signed with another algorithm says it needs the issuer's key. A Copy Button copies the payload, and the foot's Shine Button signs in with the token once it decodes, is signed and hasn't expired. It's built from Textarea, JSON Tree View, Data List, Copy Button, Native Select, Input, Shine Button and Guides. For auth platforms, API consoles and any sign-in that takes a token.
FAQ
What stays in the page, and how do I wire it for real?
Everything. The token is decoded, and its signature checked, in plain functions in this page; the sample secret is typed in the block, not a real key, and neither the token nor the secret is sent, stored or logged. Sign in waits less than a second and says what a real product would do, with nothing sent. In your app, send the token to your auth endpoint, and let your server decide: it holds the real key, and a browser should never be the judge of a signature.
What does decoding mean, and what does it not do?
A JWT is three base64url parts joined by dots. The first two are JSON, so anyone can read them: decoding is not decrypting and proves nothing. The third part is the signature, which only the holder of the key can make. The page reads the first two with atob and TextDecoder, and says in one sentence what is wrong when a part isn't base64url or isn't JSON.
How is the signature really checked?
For HS256 the page computes HMAC-SHA256 over header.payload under the secret in the field with a small SHA-256 written in the block, and compares it with the token's third part. The four samples show the verdicts: Valid, Expired (valid signature, past its expiry), Altered after signing (the payload was edited after it was signed, so the signature no longer matches) and RS256, which needs the issuer's public key and so says it can't be checked here. Change one character of the payload or the secret and the verdict changes.
Why does it say expired against a fixed time?
The page never reads the clock: it judges every token against a typed "now" (16 Oct 2026, 09:30 UTC), so the claims read the same for everyone and the samples stay valid, expired or altered however long the page is open. Swap AS_OF for the current time in your app.
When does Sign in refuse?
When the token doesn't decode, is unsigned (alg none), has a signature that doesn't match the secret, needs a secret and has none, or has expired. Each puts one sentence in the foot and moves focus to the field to fix. A token signed with another algorithm goes in, and the status says its signature was not checked. The button is never disabled, so keyboard users can always reach it and be told why.
Related
- Pro
A sign-in for a data-pipeline service where you paste a token and chips say whether it is a personal token or a JWT, with its length and expiry worked out from a typed rule, and a list of token formats.
- Pro
A sign-in for a messaging API with Password and API key as two tabs, where the key tab checks a key's prefix and length and shows a curl line that rewrites itself with the key masked.
- Pro
A split sign-in page where you drop a key file or paste a PEM key and a readout checks its BEGIN and END lines, its base64 body and shows its SHA-256 fingerprint, all in the tab.
- Pro
Session Expired Login
Sessions and devicesA re-authentication page for a document editor that keeps the email read-only, asks only for the password, shows where you were, and confirms before switching account.
- Pro
OAuth Consent Login
Sign-up and consentA consent screen for a calendar when a scheduling app asks for access: two required permissions shown locked, two optional ones you can untick, a button that counts what it grants and a scope details disclosure.
- Pro
Account Locked Login
Recovery and resetA locked-account page for a point-of-sale system that draws the lockout ladder, marks the rung the account is on with a fixed unlock time, and offers an unlock link by email or a password reset.