Java Identifier Regex
Validates that a string is a syntactically legal Java identifier: it must start with a letter, underscore, or dollar sign, followed by any number of letters, digits, underscores, or dollar signs.
Regex Pattern
^[A-Za-z_$][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 |
| [A-Za-z_$] | The identifier must begin with a letter, underscore, or dollar sign |
| [A-Za-z0-9_$]* | Zero or more letters, digits, underscores, or dollar signs make up the rest of the identifier |
| $ | Anchors the match to the end of the string (end-of-string anchor, distinct from the literal $ allowed inside identifiers) |
Detailed Explanation
What it does
This pattern checks whether a string is shaped like a valid Java identifier for a variable, method, class, or field name. It requires the first character to be a letter, underscore, or dollar sign, and every subsequent character to be a letter, digit, underscore, or dollar sign, with no spaces or other punctuation.
Why it works
The Java Language Specification defines an identifier as starting with a Java letter (which includes underscore and dollar sign as valid 'letters' for identifier purposes) followed by any number of Java letters or digits. The two character classes reproduce that rule, and the ^/$ anchors ensure the whole string qualifies, not just a prefix, so a value like total-cost fails because of the hyphen.
Common use cases
- Validating class, method, or variable names generated dynamically by a code generator or annotation processor
- Checking that a JSON or config key can be safely used as a Java field name via reflection
- Linting auto-generated getters/setters or bytecode-manipulation targets before compilation
- Sanitizing user input before using it to build a dynamic class or package name
Edge cases
- A lone underscore, _, was a legal identifier in older Java versions but is now reserved and cannot be used alone, even though this pattern still matches it
- Dollar signs are technically legal anywhere in an identifier, matching compiler-generated names like Outer$Inner, even though hand-written code rarely uses them
- Identifiers with trailing digits, like value2, are valid since digits are allowed anywhere after the first character
- Java also permits many Unicode letters (e.g. café) in identifiers, which this ASCII-only pattern intentionally rejects
Limitations
- Does not exclude the 50+ reserved keywords (class, static, return, etc.), which are structurally valid but illegal as identifiers
- Does not flag the single underscore _, which is a reserved keyword as of Java 9 and cannot be used as an identifier by itself
- Only covers the ASCII subset of legal identifier characters and ignores Java's Unicode letter/digit identifier rules
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 javaIdentifierRegex = /^[A-Za-z_$][A-Za-z0-9_$]*$/;
console.log(javaIdentifierRegex.test('$dollarField')); // trueCommon Mistakes
Forgetting that Java identifiers may legally contain dollar signs, and writing [A-Za-z_][A-Za-z0-9_]* instead, which rejects compiler-generated names like Outer$Inner
Fix: Include $ in both the first-character and following-character classes
Assuming this regex rejects reserved keywords like class or synchronized, since they look like normal identifiers
Fix: Cross-check the matched string against Java's fixed list of reserved keywords in addition to the regex
Treating a lone underscore _ as always valid, when Java 9+ reserves it and disallows it as a standalone identifier
Fix: Add an explicit check that rejects the exact string "_" even though it structurally matches the identifier pattern
Performance Notes
- The two character classes don't overlap in what they consume, so the engine matches in linear time with no catastrophic backtracking
- Anchoring with ^ and $ lets invalid identifiers fail fast on the very first character
- Cheap enough to run per-token during parsing, annotation processing, or IDE-style live validation
Browser Compatibility
| Engine | Supported | Notes |
|---|---|---|
| Chrome | Yes | — |
| Firefox | Yes | — |
| Safari | Yes | — |
| Edge | Yes | — |
| Node.js | Yes | — |