FHIR Debugger
Decode SMART on FHIR access tokens and id_tokens in your browser: claims, expiry, scope and fhirUser. Signature verification only with a JWKS you provide.
How to inspect a SMART token
- Paste an access token or id_token (a JWT: three base64url parts separated by dots).
- Read the decoded header (algorithm
alg, key idkid) and payload (claims), with the time claimsexp,iatandnbfconverted to readable dates and checked against the current time. - To check the signature, paste the authorization server's JWKS (the JSON at its
jwks_uri) and click Verify signature. Use Load sample to try it with a sample token and key set. - If the token has a
scopeclaim, send it to the Scope Analyzer to see what it grants.
The token is decoded and verified in this page and isn't sent anywhere, saved to your workspace or added to history.
Decoding is not verifying
Anyone can create a JWT with any claims. Decoding shows what the token says. Only verifying the signature against the issuer's public key shows that the issuer created it and that it hasn't been altered. Signature verification here supports RS256/384/512 and ES256/384/512 using the browser's Web Crypto API. Tokens with alg: "none" are flagged as unsigned and must never be trusted.
What to look for
| Claim | Check |
|---|---|
exp | In the future. Expired tokens are the most common cause of sudden 401s |
iss | The authorization server you expect |
aud | For access tokens, often the FHIR base URL; for id_tokens, your client_id |
scope | Matches what your app needs. Servers can grant less than you requested |
fhirUser (id_token) | The FHIR URL of the signed-in user, such as Practitioner/123 |
patient | Some servers include launch context in the token. The standard place is the token response |
Common SMART problems
- Opaque access tokens. Many servers issue access tokens that aren't JWTs. If decoding fails with a base64 or JSON error, the token is probably opaque. That's valid. Read the scope and context from the token *response* instead.
- Clock skew. A token that looks "not yet valid" (
nbforiatin the future) usually means the client's or server's clock is off. - Wrong key. "Signature did not verify" with the right token usually means the JWKS is from a different environment (sandbox vs production) or the key was rotated. Match the token's
kidto a key in the JWKS.
SMART on FHIR Developer Guide walks through discovery, launch, scopes and token responses end to end.
FAQ
Is it safe to paste a production token?
The token stays in this page. Still, a valid access token is a credential: anyone who has it can use it until it expires. Prefer expired or test tokens, and never paste tokens into tools that send them to a server.
Where do I get the JWKS?
From the authorization server's jwks_uri, listed in its .well-known/smart-configuration (or OpenID configuration). Open that URL and paste the JSON.
Which algorithms can it verify?
RS256, RS384, RS512, ES256, ES384 and ES512, using the browser's Web Crypto API. Symmetric (HS256) tokens can't be verified without the shared secret, and you shouldn't paste that here.
Why does decoding fail with a base64 or JSON error?
The token is probably opaque: a random string rather than a JWT. SMART doesn't require JWT access tokens. Read the scope and launch context from the token response instead.
FHIR Toolbox is a free collection of HL7 FHIR tools by Omindra Labs. The tools process your data in your browser; it is not uploaded for normal tool operations.