A pattern analyzer takes a regular expression, uses it to split raw text into searchable tokens, and hands those terms to your search index. This guide shows how the regex decides where one token ends and the next begins, which parameters you can tune, and how the same idea of pattern analysis helps you sort error logs by their most common patterns.
How a Pattern Analyzer Splits Text into Tokens
Search engines such as Elasticsearch and OpenSearch run every field through an analysis chain before it reaches the index. The built-in analyzer of type pattern is one such chain. Its tokenizer applies your expression, its lower case token filter normalises the result, and an optional stop token filter removes filler words. The pattern analyzer therefore needs just one decision from you: what the token separators look like. Looking to calculate a password entropy? It works entirely in your browser and takes only a few seconds.
The expression you supply must match the token separators, not the tokens themselves. By default it is \W+, meaning one or more non-word characters. Because the analyzer treats the underscore as a word character, it never splits on it unless you say so. Here is a sentence I made up and the terms it produces:
"Ship-To: Anna_Lee's Parcel #88, Floor 3."
[ ship, to, anna_lee, s, parcel, 88, floor, 3 ]Notice that "anna_lee" survives as a single token while the apostrophe breaks "Lee's" into "lee" and "s" fragments, which is exactly what the default expression is built to do.
Tokenizer and Token Filters in the Definition
The built-in definition of the analyzer is two pieces: a pattern tokenizer followed by a lowercase filter, with the stop filter disabled. If you need behaviour beyond the configuration options, recreate it as a custom analyzer: declare a tokenizer of type pattern, then list the filters you want in order.
- Tokenizer
- Cuts the input wherever the expression matches.
- Token filter
- Changes, drops or adds tokens after the cut, for example lowercasing or removing stopwords.
Pattern Tokenizer Parameters and Defaults
You configure the analyzer through a handful of parameters in the index settings. Every one is optional, and the table shows what each does when you leave it alone. The free password crack time calculator breaks the math down step by step so the answer is never a black box.
| Parameter | Purpose | Default |
|---|---|---|
| pattern | Java regex that matches separators | \W+ |
| flags | Pipe-separated modifiers such as CASE_INSENSITIVE|COMMENTS | none |
| lowercase | Convert terms to lower case | true |
| stopwords | Predefined stop words list such as _english_, or your own array | _none_ |
| stopwords_path | File holding the stopwords, one per line | not set |
The regular expression flags use java syntax and are pipe-separated, so "CASE_INSENSITIVE|COMMENTS" turns on both. Since the expression sits inside a JSON string, backslashes must be escaped: write "\\W+" to send \W+ to the engine. Forgetting this is the most common reason a new configuration fails to load.
Regular Expression Examples with Generated Tokens
Seeing the generated tokens for a real input is the quickest way to trust a configuration. The two example output cases below both use the analyze endpoint against a throwaway index. Need to check a keyboard walk? There is a free, no-sign-up tool for exactly that.
Example Configuration for Email Addresses
To break an order reference such as [email protected] on non-word characters or underscores, use the alternation \W|_. This example configuration defines it in the mappings-ready settings block:
PUT parcels-001
{ "settings": { "analysis": { "analyzer": { "ref_analyzer": {
"type": "pattern", "pattern": "\\W|_", "lowercase": true } } } } }Running the analyzer on that reference returns [ order, 4471, shop, mail, org ], five clean terms that a search for "shop mail" will now match.
Splitting CamelCase Without Losing Digits
Developer data is full of identifiers like parseXMLFeed2Cache_v3. A longer expression using lookarounds can split on case changes and on the boundary between letters and digits, so camelcase names become searchable words: [ parse, xml, feed, 2, cache, v, 3 ]. Test the expression in a scratch environment first; one wrong lookahead can shred every term you index.
Stopwords and Lowercase in Practice
Switch on stopwords and the analyzer drops filler: "Latency of the Cache is Low" becomes [ latency, cache, low ] once the words "of", "the" and "is" are listed. Leave lowercase true unless case carries meaning in your data, because mixed-case queries then match without extra work.
Pattern Analysis of Error Logs and Test Failure
The same word has a second life in quality engineering. Tools like ReportPortal offer pattern analysis, a feature that scans logs from a run and labels every failed item whose message matches a saved pattern rule. It is built for failure analysis at scale: after a build with forty red tests, you want to know that twenty-six of them died for one reason, not read each trace.
You can run it automatically after every launch, or manually against a finished one. It works alongside auto-analysis, which assigns defect types, and the order matters: matching known patterns comes first, then defects are linked.
String Rule Versus Regex Rule
Two kinds of pattern rules exist. A string rule matches a plain problem phrase, such as "Connection refused: db-replica-7". A regex rule takes an expression such as timeout after [0-9]+ ms to catch a family of messages. Prefer the string form whenever it is enough, because it puts less work on the database.
- Open project settings and choose the pattern analysis tab.
- Create the rule and decide on string or regex.
- Start a run so the analysis happens after it finishes.
- Use the step view and apply a filter by pattern name to list every item that failed for that reason.
A "most popular pattern" widget on the dashboard then ranks the top reasons for each test failure over time, which tells you what to fix first.
Pathological Regular Expressions and Performance
A pattern analyzer runs your expression against every field of every document, so a careless one hurts performance and speed across the whole cluster. Pathological regular expressions backtrack so badly that matching runs slowly, and in the worst case the node throws a StackOverflowError and exits. Both engines use Java regular expressions, so the same risks apply on Elasticsearch and OpenSearch.
- Avoid nested quantifiers such as
(a+)+in the pattern. - Keep the expression anchored to separators, not to whole tokens.
- Replace the built-in analyzer with a stop token filter chain only when you must; fewer moving parts are easier to reason about.
Other Meanings of Pattern Analysis: Games and Stats
The name is also used outside engineering. A game stats site sharing that name covers tournaments, meta insights, winning compositions and pilots, offering win rates, performance metrics and other stats for competitive gaming. In the X-Wing miniatures game, a tech upgrade by the same name grants an ability: after you fully execute a red manoeuvre, you may perform one action.
These share only a name with the search analyzer, so check which one a query or doc is talking about before applying any advice from this page. The built-in search version, with its text splitting and expressions, remains the one to learn if you tune search.
Frequently Asked Questions
- Why does password strength matter?
- Weak passwords are the leading cause of account breaches. Attackers use automated tools that can try billions of combinations per second, so a short or predictable password can be cracked in seconds. A strong, unique password dramatically reduces the risk of unauthorized access to your accounts.
- What is a password pattern analyzer?
- A password pattern analyzer evaluates your password for common weaknesses such as sequential characters (abc, 123), repeated characters, dictionary words, and lack of character variety. It goes beyond simple length checking to identify structural patterns that make passwords easier to guess or brute-force.
- How does this password strength checker work?
- The tool scores your password based on length, presence of uppercase letters, lowercase letters, numbers, and symbols, as well as deductions for sequential characters, consecutive same-type characters, and repeated patterns. The score out of 100 maps to a strength rating and an estimated crack time.
- Is it safe to use an online password checker?
- Yes — this tool performs all analysis entirely within your browser. Your password is never transmitted to any server, stored, or logged. You can verify this by disconnecting from the internet before entering your password and confirming the tool still works.
- What makes a strong password?
- A strong password is at least 12–16 characters long and combines uppercase letters, lowercase letters, numbers, and symbols. It avoids dictionary words, predictable sequences like "123" or "abc", and personal information. Using a passphrase — a string of random words — can also be highly effective.
- What is password brute-forcing?
- Brute-forcing is an attack method where software systematically tries every possible combination of characters until it finds the correct password. The time required depends on password length and complexity — a 6-character all-lowercase password can be cracked almost instantly, while a 16-character mixed password would take centuries.
- What are the most common poor password practices?
- Common mistakes include using short passwords (fewer than 8 characters), relying on single dictionary words, substituting letters with numbers predictably (e.g. "p@ssw0rd"), reusing passwords across sites, and using sequential patterns like "123456" or "qwerty". These are the first patterns attackers try.
- What is a passphrase and is it more secure?
- A passphrase is a sequence of random words, such as "correct-horse-battery-staple". Because it is long, it has extremely high entropy and is very difficult to brute-force, yet easier to remember than a random string of characters. Passphrases of 4+ random words are generally considered very strong.