Syslog Message Parser

Parse RFC 3164 and RFC 5424 syslog messages. Extract facility, severity, timestamp, hostname, and message fields.

Tested tool guide Tested browser tools Checked August 16, 2026

What Syslog Message Parser does, with a checked example

Paste a raw syslog line and this tool returns it split into the fields the standards define: facility and severity decoded from the <PRI> prefix, timestamp, hostname, and the free-text message, plus - for RFC 5424 lines - app name, process ID, message ID, and any structured data. It also tells you which of the two grammars the line follows. The thing most people are surprised by: RFC 3164 timestamps contain no year, so the year shown for those lines is an assumption, and many real-world logs (Cisco, Juniper) match neither standard cleanly.

Worked example

A concrete input and expected output from the current implementation.

Input

<165>1 2024-03-14T08:30:00.123Z webserver01 nginx 1234 worker - GET /index.html 200

Expected output

Facility: 20 (local4)
Severity: 5 (notice)
Version: 1
Timestamp: 2024-03-14T08:30:00.123Z
Hostname: webserver01
App name: nginx
Process ID: 1234
Message ID: worker
Structured data: none
Message: GET /index.html 200

The priority is the one tricky number: 165 = 20 x 8 + 5, so facility 20 (local4) and severity 5 (notice). The rest of the fields then fall out of the RFC 5424 field order, and the lone '-' after 'worker' is the NILVALUE saying no structured data is attached.

How the result is produced

Decoding the priority

Every syslog line must open with <PRI>, an integer from 0 to 191. The tool splits it arithmetically: facility is PRI divided by 8 rounded down, severity is the remainder, and both map to standard names - facility 16 to 23 are local0 to local7, severity 0 to 7 are emergency, alert, critical, error, warning, notice, informational, debug. The same numeric scheme applies under both RFCs.

Two grammars, one shape

What follows the PRI decides the format. RFC 5424 continues with a version digit, an ISO 8601 timestamp, hostname, app name, process ID, message ID, structured data, then the message. RFC 3164 instead carries an abbreviated-month timestamp (no year, no timezone), a hostname, a program tag, and the message. The parser recognizes 5424 by its version-and-timestamp shape and 3164 by the month abbreviation.

Good uses

A device or service sent a log line you cannot decode by eye - paste it to learn which facility produced it, how severe it is, and which host it came from, instead of mentally decoding <PRI> and the timestamp.
You are configuring rsyslog, syslog-ng, or a custom forwarder to emit RFC 5424 and want to confirm the emitted lines are well-formed before they reach your central collector.
You are mapping fields into an alert rule or SIEM parser and need the exact breakdown - especially RFC 5424 structured data - to match your parsing config to what the sender actually produces.

Limits and checks

RFC 3164 has no year. The timestamp is only month, day, and time, so the parser has to assume a year and, like virtually every implementation, uses the current one. A line from late December parsed in early January is dated a year late, and no parser can do better from the line alone; treat that year as approximate.
Many devices do not emit either standard. Cisco IOS lines shaped like %SEC-6-IPACCESSLOGP-... and Juniper formats have their own layouts, so they will parse partially or not at all. A failed parse usually says more about the device's format than about the line.
Message bytes are not guaranteed UTF-8. RFC 5424 expects UTF-8 and marks non-ASCII text with a BOM, but real logs frequently are not UTF-8; such bytes can render as replacement characters. Note the BOM is an invisible byte sequence, not the literal text 'BOM'.

Common questions

Why is the year on my RFC 3164 line wrong?

Because the line has no year in it. RFC 3164 timestamps are month, day, and time only, so the parser has to supply a year and, like virtually all implementations, uses the current one. That is right for fresh logs and wrong by one around New Year, with no fix inside the line itself. Switch the sender to RFC 5424, whose timestamp is full ISO 8601 with a timezone.

What does '-' mean in the fields, and why is there no structured data?

In RFC 5424, '-' is the NILVALUE: it marks a field the sender left empty - no app name, no process ID, no structured data. It is normal, not an error. Structured data exists only in RFC 5424; an RFC 3164 line never has it. When structured data is NILVALUE, the message carries no [key="value"] blocks, so everything after the message ID is free-text message.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools

Password Generator

Generate strong, random passwords with customizable length, character sets, and complexity requirements.

Password Strength Checker

Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.

Random String Generator

Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.

QR Code Generator

Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.

QR Code Reader

Scan and decode QR codes from uploaded images or your device camera to extract embedded data.

File Checksum Calculator

Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.