Kotlin Regex: A Guide to Regular Expressions

String manipulation in Kotlin gets messy fast without the right tools. Kotlin regex gives you pattern matching, text extraction, and input validation through a single Regex class that’s cleaner than anything Java offers.

But the syntax can be tricky. Escaping rules change between raw strings and regular strings. Functions like find(), matchEntire(), and replace() behave differently in ways that catch even experienced developers off guard.

This guide covers how to create and use regular expressions in Kotlin, from basic string matching to capturing groups, performance optimization, and cross-platform differences in Kotlin Multiplatform projects. You’ll get practical patterns for email validation, phone number extraction, and password checking that you can drop into your code today.

What Is Kotlin Regex

Kotlin regex is a pattern-matching system built directly into the Kotlin standard library through the Regex class. It lets you search text, extract substrings, validate input, and replace content using patterns instead of manual string operations.

The Regex class lives in kotlin.text and wraps java.util.regex.Pattern on the JVM. But it doesn’t just pass things through. Kotlin adds its own extension functions, cleaner syntax, and functional programming hooks that make the whole experience less painful than raw Java regex.

Here’s the thing most people don’t realize right away. Kotlin treats regex as a first-class citizen. You get dedicated methods on the Regex class itself, like find(), findAll(), replace(), and matchEntire(). No more chaining Pattern.compile().matcher().find() calls like in Java.

How Kotlin Regex Differs from Java Pattern

The difference is mostly about ergonomics. Java forces you through a multi-step process: compile a Pattern, create a Matcher, then call methods on the Matcher. Kotlin collapses that into one or two lines.

API comparison:

Kotlin’s MatchResult is immutable. Java’s Matcher is a stateful object that changes as you call find() repeatedly. That alone makes Kotlin regex safer in concurrent code.

JetBrains reports that 95% of the top 1,000 Android apps include Kotlin code, according to Dice. That means most Android text processing and input validation happening today runs through Kotlin’s regex API, not Java’s.

When You Actually Need Regex in Kotlin

Not every string operation needs a regex. Kotlin gives you contains(), startsWith(), split() with plain delimiters, and a bunch of other String methods. Those are faster and clearer for simple cases.

Regex makes sense when patterns get dynamic. Email validation, extracting timestamps from log files, parsing URLs with variable path segments. Anything where the structure is consistent but the content changes.

Research estimates that more than a third of JavaScript and Python projects include regex patterns. Kotlin projects, especially in Android development, follow a similar trend because of the amount of input validation and text processing mobile apps require.

How to Create a Regex in Kotlin

There are three ways to create a regex object in Kotlin. Each produces the same compiled pattern under the hood, so this is mostly about readability and personal preference.

The Regex constructor: Regex("\d{3}-\d{4}")

The toRegex() extension: "\d{3}-\d{4}".toRegex()

Literal factory: Regex.fromLiteral("abc") (treats everything as literal text, no metacharacters)

Most Kotlin developers prefer toRegex() because it chains nicely and reads left-to-right. The constructor is fine too. fromLiteral() only makes sense when you want to match a string that happens to contain characters like . or and you don’t want to escape them.

Raw Strings and the Backslash Problem

Escaping is where beginners trip up the most. In a regular Kotlin string, you need double backslashes for regex metacharacters. So d becomes "\d". It gets ugly fast with complex patterns.

Triple-quoted raw strings fix this. Inside """...""", a backslash is just a backslash. Your regex reads exactly like it would in a regex tester tool.

Compare these two:

• Regular string: "^[A-Za-z0-9.%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,6}$"
• Raw string: """^[A-Za-z0-9.%+-]+@[A-Za-z0-9.-]+.[A-Za-z]{2,6}$"""

The raw string version is easier to read, easier to copy into regex testers, and less likely to hide bugs. A survey of 158 software developers found that 94% reuse regex patterns from other sources. Raw strings make that copy-paste workflow much cleaner in Kotlin.

RegexOption Flags and What They Change

You can pass one or more RegexOption values when creating a regex. These modify how the pattern engine behaves.

IGNORECASE: makes matching case-insensitive, so abc matches ABC.

MULTILINE: changes ^ and $ from matching start/end of the entire string to matching start/end of each line.

