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,}$

Token	Meaning
^	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

3 matches

Test Cases

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

Input	Expected	Result
		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

Engine	Supported	Notes
Chrome	Yes	—
Firefox	Yes	—
Safari	Yes	—
Edge	Yes	—
Node.js	Yes	—

Work with this pattern

Take this expression further — test it against your own data, adapt it in the builder, or read up on the syntax behind it.

Regex Tester

Test a regular expression against sample text and see every match highlighted live.

Regex Generator

Build a pattern by clicking blocks — no syntax memorisation required.

Regular Expressions Guide

What regex is, how the syntax works, and the mistakes that trip people up.

Regex Cheat Sheet

Every token, quantifier, and assertion on one printable page.

Python Regex Guide

The re module end to end — search, match, findall, groups, and substitution.

Regex Pattern Library

100+ ready-to-use patterns for email, URLs, dates, IPs, and more.