camelCase Identifier Regex
Validates that a string is a lowerCamelCase identifier: it starts with a lowercase letter and each subsequent word begins with a single uppercase letter followed by lowercase letters or digits.
Regex Pattern
^[a-z][a-z0-9]*(?:[A-Z][a-z0-9]*)*$Pattern Breakdown
Hover over a token to see what it does.
| Token | Meaning |
|---|---|
| ^ | Anchors the match to the start of the string |
| [a-z] | The identifier must begin with a lowercase letter |
| [a-z0-9]* | Zero or more lowercase letters or digits completing the current word |
| (?: | Start of a non-capturing group for each additional capitalized word |
| [A-Z] | An uppercase letter marking the start of a new word segment |
| )* | Closes the group and allows any number of additional word segments |
| $ | Anchors the match to the end of the string |
Detailed Explanation
What it does
This pattern checks that a string follows lowerCamelCase naming: it must start with a lowercase letter, and every subsequent 'hump' must begin with exactly one uppercase letter followed by lowercase letters or digits. Strings starting with an uppercase letter (PascalCase), containing underscores, or containing spaces are rejected.
Why it works
The leading [a-z][a-z0-9]* requires the identifier to open with a lowercase run, matching how camelCase variables always begin. The repeating group (?:[A-Z][a-z0-9]*)* then consumes zero or more additional words, each starting with a capital letter, letting the pattern accept identifiers of any number of humps such as myVariableName123 while the ^/$ anchors guarantee the entire string conforms, not just part of it.
Common use cases
- Linting variable, function, or property names against a camelCase style guide
- Validating JSON keys or API field names before accepting a payload
- Enforcing consistent naming conventions in code generation tools
- Detecting and flagging snake_case or PascalCase names that should be converted
Edge cases
- A single lowercase word with no capital letters, like camel, is valid since the repeating group is optional
- Identifiers with trailing digits, like myVariableName123, are valid because digits are allowed within any word segment
- Consecutive capital letters, like an acronym in camelCASE, still match because each capital can be treated as its own single-letter word segment under this simplified pattern
- An identifier starting with a digit, like 123camelCase, is rejected since the first character must be a lowercase letter
Limitations
- Does not specifically reject or flag acronym runs (XMLHttpRequest-style casing) as non-idiomatic camelCase
- Does not support Unicode letters outside the basic a-z/A-Z ranges
- Cannot verify that the identifier is actually a reserved word or otherwise invalid in a specific programming language
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 | |||
| Pass |
Language Variants
Production-ready examples in 12 languages.
const camelCaseRegex = /^[a-z][a-z0-9]*(?:[A-Z][a-z0-9]*)*$/;
console.log(camelCaseRegex.test('myVariableName123')); // trueCommon Mistakes
Writing [a-zA-Z0-9]+ to 'match camelCase', which actually matches PascalCase, snake_case-without-underscores, and almost any alphanumeric string too
Fix: Explicitly require a lowercase first character and structure subsequent words as (?:[A-Z][a-z0-9]*)* to enforce the actual camelCase shape
Not accounting for digits within words, causing valid identifiers like value2Add to be rejected
Fix: Include 0-9 in each word's character class, e.g. [a-z0-9]* and [A-Z][a-z0-9]*
Expecting this pattern to reject acronym-heavy names like getHTTPResponse
Fix: If strict word-boundary casing matters, add a more advanced check or a linter rule (e.g. ESLint camelcase) rather than relying purely on this regex
Performance Notes
- Both quantified character classes ([a-z0-9]* and the repeating group) are non-overlapping, so the engine matches in linear time with no catastrophic backtracking
- Anchoring with ^ and $ lets invalid identifiers fail fast on the very first character check
- This is cheap enough to run per-keystroke in an editor or linter without any noticeable performance cost
Browser Compatibility
| Engine | Supported | Notes |
|---|---|---|
| Chrome | Yes | — |
| Firefox | Yes | — |
| Safari | Yes | — |
| Edge | Yes | — |
| Node.js | Yes | — |