/^/
MediumSecurity5 min read

Generic API Key Regex

Matches a generic API key shape: an optional underscore-separated prefix like sk_live_ followed by a 32-character or longer alphanumeric token.

#api-key#security#token#credentials#validation#secrets

Regex Pattern

^(?:[a-zA-Z0-9]+_)*[A-Za-z0-9]{32,}$

Pattern Breakdown

Hover over a token to see what it does.

^(?:[a-zA-Z0-9]+_)*[A-Za-z0-9]{32,}$
TokenMeaning
^Anchors the match to the start of the string
(?:Opens a non-capturing group for one prefix segment
[a-zA-Z0-9]+_Matches a prefix word followed by a literal underscore, e.g. sk_ or live_
)*Repeats the prefix segment zero or more times, allowing multi-part prefixes like sk_live_
[A-Za-z0-9]{32,}Matches the key body: 32 or more letters or digits
$Anchors the match to the end of the string

Detailed Explanation

What it does

This pattern recognizes the common shape of vendor API keys: zero or more underscore-terminated prefix words, such as sk_ and live_, followed by a long alphanumeric secret of at least 32 characters. It matches both prefixed keys like sk_live_4f6e2a1b9c8d7e6f5a4b3c2d1e0f9a8b and bare 32+ character tokens with no prefix at all.

Why it works

The repeated non-capturing group (?:[a-zA-Z0-9]+_)* greedily consumes any number of alphanumeric-plus-underscore prefix segments, since each segment must end in a literal underscore. Once no more underscore-terminated segments remain, the final [A-Za-z0-9]{32,} requires the remaining tail of the string to be a purely alphanumeric run of at least 32 characters, which is what most providers use for the actual secret entropy.

Common use cases

  • Detecting hardcoded API keys during a pre-commit secret-scanning check
  • Validating the shape of a key pasted into a settings form before storing it
  • Flagging suspicious strings in logs that may be leaked credentials
  • Building a first-pass filter before a stricter, provider-specific key format check

Edge cases

  • A bare 32-character alphanumeric token with no prefix, like a raw API secret, is valid since the prefix group is optional
  • Multi-segment prefixes like sk_live_ or pk_test_ are both valid because the prefix group can repeat
  • A token shorter than 32 characters, even with a valid-looking prefix, is rejected by the {32,} minimum length requirement
  • Any non-alphanumeric, non-underscore character, such as a hyphen or exclamation mark, breaks the match since neither the prefix nor body class permits it

Limitations

  • This is a generic shape check, not a validator for any specific vendor format like Stripe, AWS, or GitHub tokens, which each have their own stricter conventions
  • A string matching this pattern is not guaranteed to be a real, active credential, only that it looks like one structurally
  • Does not verify checksum bytes or embedded metadata that some providers include in their key formats

Interactive Tester

Edit the pattern or text below — matching runs live in your browser.

//
Open in Playground →
sk_live_4f6e2a1b9c8d7e6f5a4b3c2d1e0f9a8b 4f6e2a1b9c8d7e6f5a4b3c2d1e0f9a8b pk_test_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Test Cases

Editable — add your own inputs to see if they pass.

InputExpectedResult
Pass
Pass
Pass
Pass
Pass
Pass
Pass
Pass

Language Variants

Production-ready examples in 12 languages.

const apiKeyRegex = /^(?:[a-zA-Z0-9]+_)*[A-Za-z0-9]{32,}$/;
console.log(apiKeyRegex.test('sk_live_4f6e2a1b9c8d7e6f5a4b3c2d1e0f9a8b')); // true

Common Mistakes

Treating a regex match as proof the key is valid and active, then skipping server-side verification against the issuing provider

Fix: Use this pattern only as a fast pre-filter, such as in a secret scanner, and always verify real keys against the provider API

Hardcoding a fixed total length instead of a minimum, which breaks when a provider later issues longer keys

Fix: Use an open-ended quantifier like {32,} rather than an exact {32} so longer valid keys still match

Using this generic pattern to validate a specific provider format like a GitHub token or JWT, which have their own distinct structures

Fix: Write a provider-specific pattern for strict validation, and reserve this generic pattern for broad detection

Performance Notes

  • The repeated prefix group (?:[a-zA-Z0-9]+_)* can backtrack on pathological input with many underscores and no valid tail, so bound total input length before matching in security-sensitive contexts like log scanning
  • Anchoring with ^ and $ prevents matching a key-shaped substring embedded inside a longer, unrelated string
  • For scanning large log files, run this regex only against candidate lines pre-filtered by a cheaper substring check to avoid unnecessary regex evaluations

Browser Compatibility

EngineSupportedNotes
ChromeYes—
FirefoxYes—
SafariYes—
EdgeYes—
Node.jsYes—