DevTools Hub

Search tools

Search for a developer tool

JWT

JWT Audience Validator

Check a JWT's aud claim against the audience your service expects.

Part of the JWT Toolkit

Comma or newline separated — the value(s) your service identifies itself as.

Audience matchesaud: array of strings
  • Match: "api.example.com" appears in both this token's "aud" claim and your expected audience list.
  • This token lists 2 audiences ("api.example.com", "web.example.com"). Every one of those services would accept this same token — the narrower the audience list, the smaller the blast radius if any one of those services is compromised.
Token's aud claim (2)
  • api.example.com
  • web.example.com
Expected audience(s) (1)
  • api.example.com

What this checks

Paste a token and the audience value(s) your service expects, and this checks whether the token's aud claim actually contains one of them — the same check your server-side verifier should be doing on every request, spelled out so you can see exactly why a token passes or fails.

What RFC 7519 actually requires

RFC 7519 §4.1.3 is direct about this: "If the principal processing the claim does not identify itself with a value in the 'aud' claim when this claim is present, then the JWT MUST be rejected." The spec also defines two valid shapes for aud — a single case-sensitive string when there's exactly one audience, or an array of case-sensitive strings when there are several. Both are legal, which is exactly the kind of detail that trips up hand-rolled verification code written to expect only one form.

Two ways this check gets quietly skipped

The RFC's MUST-reject rule only fires "when this claim is present" — it says nothing about a token that has no aud at all. Plenty of JWT libraries treat a missing claim as nothing to validate and let the token through by default, which is easy to mistake for "the token doesn't need an audience" rather than "audience validation was never actually configured." The second way is a comparison that's looser than the spec allows: matching audiences case-insensitively, or with a substring check instead of exact equality, can let a token meant for one service pass validation for another with a similar name.

FAQ

Is my token uploaded anywhere?

No — decoding and comparison happen entirely in your browser.

What's the difference between this and JWT Inspector?

JWT Inspector flags general red flags across a token — alg: none, missing expiration, unusually long lifetimes — without knowing anything about what audience your specific service expects. This tool does one focused check against a value you provide, the way an actual verifier would.

Does this check the signature or expiration too?

No — this is audience-only, by design. Check the signature with JWT Signature Verifier and expiration with JWT Expiration Checker. A real verifier needs all of these checks together — a valid audience on an expired or unsigned token is still a token you should reject.

My token has an azp or scope claim instead of aud — is that the same thing?

No. azp (Authorized Party, from OIDC) identifies the client the token was issued to, which can differ from who it's intended for. See JWT Claims Viewer for a plain-English breakdown of every standard claim, audience included.

Related tools