Skip to content
shadcn.io

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.

Framework
UI library

Preview

Preview width

Installation

Part of Pro
Pro unlocks the code and one-line install of every Pro button and text effect, plus the MCP for your AI editor.
Have Pro already? Sign in to open it.Opens here as soon as you're Pro.

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.

How does it look on a phone?

The two columns stack: the token and the decoded tree first, then the signature and the claims. The foot is pinned to the bottom of the screen with the status above Sign in. The decoded tree scrolls inside its own box, and the box takes focus so a keyboard can scroll it.

  • 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 devices

    A 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 consent

    A 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 reset

    A 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.