Skip to content
Owais KhanSoftware Reviews

Log4j Pattern to Regex Converter

Paste any Log4j or Logback layout pattern — like %d{yyyy-MM-dd} [%t] %-5p %c - %m%n — and get a ready-to-use regular expression with named capture groups, a Logstash Grok pattern, or a Fluentd regex. Works as a log4j pattern to regex online converter and as alog4j pattern to grok pattern converter, all in one place.

Everything runs locally: what you paste never leaves your browser.

Convert your Log4j pattern to regex

Specifiers detected

SpecifierFieldArg
%ddateyyyy-MM-dd HH:mm:ss
%tthread—
%plevel—
%clogger—
%mmessage—
%nnewline—

Matched fields

FieldValue
date2024-03-15 14:22:07
threadmain
levelINFO
loggercom.example.App
messageA

Worked example

Pattern: %d{yyyy-MM-dd HH:mm:ss} [%t] %-5p %c - %m%n

Named capture groups

(?<date>[\d\-T:./ ,]+) \[(?<thread>[^\]]+)\] (?<level>TRACE|DEBUG|INFO|WARN|ERROR|FATAL) * (?<logger>[\w.$]+) - (?<message>.+?)(?:\r?\n)?

Logstash Grok (log4j pattern to grok pattern converter)

%{TIMESTAMP_ISO8601:date} [%{DATA:thread}] %{LOGLEVEL:level} %{JAVACLASS:logger} - %{GREEDYDATA:message}

Fluentd regex

/^(?<date>[\d\-T:./ ,]+) \[(?<thread>[^\]]+)\] (?<level>TRACE|DEBUG|INFO|WARN|ERROR|FATAL) * (?<logger>[\w.$]+) - (?<message>.+?)(?:\r?\n)?$/

Raw positional groups

([\d\-T:./ ,]+) \[([^\]]+)\] (TRACE|DEBUG|INFO|WARN|ERROR|FATAL) * ([\w.$]+) - (.+?)(?:\r?\n)?

What this tool does

A Log4j or Logback pattern layout is a compact DSL that tells the logging framework how to format each line. When you need to parse those lines later — in Logstash, Fluentd, a custom script, or a SIEM — you need the inverse: a regular expression that extracts the same fields the pattern wrote. Writing that regex by hand is tedious and error-prone because every %d, %p, and %c must be translated to the right character class, and the surrounding literal text must be escaped.

This log4j pattern layout regex generator automates that translation. It tokenises the pattern in a single pass, maps each specifier to a named capture group, and escapes every literal character. The result is a regex you can drop straight into your parsing pipeline.

Convert Log4j layout pattern to regex — step by step

To convert log4j layout pattern to regex, the tool works through three stages:

  1. Tokenise. The pattern is scanned left-to-right with a single regex that recognises %[padding][specifier][{arg}] sequences. Everything between specifiers is a literal token.
  2. Map. Each specifier character (or multi-character alias likemsg, logger, le) is looked up in a table that records the canonical field name and a suitable character-class regex. %dbecomes (?<date>[\d\-T:./ ,]+); %p becomes(?<level>TRACE|DEBUG|INFO|WARN|ERROR|FATAL); and so on.
  3. Assemble. Literal tokens are regex-escaped and concatenated with the mapped groups to produce the final pattern.

Logback pattern to regex

Logback uses the same specifier syntax as Log4j 2.x, so this tool doubles as alogback pattern to regex converter. Multi-character Logback aliases —%le for level, %lo for logger, %msg for message — are all recognised and mapped to the same named groups as their single-character equivalents. A pattern copied from a logback.xml <pattern> element can be pasted here without modification.

Log4j pattern to Grok pattern

The Grok output format replaces each specifier with a Logstash Grok macro such as%{TIMESTAMP_ISO8601:date}, %{LOGLEVEL:level}, and%{GREEDYDATA:message}. Literal text is passed through unchanged. The result can be pasted directly into a Logstash grok filter or an Elastic pipeline without further editing. This makes the tool useful as alog4j pattern to grok pattern converter as well as a plain regex generator.

Using this as a log4j pattern to regex online tool

Because the entire conversion runs in your browser, this works as a fully offlinelog4j pattern to regex online tool once the page has loaded. There is no server round-trip, no rate limit, and no account required. The test-log-line feature lets you verify the generated regex against a real line from your application before you commit it to a pipeline configuration.

Frequently asked questions

How do I convert a Log4j %d date format pattern into a regular expression?
The %d specifier in Log4j accepts an optional date format argument such as %d{yyyy-MM-dd HH:mm:ss}. This tool maps that specifier to the named capture group (?<date>[\d\-T:./ ,]+), which matches the numeric and separator characters that any standard date format produces. The argument inside the braces is inspected so the character class can be widened when the format includes commas or slashes. You can paste any %d variant — %d{ISO8601}, %d{HH:mm:ss.SSS}, or a custom format — and the converter will produce a regex that matches real timestamps from that pattern without you having to hand-craft the character class yourself.
How does this handle Log4j MDC variables like %X{userId} in regex?
The %X specifier (MDC, Mapped Diagnostic Context) is recognised and mapped to the named capture group (?<mdc>[^\]]*)), which matches any characters that are not a closing bracket — the typical delimiter used when MDC values are embedded in a log line. The argument inside the braces, such as {userId}, is preserved in the token list so you can see which MDC key was referenced, but the generated regex uses a single permissive group because MDC values are free-form strings. If you need a stricter pattern for a specific MDC key you can copy the output and tighten the character class by hand. The Grok output uses the DATA pattern for the same reason.
Can I output named capture groups instead of positional regex groups?
Yes — named capture groups are the default output format. Every recognised specifier is wrapped in a Python/PCRE-compatible (?<fieldname>…) group where the field name is the canonical Log4j field: date, level, logger, thread, message, method, line, file, class, ndc, mdc, or relative. Positional (unnamed) groups are available by selecting the "Raw" format, which wraps each specifier in a plain (…) group instead. Named groups are strongly recommended for log parsing pipelines because they let you reference fields by name in your application code, Logstash filter, or Fluentd parser without counting parentheses.
What is the difference between Log4j 1.x, Log4j 2.x, and Logback pattern specifiers?
Log4j 1.x uses single-character conversion specifiers such as %d, %p, %c, %t, %m, and %n. Log4j 2.x adds multi-character aliases like %msg for message, %le for level, and %lo for logger, and introduces additional specifiers for thread context. Logback is largely compatible with Log4j 2.x aliases and adds %le, %lo, and %msg as first-class specifiers. This tool recognises all three dialects: single-character Log4j 1.x specifiers, the multi-character Log4j 2.x aliases, and the Logback equivalents, so you can paste a pattern from any of the three frameworks and get a correct regex without first identifying which framework produced it.
Is anything I paste uploaded or processed on a server?
No. The entire conversion runs as an inlined script inside this page. Your pattern and any log lines you test never leave your browser — there is no API call, no upload step, and no analytics instrumentation that could capture input. This is enforced structurally: the site build pipeline scans every shipped HTML file for browser APIs capable of sending data off the page and fails the build if it finds one, so the guarantee is mechanical rather than a policy promise.