PatternRegex
Match a JWT
Spot a JSON Web Token by its three dot-separated Base64url segments, the first of which always starts with the eyJ header prefix.
Last updated
Matches
- eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dGhpc2lzbm90YXJlYWxzaWc
- eyJhbGciOiJub25lIn0.eyJhIjoxfQ.abc-def_123
Doesn’t match
- not.a.jwt.token
- eyJhbGciOiJIUzI1NiJ9.onlytwosegments
Why it’s written this way
A JWT is three Base64url segments — header, payload, signature — joined by literal dots, and [A-Za-z0-9_-]+ matches that alphabet (note the underscore and hyphen instead of Base64's + and /). The literal eyJ prefix anchors the first segment because every JWT header starts as JSON with a '{' character, which happens to Base64url-encode to eyJ in virtually every real token.
The three-segment shape with two literal dots is what distinguishes this from the generic Base64url pattern you'd use for a single token part.
Edge cases to know
- →Matching this pattern proves the string has the right shape, never that the token is valid — it does not check the signature, the expiry claim, or that the payload is even legal JSON once decoded.
- →It assumes an unencrypted JWS-style token (three parts). Encrypted JWEs use five dot-separated parts and will not match.
- →The eyJ check is a heuristic, not a spec requirement — a header encoded with unusual key ordering or whitespace could in theory produce a different prefix, though this is vanishingly rare in practice.