DOTMATCHESALL: makes . match newline characters too (normally it doesn’t).

COMMENTS: lets you add whitespace and comments inside patterns for readability.

LITERAL: treats the entire pattern as literal text.

UNIXLINES: only recognizes n as a line terminator.

Combine multiple options with setOf():

"pattern".toRegex(setOf(RegexOption.IGNORECASE, RegexOption.MULTILINE))

One option that trips people up: CANONEQ (canonical equivalence). It’s available through the Regex constructor but rarely needed unless you’re dealing with Unicode normalization edge cases.

Kotlin Regex Functions for Matching

The Regex class gives you five main matching functions. Picking the wrong one is a common source of bugs, especially between matches() and containsMatchIn().

Boolean Checks with containsMatchIn and matches

containsMatchIn() returns true if the pattern appears anywhere in the input string. It’s the equivalent of searching for a substring, but with pattern support.

matches() requires the entire input string to match the pattern. Not just a piece of it. The whole thing.

This distinction burns people regularly. If your pattern is d+ and your input is "abc123def", containsMatchIn() returns true (there are digits in there). But matches() returns false because the whole string isn’t just digits.

Kotlin also provides String.matches(regex) as an extension function. It behaves identically to regex.matches(input). Choose whichever reads better in context.

Extracting Results with find and findAll

Single match: find() returns the first MatchResult or null if nothing matches. You get the matched value, its index range, and any captured groups.

All matches: findAll() returns a Sequence<MatchResult>. It’s lazy, meaning it doesn’t compute all matches upfront. That matters when processing large text.

Both accept an optional startIndex parameter if you want to begin matching from a specific position. Default is 0.

matchEntire() is the strict cousin. It tries to match the entire input (like matches()) but returns a MatchResult instead of a boolean. Useful when you want to validate AND extract groups in one step.

MatchResult Properties

Every successful match gives you a MatchResult with these:

• value – the actual matched text
• range – the start and end indices within the input string
• groupValues – a list of all captured group values (index 0 is the full match)
• groups – a MatchGroupCollection for accessing named groups
• destructured – a shortcut for pulling group values into variables

The destructured property is pure Kotlin convenience. You won’t find anything like it in Java’s Matcher class. It lets you do things like val (year, month, day) = result.destructured in a single line.

Capturing Groups and Destructuring

Capturing groups are the real power of regex. They let you not just match text but pull out specific parts of it. Kotlin makes this significantly cleaner than Java through destructuring declarations and named group access.

Numbered Groups

Every set of parentheses in a regex pattern creates a numbered group. Group 0 is always the full match. Group 1 is the first set of parentheses, group 2 the second, and so on.

Access them through MatchResult.groupValues. It’s a plain List<String>, so groupValues[1] gives you the first captured group.

Took me a while to internalize this: if a group is optional and didn’t participate in the match, groupValues returns an empty string for it. Not null. That’s a Kotlin-specific choice that avoids null checks but can mask bugs if you’re not careful.

Named Groups

Numbered groups get confusing fast in complex patterns. Named groups solve that. The syntax is (?<name>...) inside the pattern.

Then access them with matchResult.groups["name"]?.value. It returns a MatchGroup? (nullable), so you need the safe-call operator.

Named groups make patterns self-documenting. Instead of remembering that group 3 is the port number, you write (?<port>d+) and call it by name. Your colleagues will thank you for that during the code review process.

Destructuring Declarations

This is where Kotlin really shines.

The destructured property on MatchResult exposes component functions. You can pull capture groups directly into variables with a single expression:

val (protocol, host, path) = regex.find(url)!!.destructured

It maps component1() to group 1, component2() to group 2, and so on. Clean, readable, and it plays nicely with Kotlin data classes if you’re mapping matches to objects.

Quick warning: destructuring only works with numbered groups. Named groups don’t participate. If your pattern uses only named groups, you’ll still need to access them through the groups collection.

Replace and Split with Kotlin Regex

Matching is half the picture. The other half is transforming text. Kotlin’s Regex class gives you replace(), replaceFirst(), and split() for this. And the lambda-based replacement is where things get interesting.

Basic String Replacement

replace(input, replacement) swaps every match in the input with the replacement string. Simple enough.

