skip to content

What is the difference between $, \A, \Z, and \z in Java regex, and when does it matter for input validation?

level: seniorimportance: must knowfreq 54%

answer

  1. \A = absolute start, ignores MULTILINE
  2. \z = strict end, nothing after (z = zero tolerance)
  3. \Z = end but allows one trailing terminator
  4. $ is mode-sensitive and trailing-newline-tolerant
  5. \A...\z for strict validation; matches() also whole-input

basics

~10 s

\A always matches the very start of the input. \z matches only the very end. \Z matches the end but allows one trailing line terminator. Unlike $, the input anchors ignore the MULTILINE flag.

solid answer

~50 s

Java has two families of end/start anchors. The line anchors ^ and $ depend on the MULTILINE flag: with it on they match at every line, and even by default $ tolerates a single trailing line terminator. The input anchors are mode-independent: \A always matches the absolute start of the input, \z matches only the absolute end (nothing after it), and \Z matches the end but allows one trailing line terminator. The practical consequence is for validation: if you write ^\d+$ in MULTILINE mode, or rely on $'s trailing-newline tolerance, an attacker can sneak a second line or a trailing newline past your check (e.g. "123\nmalicious"). Anchoring with \A...\z guarantees the entire input matches with nothing extra, which is the safest choice for strict whole-input validation. So the rule of thumb: use \A and \z for security-relevant full-input validation, and reserve ^/$ for line-oriented scanning.

code

java · 20 lines
java
import java.util.regex.*;

String hostile = "123\nrm -rf /";

// Pitfall: MULTILINE ^...$ matches only the first line
System.out.println(Pattern.compile("^\\d+$", Pattern.MULTILINE)
        .matcher(hostile).find());            // true (unsafe)

// Pitfall: default $ tolerates a trailing newline
System.out.println(Pattern.compile("^\\d+$")
        .matcher("123\n").find());             // true (unsafe)

// Robust: input anchors, strict end
System.out.println(Pattern.compile("\\A\\d+\\z")
        .matcher(hostile).find());            // false (safe)
System.out.println(Pattern.compile("\\A\\d+\\z")
        .matcher("123\n").find());            // false (safe)

// Equivalent safety with matches()
System.out.println(Pattern.compile("\\d+").matcher("123\n").matches()); // false

go deeper

for a junior

Knows that \A means start and \z means end of input, separate from ^ and $.

for a middle

Distinguishes \z (strict end) from \Z (allows one trailing terminator) and knows they ignore MULTILINE.

for a senior

Chooses \A...\z for strict validation, explains the $ trailing-newline and MULTILINE pitfalls, and knows matches() is whole-input.

for a principal

Treats anchor choice as a security control, codifies validation conventions, and reasons about injection vectors and defensive defaults across a codebase.

## Two families of anchors Java regex offers **line anchors** and **input anchors**. They look similar but behave differently, and the difference is a real source of bugs and even security holes. ### Line anchors: `^` and `$` - `^` = start of a line (default: start of the whole input; with MULTILINE: start of each line). - `$` = end of a line (default: end of the whole input **or just before a final line terminator**; with MULTILINE: before each terminator and at the end). - **They are mode-sensitive**: their meaning changes with the MULTILINE flag. ### Input anchors: `\A`, `\z`, `\Z` - `\A` = the **absolute start of the input**. Always. Ignores MULTILINE. - `\z` = the **absolute end of the input** — nothing at all may follow, not even a newline. - `\Z` = the end of the input **but tolerating one final line terminator** (like default `$`, minus the per-line behavior). Memory aid: lowercase `\z` is the **strict** end (z = zero tolerance); uppercase `\Z` is the **lenient** end (allows one trailing terminator). ## Why the difference matters: a concrete bug Consider validating that a field is **only digits**: ``` Pattern p = Pattern.compile("^\\d+$", Pattern.MULTILINE); p.matcher("123\nrm -rf /").find(); // TRUE — surprise! ``` In MULTILINE mode, `^\d+$` matches the **first line** `123`, so `find()` returns true even though the input contains a malicious second line. Even **without** MULTILINE, `$` tolerates a trailing newline, so `"123\n"` passes — and downstream code that splits on newlines might then process the part after it. This is the classic **multiline / trailing-newline injection** pitfall. The robust fix is input anchors: ``` Pattern.compile("\\A\\d+\\z").matcher("123\nrm -rf /").find(); // false ``` `\A\d+\z` demands the **entire input** be digits with **nothing** after — no trailing newline, no second line. ## `matches()` is also whole-input `Matcher.matches()` requires the **whole** input to match, so `Pattern.compile("\\d+").matcher("123\n").matches()` is **false** (the `\n` isn't matched). That makes `matches()` a safe alternative too. But the moment you switch to `find()` (e.g. to extract while validating), you must anchor explicitly, and `\A...\z` is unambiguous regardless of flags. ## When to use which - **Strict full-input validation (security-relevant):** `\A...\z` (or `Matcher.matches()`). - **Line-by-line scanning of a block of text:** `^...$` with MULTILINE. - **Accepting an optional single trailing newline (e.g. file content):** `\A...\Z`. ## Java string escaping reminder In a Java `String` literal, each backslash doubles: `"\\A\\d+\\z"`. Forgetting this is a common compile-time/logic error.

  • You must validate that an entire user input is exactly an integer, with no trailing characters at all. Which anchors do you use?
    \A\d+\z — \A pins the absolute start, \z pins the absolute end with zero tolerance for any trailing character including a newline. Equivalent safety comes from Matcher.matches() on \d+.
  • Why might ^...$ in MULTILINE mode be a security risk for validation?
    It matches a single line, so input like "123\nmalicious" passes the check while still carrying an extra line that downstream code may process — a multiline injection vector. Use \A...\z instead.

saying these in an interview costs you the question

  • Using ^\d+$ with MULTILINE for whole-input validation (matches just the first line)
  • Forgetting $ tolerates a trailing newline, letting "123\n..." pass
  • Assuming \A/\z respond to MULTILINE (they never do)
  • Swapping \z and \Z meanings (lowercase is strict, uppercase is lenient)

context

resolving links…