Bearer Token Regex
Matches the value of an HTTP Authorization header using the Bearer scheme, such as 'Bearer <token>'.
Regex Pattern
^Bearer\s+[A-Za-z0-9\-_.]+$Pattern Breakdown
Hover over a token to see what it does.
| Token | Meaning |
|---|---|
| ^ | Anchors the match to the start of the string |
| Bearer | Literal, case-sensitive scheme keyword required by the HTTP Authorization header spec |
| \s+ | One or more whitespace characters separating the scheme from the token |
| [A-Za-z0-9\-_.]+ | One or more characters valid in common bearer tokens: letters, digits, hyphen, underscore, and dot |
| $ | Anchors the match to the end of the string |
Detailed Explanation
What it does
This pattern validates the full value of an Authorization header that uses the Bearer authentication scheme, verifying the literal keyword 'Bearer', at least one whitespace separator, and a token made up of URL-safe characters commonly found in opaque tokens and JWTs.
Why it works
The scheme name Bearer is matched literally and case-sensitively because RFC 6750 defines it as a fixed, case-sensitive token. The character class [A-Za-z0-9\-_.] covers the alphabet used by both simple opaque bearer tokens and base64url-encoded JWTs (which use dots to separate header, payload, and signature), so the pattern works for either token style without modification.
Common use cases
- Validating that an incoming Authorization header is well-formed before attempting to parse or verify the token
- Extracting the raw token value from a header for signature verification or introspection
- Filtering log lines to detect and redact Authorization headers before writing them to disk
- Writing middleware that rejects malformed Authorization headers early in a request pipeline
Edge cases
- JWTs, which include two internal dots separating header, payload, and signature, are matched because dots are included in the token character class
- Case sensitivity matters: 'bearer abc123' with a lowercase b does not match because Bearer is a case-sensitive literal per the HTTP spec
- Multiple whitespace characters between 'Bearer' and the token, such as a tab, are tolerated because \s+ matches one or more whitespace characters
- A header value with only the word 'Bearer' and no token is rejected since the token portion is required
- Tokens containing characters like + or / (standard base64 rather than base64url) will not match this stricter character class
Limitations
- Does not validate that the token itself is cryptographically valid or unexpired, only that it is well-formed
- Does not support standard base64 tokens using + and / without extending the character class
- Assumes a single space-separated scheme and token; does not handle multiple Authorization headers or comma-separated credentials
Interactive Tester
Edit the pattern or text below — matching runs live in your browser.
Test Cases
Editable — add your own inputs to see if they pass.
| Input | Expected | Result | |
|---|---|---|---|
| Pass | |||
| Pass | |||
| Pass | |||
| Pass | |||
| Pass | |||
| Pass | |||
| Pass |
Language Variants
Production-ready examples in 12 languages.
const bearerTokenRegex = /^Bearer\s+[A-Za-z0-9\-_.]+$/;
console.log(bearerTokenRegex.test('Bearer abc123')); // trueCommon Mistakes
Matching 'bearer' case-insensitively, accepting malformed headers that violate the HTTP Authorization scheme's case sensitivity
Fix: Keep the match case-sensitive since RFC 6750 defines the scheme name as the literal string Bearer
Using a plain space character instead of \s+, which fails on headers with a tab or multiple spaces
Fix: Use \s+ to tolerate any run of whitespace between the scheme and the token
Restricting the token character class too tightly and rejecting valid base64 tokens that include + or /
Fix: Extend the character class to include + and / if standard (non-URL-safe) base64 tokens are expected
Performance Notes
- The literal 'Bearer' prefix lets the regex engine fail fast on any header that doesn't start with the correct scheme
- The token character class [A-Za-z0-9\-_.]+ has no internal ambiguity, so no catastrophic backtracking occurs even on very long tokens
- Anchoring with ^ and $ ensures the entire header value is validated rather than just a substring
Browser Compatibility
| Engine | Supported | Notes |
|---|---|---|
| Chrome | Yes | — |
| Firefox | Yes | — |
| Safari | Yes | — |
| Edge | Yes | — |
| Node.js | Yes | — |