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.
Part by part
- ^eyJ
- A JWT header always begins with the JSON characters {" , which base64url-encode to eyJ. Anchoring on it is a cheap and surprisingly reliable way to spot a token.
- [A-Za-z0-9_-]+
- A base64url segment: the standard alphabet with hyphen and underscore replacing plus and slash, so the token survives being put in a URL.
- \.
- An escaped dot separating the three segments. Unescaped it would match any character and the structure would mean nothing.
- $
- Anchored at both ends, because this validates a whole token rather than finding one in text.
Common mistakes
^[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+$Dropping the eyJ prefix matches any three dot-separated base64url strings, which includes plenty of things that are not tokens. The prefix is what makes the pattern specific rather than merely structural.
^eyJ[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+$^eyJ[A-Za-z0-9+/=]+\.[A-Za-z0-9+/=]+\.[A-Za-z0-9+/=]+$Using the standard base64 alphabet is wrong for JWTs, which are base64url-encoded. Real tokens containing a hyphen or underscore fail, and the failure looks like a malformed token rather than a bad pattern.
^eyJ[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\.[A-Za-z0-9_-]*$Allowing an empty third segment accepts unsigned tokens with a trailing dot. That is a real format, and accepting it silently in a pattern used for authentication is how alg:none bugs survive review.
Questions
Does matching this mean the token is valid?
Absolutely not, and the distinction matters more here than anywhere else on this page. The pattern reads shape only. It cannot verify the signature, check expiry, or confirm the issuer — a forged token matches exactly as well as a real one.
Why does every JWT start with eyJ?
Because the header is JSON, so it starts with an opening brace and a quotation mark. Those two characters base64url-encode to eyJ every time, which is why the prefix is a dependable signal.
Can I use this to pull a token out of an Authorization header?
Not as written — it is anchored at both ends. Remove the anchors and match against the part after "Bearer ", or better, split the header on whitespace and validate the second field.
Is it safe to log a string that matches this?
No. A JWT is a credential for as long as it is valid, and the payload is only encoded rather than encrypted, so anyone reading the log can decode its claims. Redact tokens before they reach any log.