Paste the token and see exactly why it fails.

The string you handed to jwt.verify() (or jose's jwtVerify()) is not a valid JWS Compact Serialization: RFC 7515 defines a JWT as exactly three base64url segments joined by two period characters, header.payload.signature. jsonwebtoken says "jwt malformed" only when the value does not split into exactly three parts at the periods: the word Bearer alone, a secret or the text null passed as the token, or a five-part JWE. When there are three parts but a segment is not valid base64url or not JSON, for example because a "Bearer " prefix, quotes or a line break came along, it says "invalid token" instead. Both are structural errors, checked before signature or claims.

The signature check is byte-exact over the header and payload segments as they were originally encoded, so the usual causes are: the secret or key you're verifying with does not match the one that actually signed it (a rotated Supabase JWT secret, an old copy in an environment variable, the wrong project's key); the token was re-encoded after signing (even reformatting whitespace inside the JSON before re-encoding changes the signed bytes); or a secret got used where a public key was needed, or the reverse. Confirm the current key first, byte for byte, before assuming the token itself is broken.

Usually a clock mismatch, not a short-lived token. RFC 7519 defines "exp" as a NumericDate compared against the verifying server's own clock, and explicitly allows "some small leeway" for clock skew; if the machine verifying the token is more than a few minutes ahead of the one that issued it (common on a VM, container, or a laptop that just woke up), a token minted seconds ago already looks expired. Set the clock skew tolerance above to a few minutes to test that theory, and check NTP sync on whichever server verifies tokens.

An HMAC algorithm (HS256/HS384/HS512) uses one shared secret for both signing and verifying: whoever holds it can do either. An asymmetric algorithm (RS256/384/512, PS256/384/512, ES256/384/512) uses a private key to sign and a separate public key to verify; the public key can verify signatures but cannot create new valid ones. Pasting a public key where an HMAC secret is expected, or a shared secret where a public key is expected, cannot work, and is also the shape of a known "algorithm confusion" attack: a verifier must pin which algorithm and which kind of key it accepts, never trust the token's own header.alg to decide.

Nothing you paste is sent anywhere: decoding is plain base64url + JSON.parse, and signature verification runs through your browser's own Web Crypto API (window.crypto.subtle), entirely client-side. There is no backend for this tool and no request that carries the token or key. As general hygiene, still avoid pasting a production secret into any tool including this one, and prefer rotating a secret you're unsure about over trusting it stayed private.

Supabase access tokens are HS256, signed with your project's JWT secret from Project Settings → API (or verified via its published JWKS on newer projects using asymmetric keys): paste that as an HMAC secret above. A Supabase anon or service_role key is itself a JWT but is a static project API key, not a user session; it decodes fine but verifying it just confirms the JWT secret, not a login. Firebase ID tokens are RS256, signed by Google and issued with iss "https://securetoken.google.com/<project-id>": verify them against Google's public keys at googleapis.com/robot/v1/metadata/x509/securetoken@system.gserviceaccount.com, selecting the key whose "kid" matches the token's header. A Firebase custom token (minted server-side, has a "uid" claim) is different again: it must be exchanged client-side via signInWithCustomToken() before you get a verifiable ID token.