Firebase JWT Debugger

Decode Firebase Auth tokens with firebase.tenant, sign_in_provider, and custom claims.

Last updated: May 2026

shield

Private: Decoding, analysis, signature verification, and token generation all run in your browser. Nothing is sent to any server, except a JWKS URL you explicitly enter and click Verify on.

Paste your JWT

At a glance

Tenant claim: firebase.tenant (GCIP only)
Sign-in provider claim: firebase.sign_in_provider
Identities claim: firebase.identities
User identifier: sub (and user_id, mirrored)
Default algorithm: RS256

Firebase Auth ID tokens nest provider-specific data under the `firebase` claim object. Multi-tenant projects (built on Google Cloud Identity Platform) use `firebase.tenant` to identify the tenant. Custom claims set via the Admin SDK appear at the top level — this debugger separates them from standard registered claims so you can see your additions clearly.

Multi-tenant Firebase via GCIP

Firebase Auth's standard product gives you one auth context per Firebase project — for a true multi-tenant SaaS, you upgrade to Google Cloud Identity Platform. GCIP projects can have multiple tenants under one project, with isolated user pools and configuration per tenant.

When a user authenticates against a GCIP tenant, the resulting ID token includes `firebase.tenant` set to the tenant id (e.g. `tenant-acme-en2vw`). Your backend should validate this claim and use it for authorization scoping in the same way you'd use `tenant_id` on a custom JWT.

Frequently asked questions

When does firebase.tenant appear?expand_more

Only on Google Cloud Identity Platform (GCIP) projects with multi-tenancy enabled. Standard Firebase Auth projects don't have a tenant claim — there is exactly one tenant (the project itself).

How do I add custom claims to a Firebase token?expand_more

Use the Admin SDK's `setCustomUserClaims(uid, { ... })`. The next time the user's ID token is refreshed (within an hour, or sooner if you force a refresh), the claims appear at the top level of the token alongside `email`, `sub`, etc. Don't put more than 1000 bytes of custom claims — Firebase rejects oversized claim sets.

Why is sign_in_provider important?expand_more

It tells you how the user authenticated this session — `password`, `google.com`, `phone`, etc. For step-up auth (e.g., requiring fresh re-authentication for sensitive operations), check `auth_time` and `sign_in_provider` together to confirm the session came from a method strong enough for the operation.