How to fix PGRST107: Invalid JWT in Supabase

Dump the incoming headers before they reach Supabase and make sure the request is still sending a bearer token. Many errors are simply typos or missing headers when running curl/fetch from the command line.

You can use curl to see exactly what reaches Supabase:

curl -v -X POST https://your-project.supabase.co/rest/v1/widgets   -H "apikey: YOUR_ANON_KEY"   -H "Authorization: Bearer YOUR_JWT"   -H "Content-Type: application/json"   -d '{"name":"test"}'

The Authorization line must exist, start with Bearer, and the token should have three dot-separated parts. If the header disappears before Supabase sees it, a proxy or middleware is stripping it and you will need to preserve the header or re-add it before forwarding the request.

Supabase exposes the current key set (JWKS) at https://<project>.supabase.co/auth/v1/.well-known/jwks.json. Decode your token (for example with https://jwt.io or a library) and check the kid and alg fields match one of the keys in the JWKS response. If they do not match, you are presenting a token signed by another project or an out-of-date key.

You can also use the jose library to verify locally:

import { createRemoteJWKSet, jwtVerify } from "jose";

const JWKS = createRemoteJWKSet(
  new URL("https://your-project.supabase.co/auth/v1/.well-known/jwks.json")
);

await jwtVerify(token, JWKS);

If this verification throws, the signature is invalid. Use Supabase Auth, the CLI supabase gen bearer-jwt, or the new signing keys page to mint a token that matches the active key.

When you rotate signing keys in the Supabase dashboard, the edge cache can keep the old key for ~10 minutes. During that window, tokens signed with the new key can trigger PGRST107 because PostgREST still trusts the old key. If you control the client, re-run supabase.auth.refreshSession() or sign the user out and back in so they receive a JWT signed with the current key.

If you rotate keys manually, wait at least 15–20 minutes before revoking the old key to ensure all caches (edge layers and custom runtimes) have the latest JWKS. The Signing Keys doc explains this timing and how to roll back if something breaks.

Supabase Auth also exposes a convenience endpoint that verifies whether a token is valid:

curl https://your-project.supabase.co/auth/v1/user   -H "apikey: <anon or publishable key>"   -H "Authorization: Bearer YOUR_JWT"

If this returns HTTP 200, Auth has already validated the signature and claims. If Auth rejects the token, fix the signing key/claims or regenerate the token with Supabase Auth before retrying the PostgREST request. Calling this endpoint is especially helpful when using shared secrets (legacy JWT secret or HS256 signing keys), because it avoids reinventing verification logic.