Backreferences work inside the replacement string. Use $1, $2 for numbered groups or ${name} for named groups. This lets you restructure matched text without writing any extra logic.

Example: reformatting dates from MM/DD/YYYY to YYYY-MM-DD is just a single replace() call with backreferences. No parsing, no splitting, no temp variables.

replaceFirst() does the same thing but stops after the first match. Use it when you only need to fix the first occurrence.

Lambda-Based Replacement

This is the feature I reach for most. Instead of a static replacement string, you pass a lambda that receives the MatchResult and returns whatever you want.

The possibilities open up fast. You can capitalize matched words, look up values in a map, do math on captured numbers, or conditionally replace based on context. Every match gets processed individually.

Netflix, one of the companies that adopted Kotlin early for Android apps, processes massive volumes of text data across their platform. Lambda replacements in regex are exactly the kind of pattern that scales well in back-end development and data pipelines.

Splitting Strings with Regex

split() breaks a string into a list wherever the pattern matches. It works similarly to String.split() but with regex power.

The limit parameter controls how many pieces you get back. limit = 0 (the default) removes trailing empty strings. limit = -1 keeps everything. limit = 3 gives you at most 3 pieces, with the rest of the string lumped into the last one.

Edge case to watch: if your pattern matches at the beginning of the string, the first element in the result list will be an empty string. Same thing happens with consecutive matches. You’ll get empty strings between them.

When your split logic is simple (fixed delimiter, no pattern needed), prefer String.split() with a plain string argument. It’s faster and more readable. Save regex split for cases where your delimiter itself is a pattern.

Kotlin Regex Pattern Syntax Reference

Kotlin’s regex syntax follows the Java Pattern specification on the JVM. If you’ve written regex in Java, PHP, or any PCRE-compatible language, most of what you know transfers directly.

But there are details worth calling out, especially around quantifier behavior and zero-width assertions.

Character Classes and Shorthand

Built-in shortcuts:

• d matches any digit (same as [0-9])
• w matches word characters (letters, digits, underscore)
• s matches whitespace (space, tab, newline)
• b is a word boundary anchor

Uppercase versions negate them. D matches non-digits, W matches non-word characters, S matches non-whitespace.

Custom character classes use brackets: [aeiou], [A-Fa-f0-9], [^0-9] (negated). You can combine ranges and individual characters freely inside brackets.

Unicode category support is available through p{L} (any letter), p{N} (any number), and similar syntax. Relevant if you’re building apps for international audiences, which is common in mobile application development.

Greedy vs Lazy Quantifiers in Practice

Greedy quantifiers grab as much text as possible, then backtrack if needed. Lazy quantifiers take the minimum. Possessive quantifiers never backtrack at all.

The classic trap: matching HTML tags with <.>. Greedy . swallows everything from the first < to the last > in the string. Switch to <.?> (lazy) and it stops at the nearest >.

A 2024 analysis found that over 10% of popular open-source projects on GitHub contained regex patterns vulnerable to denial-of-service attacks, often caused by nested greedy quantifiers. Possessive quantifiers and atomic groups help prevent this in performance-sensitive paths.

Lookahead and Lookbehind Patterns

Zero-width assertions check for patterns without consuming characters. They answer “is this pattern here?” without including it in the match.

Positive lookahead (?=...) checks that something follows the current position.

Negative lookahead (?!...) checks that something does NOT follow.

Positive lookbehind (?<=...) checks what came before the current position.

Negative lookbehind (?<!...) checks that something did NOT come before.

Lookbehinds on the JVM require fixed-length patterns. You can’t use or + inside them. That’s a Java/JVM limitation, not a Kotlin-specific one. Worth keeping in mind if you’re working across Kotlin Multiplatform targets, because the JavaScript regex engine has different rules for lookbehind support.

