> For the complete documentation index, see [llms.txt](https://docs.userlane.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.userlane.com/assistance/in-app-guidance/validators/regex-patterns-for-input-validation.md).

# Regex patterns for input validation

Regex syntax and ready-to-use patterns for guide step input validation.

When a guide step asks someone to type a value, a validator[^1] can check what they enter against a regular expression (regex). This helps for fields like email addresses, postal codes, International Bank Account Numbers (IBANs), and time formats, where the expected input follows a known pattern. This article covers the syntax basics and ready-to-use patterns for common cases. For how to set the validation mode, see [Creating validators](/assistance/in-app-guidance/validators.md).

## Regex syntax primer

A regular expression is a pattern that describes what a valid input looks like. The table below covers the building blocks you need for most input validation rules.

<table><thead><tr><th width="132.654541015625">Element</th><th width="80.2742919921875">Syntax</th><th>What it does</th><th>Example</th></tr></thead><tbody><tr><td>Start anchor</td><td><code>^</code></td><td>Matches the beginning of the input</td><td><code>^Hello</code> matches "Hello world" but not "Say Hello"</td></tr><tr><td>End anchor</td><td><code>$</code></td><td>Matches the end of the input</td><td><code>world$</code> matches "Hello world" but not "world peace"</td></tr><tr><td>Digit</td><td><code>\d</code></td><td>Matches any single digit (0 to 9)</td><td><code>\d\d</code> matches "42"</td></tr><tr><td>Word character</td><td><code>\w</code></td><td>Matches a letter, digit, or underscore</td><td><code>\w+</code> matches "hello_123"</td></tr><tr><td>Any character</td><td><code>.</code></td><td>Matches any single character except a newline</td><td><code>h.t</code> matches "hat", "hit", "h9t"</td></tr><tr><td>Character set</td><td><code>[abc]</code></td><td>Matches any one of the listed characters</td><td><code>[aeiou]</code> matches any vowel</td></tr><tr><td>Zero or more</td><td><code>*</code></td><td>Repeats the previous element zero or more times</td><td><code>ab*c</code> matches "ac", "abc", "abbc"</td></tr><tr><td>One or more</td><td><code>+</code></td><td>Repeats the previous element one or more times</td><td><code>ab+c</code> matches "abc", "abbc", but not "ac"</td></tr><tr><td>Optional</td><td><code>?</code></td><td>Makes the previous element optional (zero or one)</td><td><code>colou?r</code> matches "color" and "colour"</td></tr><tr><td>Exact count</td><td><code>{n}</code></td><td>Repeats the previous element exactly n times</td><td><code>\d{5}</code> matches "80331"</td></tr><tr><td>Range</td><td><code>{n,m}</code></td><td>Repeats the previous element between n and m times</td><td><code>\d{3,5}</code> matches "123", "1234", "12345"</td></tr><tr><td>Alternation</td><td><code>|</code></td><td>Matches the expression on either side</td><td><code>cat|dog</code> matches "cat" or "dog"</td></tr><tr><td>Group</td><td><code>()</code></td><td>Groups elements together, often combined with alternation or quantifiers</td><td><code>(ab)+</code> matches "ab", "abab"</td></tr><tr><td>Escape</td><td><code>\</code></td><td>Treats the next special character as literal</td><td><code>\.</code> matches an actual period</td></tr></tbody></table>

Put `^` at the start and `$` at the end of every pattern. Without them, the regex matches any input that contains the pattern anywhere, rather than requiring the entire input to match.

## Common patterns

Each pattern below is ready to paste into the regex field in the Editor[^2]. The **Passes** and **Fails** columns show what to expect when you test.

<table><thead><tr><th width="132.20660400390625">What it validates</th><th width="132.4453125">Pattern</th><th width="204.6815185546875">Explanation</th><th>Passes</th><th>Fails</th></tr></thead><tbody><tr><td>24-hour time (HH:MM)</td><td><code>^([01]\d|2[0-3]):[0-5]\d$</code></td><td>Hours 00 to 23, colon, minutes 00 to 59</td><td>14:30, 08:00</td><td>25:00, 8:00 AM</td></tr><tr><td>12-hour time (H:MM AM/PM)</td><td><code>^(0?[1-9]|1[0-2]):[0-5]\d\s?(AM|PM)$</code></td><td>Hours 1 to 12, colon, minutes, optional space, AM or PM</td><td>2:30 PM, 12:00 AM</td><td>13:00 PM, 0:30 AM</td></tr><tr><td>Email address (basic)</td><td><code>^[^@\s]+@[^@\s]+\.[^@\s]+$</code></td><td>Something before @, something after, a dot, and a domain</td><td>user@example.com</td><td>user@, @example.com</td></tr><tr><td>German postal code</td><td><code>^\d{5}$</code></td><td>Exactly five digits</td><td>80331, 10115</td><td>8033, 103115</td></tr><tr><td>US ZIP code (with optional +4)</td><td><code>^\d{5}(-\d{4})?$</code></td><td>Five digits, optionally followed by a hyphen and four more</td><td>90210, 90210-1234</td><td>90210-12, 9021</td></tr><tr><td>German IBAN</td><td><code>^DE\d{20}$</code></td><td>Country code DE followed by exactly 20 digits</td><td>DE89370400440532013000</td><td>DE8937, de89370400440532013000</td></tr><tr><td>1 to 5 words</td><td><code>^(\S+\s+){0,4}\S+$</code></td><td>One to five groups of non-whitespace separated by spaces</td><td>"hello world", "one"</td><td>"this has six words in it"</td></tr></tbody></table>

These patterns are strict by design, which is usually what you want for form validation. If a pattern is too restrictive for a specific use case, loosen it by adjusting the character classes or quantifiers.

## Tips

Test every pattern before publishing. A wrong regex either blocks users from submitting valid input or silently accepts values that should fail. Use the test field in the Editor to try a few passing and failing inputs before saving.

If the expected input may contain special regex characters (periods, parentheses, plus signs), escape them with a backslash in the pattern. For example, match a literal period with `\.` rather than `.`, which matches any character.

The Editor can also draft a starting pattern from a plain-language description with AI. This uses the same AI service[^3] as the AI Assistant and saves time on unfamiliar formats. Always review and test the result before publishing.

## Relevant articles

{% content-ref url="/pages/BJ6uX7MdEouMq5jZDQtF" %}
[Creating validators](/assistance/in-app-guidance/validators.md)
{% endcontent-ref %}

{% content-ref url="/pages/1S0Ysrf45iMPMs4rp5yk" %}
[Creating guides](/assistance/in-app-guidance/creating-guides.md)
{% endcontent-ref %}

{% content-ref url="/pages/14ViydxzHwBkmZMnQj6h" %}
[AI features: what data is processed and where](/security-and-privacy/ai-features-what-data-is-processed-and-where.md)
{% endcontent-ref %}

## FAQ

<details>

<summary>Where do I enter the regex?</summary>

In the Editor, open the guide step that asks for input and select the specific value validation option. The regex field appears alongside an explanation field (shown to the user if the input fails) and a test field for trying patterns before saving.

</details>

<details>

<summary>Can I test the regex before publishing?</summary>

Yes. The Editor provides a test field next to the regex input. Type a sample value and the Editor shows whether it passes or fails against the pattern. Test with both valid and invalid inputs before saving the step.

</details>

<details>

<summary>What happens if the regex is wrong?</summary>

It depends on the validator mode. In **Visible** mode, the user sees an error message for every input, even valid ones. In **Warning** mode, the user is warned at submission but can override. In **Measure** mode, no message is shown, but the compliance data is inaccurate. In all three cases, a wrong regex undermines trust in the guidance, so test before publishing.

</details>

[^1]: A validator checks what someone types into a form field and records whether the entry matched. It runs in one of three modes: **Measure** (silent), **Visible** (inline hint), and **Warning** (message at submission).

[^2]: The Editor is the workspace where Userlane content is built, separate from the portal where content is targeted and analytics are viewed.

[^3]: The AI features in Userlane, including the regex generator and the AI Assistant, run on a model hosted by Microsoft. They do not use customer data for training. For details, see [AI features transparency](/security-and-privacy/ai-features-what-data-is-processed-and-where.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.userlane.com/assistance/in-app-guidance/validators/regex-patterns-for-input-validation.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