Password strength checking is a practical use case for multiple lookaheads. Stack one (?=.[A-Z]) for uppercase, another (?=.d) for digits, another (?=.[!@#$]) for special characters. They all check the same string position without consuming input, so you validate multiple criteria in a single pattern.

Kotlin Regex Performance and Optimization

Kotlin’s Regex class compiles down to java.util.regex.Pattern on the JVM. That means every performance characteristic of Java’s regex engine applies directly to your Kotlin code, including the backtracking behavior that can cause trouble.

The biggest performance mistake? Recreating Regex objects inside loops or hot functions. Every call to toRegex() recompiles the pattern from scratch.

Precompiling Regex Patterns

Store regex objects as constants. Declare them in a companion object or as a top-level val so the pattern compiles once and gets reused across every call.

A JMH benchmark shared in the Kotlin community showed that precompiled regex objects performed significantly faster than on-demand compilation, with the gap growing as pattern complexity increased. The exact savings depend on your pattern and input, but caching is a habit worth building into any codebase.

When 99% of execution time is spent on database or HTTP calls, regex compilation barely registers. But in tight loops processing thousands of strings (log parsing, data pipelines), the difference adds up.

Catastrophic Backtracking

A 2024 analysis of GitHub repositories found that over 10% of popular open-source projects contained regex patterns vulnerable to ReDoS attacks, often through catastrophic backtracking.

The problem comes from nested quantifiers. Patterns like (a+)+ or (a|b)c can force the engine to explore an exponential number of paths on non-matching input. Stack Overflow once experienced a 34-minute outage from a single backtracking regex, according to a 2024 Medium report on ReDoS vulnerabilities.

Prevention strategies:

• Avoid nested quantifiers ((a+)+ is almost always wrong)
• Use possessive quantifiers (++, +) or atomic groups when backtracking isn’t needed
• Set input length limits before passing strings to regex

When to Skip Regex Entirely

Kotlin’s standard library string functions are faster for simple checks. If you just need startsWith(), endsWith(), contains(), or split() with a fixed delimiter, use those.

Regex adds value when the pattern is variable or complex. For everything else, plain string methods beat regex on both speed and readability. Good software development best practices mean picking the right tool, not the most powerful one.

Common Kotlin Regex Patterns with Examples

These patterns cover the tasks Kotlin developers run into most often. Each one has tricky edge cases, so treat them as starting points rather than production-ready solutions without testing against your actual data.

Email Validation

Perfect email regex doesn’t exist. The RFC 5322 specification allows characters most patterns reject, and overly strict patterns block legitimate addresses.

A practical starting point:

"""[a-zA-Z0-9.%+-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,}"""

This handles common formats. It misses edge cases like quoted local parts and IP-address domains, but those are rare in real user input. For production Android apps, consider combining regex with android.util.Patterns.EMAILADDRESS from the Android SDK tools library.

Phone Number Extraction

Phone formats vary wildly by country. A pattern that validates US numbers fails on UK or Indian formats.

For mobile apps, Google’s libphonenumber library is a better fit than raw regex for phone validation because it understands country-specific rules. Use regex for extraction from unstructured text, not for strict validation.

URL Matching and IP Address Patterns

URL extraction with named groups makes the result immediately usable:

"""(?<protocol>https?)://(?<host>[^s/]+)(?<path>/[^s])?"""

For IPv4 addresses, the naive d{1,3}.d{1,3}.d{1,3}.d{1,3} matches invalid addresses like 999.999.999.999. If you need strict validation, check each octet is between 0 and 255 using alternation or post-match logic.

Password Strength with Multiple Lookaheads

Stack multiple zero-width assertions to check several criteria at once without consuming input:

• (?=.[A-Z]) requires at least one uppercase letter
• (?=.d) requires at least one digit
• (?=.[!@#$%^&]) requires a special character

Combine them into """^(?=.[A-Z])(?=.d)(?=.[!@#$%^&]).{8,}$""" to enforce minimum 8 characters with mixed character types. This pattern runs one pass over the input. Splitting it into separate containsMatchIn() checks is more readable though, and only slightly slower.

Kotlin Regex in Android Development

Android is where most Kotlin regex runs in practice. Google estimates that 70% of the top 1,000 Play Store apps are written in Kotlin, and form validation alone accounts for a large chunk of regex usage in those apps.

Input Validation with TextWatcher

The standard approach: attach a TextWatcher to an EditText and validate input on every keystroke using containsMatchIn() or matches().

This works fine for simple patterns. But precompile your regex outside the listener. The afterTextChanged() callback fires on every character the user types, and recompiling a pattern 30 times per second wastes cycles on the main thread.

Declare the regex as a class-level property or inside a Kotlin companion object. The TextWatcher callback should only call matching methods, never construction methods.

Kotlin Regex vs android.util.Patterns

Android ships with pre-built patterns in android.util.Patterns for emails, URLs, phone numbers, and domain names.

Use Patterns when: you need well-tested validation for common formats and don’t want to maintain your own regex.

Use custom Kotlin regex when: Android’s built-in patterns don’t match your requirements (different phone format, stricter email rules, custom input formats).

One catch: Patterns.EMAILADDRESS returns a Java Pattern object, not a Kotlin Regex. You can still use it with .matcher(input).matches(), or convert it with .toRegex() if you want Kotlin’s API.

ProGuard and R8 Considerations

Regex patterns stored as strings survive minification without issues. Code obfuscation tools like ProGuard and R8 don’t touch string literals.

The only potential problem: if you use reflection to access regex-related classes (rare), R8 might strip them. Standard Kotlin regex usage has no ProGuard concerns. Ship it without extra rules.

Kotlin Multiplatform Regex Differences

Kotlin’s Regex class has the same API surface on all platforms. Same method names, same return types. But the engine underneath changes depending on your target, and that matters more than you might expect.

A study by Davis et al. analyzing 537,806 regex patterns across 8 languages found that 15% exhibit semantic differences and 10% show performance differences when moved between engines. Kotlin Multiplatform hits this problem directly because your shared code runs on different regex engines per target.

JVM, JavaScript, and Native Engine Differences

The Kotlin documentation explicitly states that pattern syntax and option sets have differences on each platform. Kotlin/JS wraps JavaScript’s RegExp with the "u" flag for Unicode support, which makes the syntax stricter (unnecessary escape sequences are prohibited).

Lookbehinds are the biggest gap. They work on JVM. On JavaScript, support depends on the browser or Node.js version. Kotlin/Native has its own quirks with complex patterns, and JetBrains has acknowledged performance issues with specific regex constructs on Native.

Writing Cross-Platform Compatible Patterns

Stick to the common subset. If your code targets multiple platforms through Kotlin Multiplatform, avoid features that only work on one engine.

Safe across all targets: basic character classes (d, w, s), alternation, capturing groups, quantifiers (greedy and lazy), anchors (^, $), and IGNORECASE.

Risky across targets: lookbehinds, possessive quantifiers, COMMENTS flag, CANONEQ, and some Unicode property escapes.

If you need lookbehinds in shared code, wrap them in expect/actual declarations. Use the JVM regex on Android, a workaround pattern on JS. It’s more work, but it prevents silent behavior differences that only surface in production.

Organizations adopting Kotlin Multiplatform report up to a 30% reduction in development costs, according to a JetBrains study. But those savings only hold if shared code, including regex patterns, actually works the same everywhere. Testing regex behavior on all target platforms should be part of your software test plan from the start.

Kotlin Regex vs Java Pattern

If you’re coming from Java or maintaining a mixed Kotlin and Java codebase, the differences between the two regex APIs affect how you write and organize text processing code.

Under the hood, they compile to the same engine. The differences are all about the wrapper.

API Ergonomics Compared

Java’s approach requires three objects for a basic match: a Pattern, a Matcher, and then method calls on the Matcher. The Matcher is stateful. It tracks the current position internally and changes with every find() call.

Kotlin’s approach gives you a single Regex object. Matching returns immutable MatchResult instances. No internal state to worry about. Each result is a snapshot, not a moving cursor.

The Stack Overflow 2024 Developer Survey ranked Kotlin as the 4th most-loved language with 58.2% satisfaction. API design like this is part of the reason. Less boilerplate, fewer state-related bugs, more readable code.

When to Use Java Pattern Directly from Kotlin

Kotlin’s RegexOption enum doesn’t expose every Java flag. CANONEQ (canonical equivalence) is there, but some others aren’t.

If you need a flag that Kotlin doesn’t wrap, create the Pattern directly:

val pattern = java.util.regex.Pattern.compile("...", Pattern.CANONEQ or Pattern.UNICODECHARACTERCLASS)

You can also convert between the two. regex.toPattern() gives you a Java Pattern. "pattern".toRegex() gives you a Kotlin Regex. Interop is straightforward when you’re working with Java libraries that expect Pattern or Matcher parameters.

Thread Safety

Both Pattern and Regex are thread-safe after compilation. You can share a compiled pattern across threads without synchronization.

Java’s Matcher, however, is not thread-safe. Each thread needs its own Matcher instance. Kotlin sidesteps this entirely because MatchResult is immutable and find()/findAll() create new results each time.

This makes Kotlin regex a better fit for concurrent text processing in Kotlin coroutines and parallel data pipelines. No shared mutable state means no race conditions on your match results.

FAQ on Kotlin Regex

What is the Regex class in Kotlin?

The Regex class lives in kotlin.text and represents a compiled regular expression. It provides methods like find(), replace(), split(), and matchEntire() for pattern matching and string manipulation. On the JVM, it wraps java.util.regex.Pattern.

How do you create a regex in Kotlin?

Use the Regex constructor (Regex("pattern")) or the toRegex() extension function ("pattern".toRegex()). Triple-quoted raw strings avoid double-backslash escaping. Both approaches produce identical compiled patterns.

What is the difference between find() and findAll() in Kotlin regex?

find() returns the first MatchResult or null. findAll() returns a lazy Sequence<MatchResult> containing every match in the input string. Use find() when you only need the first occurrence.

How do you validate an email address with Kotlin regex?

Create a pattern like """[a-zA-Z0-9.%+-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,}""" and call matches() on the input. No single regex covers all valid emails per RFC 5322, so combine regex with library validation for production apps.

What does toRegex() do in Kotlin?

toRegex() is a String extension function that compiles the string into a Regex object. You can pass RegexOption flags like IGNORECASE or MULTILINE as parameters. It’s the most common way Kotlin developers create regex patterns.

How do capturing groups work in Kotlin regex?

Parentheses in the pattern create numbered groups. Access captured values through MatchResult.groupValues or use destructured for clean extraction like val (name, age) = result.destructured. Named groups use (?<name>...) syntax.

How do you replace text using Kotlin regex?

Call regex.replace(input, replacement) for static replacements with backreference support ($1, ${name}). Pass a lambda instead for dynamic replacements where each match gets processed individually. Use replaceFirst() to change only the first occurrence.

What is the difference between matches() and containsMatchIn()?

matches() requires the entire string to match the pattern. containsMatchIn() returns true if the pattern appears anywhere in the input. This distinction causes frequent bugs when developers pick the wrong method.

Does Kotlin regex work the same across all Multiplatform targets?

The API is identical, but underlying engines differ. Kotlin/JVM uses Java’s Pattern, Kotlin/JS uses JavaScript’s RegExp, and Kotlin/Native has its own implementation. Features like lookbehinds may not work consistently across all targets.

How do you improve Kotlin regex performance?

Precompile patterns as top-level val or inside a companion object instead of recreating them in loops. Avoid nested quantifiers that cause catastrophic backtracking. Use plain String functions like contains() when regex is overkill.

Conclusion

Kotlin regex handles everything from simple string matching to complex text extraction through a clean, functional API. The Regex class, combined with features like destructuring declarations and lambda-based replacements, cuts boilerplate that Java's Pattern and Matcher approach still demands.

Getting the details right matters. Know when matches() fits versus containsMatchIn(). Precompile your patterns. Watch for engine differences if you're targeting Kotlin/JS or Kotlin/Native alongside the JVM.

The patterns you build for Kotlin flows, Android form validation, or server-side log parsing all rely on the same Regex` foundation. Master the core methods, understand quantifier behavior, and your text processing code gets shorter and more reliable.

Start with simple patterns. Build up to named groups and lookaheads as your needs grow.

• Author
• Recent Posts

Bogdan Sandu

Bogdan Sandu specializes in web design, focusing on creating user-friendly websites, and innovative UI kits.

Many of his resources are available on various design marketplaces and for free on Codepen.

Over the years, he's worked with a range of clients and contributed to design publications like Design Your Way, Designmodo, WebDesignerDepot, WPDean, Speckyboy, and Slider Revolution among others.

Latest posts by Bogdan Sandu (see all)

• How to Run TypeScript in VSCode: Quick Guide - June 16, 2026
• How to Run JavaScript in VSCode in Minutes - June 14, 2026
• How to Approve a Pull Request in GitHub Quickly - June 12, 2026