json / cef converter
Syslog to JSON & CEF converter
Paste a syslog message and get structured JSON or a CEF line you can feed to a SIEM. Both outputs are generated in the browser from the same parse, so the facility, severity, and structured data stay consistent between them.
{
"format": "rfc5424",
"pri": 165,
"facility": {
"code": 20,
"keyword": "local4"
},
"severity": {
"code": 5,
"keyword": "notice",
"label": "Notice"
},
"version": "1",
"timestamp": "2003-10-11T22:14:15.003Z",
"hostname": "mymachine.example.com",
"appName": "evntslog",
"procId": "8710",
"msgId": "ID47",
"message": "BOM event recorded",
"structuredData": [
{
"id": "exampleSDID@32473",
"params": {
"iut": "3",
"eventSource": "Application"
}
}
]
}Guide
From a wire format to a queryable one
Syslog is excellent at moving an event from one machine to another, but the line it puts on the wire is a single opaque string. The moment you want to search, alert, or build a dashboard, you need named fields. That is what these two conversions give you: JSON for general-purpose log stores and analytics, and CEF for security tooling that expects it. Both start from the same parse the syslog parser performs.
The JSON output
The JSON projection names every field the message carried. The priority is split into a facility and severity object, each with its numeric code and keyword, so a downstream filter can match on either. Nil fields are emitted as null rather than dropped, which keeps the schema stable across messages. Structured data becomes a nested array of elements, each with its SD-ID and a clean map of parameters — much easier to query than the bracketed original. A typical shape looks like this:
facility/severity— code plus keyword, e.g.{ "code": 4, "keyword": "auth" }.timestamp,hostname,appName,procId,msgId— the header fields, or null when nil.structuredData— an array of{ id, params }objects when present.message— the free-form text.
The CEF output
CEF (Common Event Format) is the lingua franca of many SIEMs. Its header is seven pipe-delimited fields:
CEF:0|Vendor|Product|Version|Signature ID|Name|Severity|extension
This converter fills the header from what the syslog message provides — the app-name becomes the product, the message ID becomes the signature ID, and a truncated message becomes the name — and then appends the remaining details as key=value extension fields such as rt (receipt time), dvchost (device host), and msg. Header characters like | and extension characters like = are escaped as the CEF spec requires.
Severity mapping
The two standards disagree about severity in two ways: direction and range. Syslog runs 0 (most severe) to 7 (least); CEF runs 0 (low) to 10 (high). The mapping here keeps the ordering intact — emergency and alert land near the top of the CEF range, informational and debug near the bottom — so an analyst sorting by CEF severity sees the same urgency order they would in syslog. Because it is a remap rather than a one-to-one conversion, confirm the exact numbers against your SIEM’s expectations.
Where this fits in a pipeline
For production volumes you would run this conversion inside a shipper — rsyslog’s mmjsonparse and template engine, syslog-ng’s JSON parser, or a Logstash/Fluentd/Vector filter — rather than by hand. The tool here is for designing and verifying that mapping: paste a representative line, see the exact JSON or CEF it should produce, and encode those field names into your pipeline. To set up the forwarding side, see the config generator; to understand the structured-data fields you are flattening, see the RFC 5424 reference.
Frequently asked questions
- Why convert syslog to JSON?
- Raw syslog is a single string, which is awkward to query. Turning it into JSON gives every field a name — facility, severity, hostname, message, structured-data parameters — so log stores like Elasticsearch, OpenSearch, or BigQuery can index and filter on them. It also makes structured data far easier to work with than the bracketed wire format.
- What is CEF?
- CEF (Common Event Format) is a logging standard originally from ArcSight, widely accepted by SIEMs. A CEF line has a pipe-delimited header — CEF:Version|Vendor|Product|Version|Signature ID|Name|Severity — followed by a space-separated set of key=value extension fields. Many security tools normalise events to CEF.
- Is the syslog-to-CEF mapping lossless?
- No, and it cannot be. CEF has its own schema and severity scale, so this tool maps syslog fields to the nearest sensible CEF keys (for example hostname to dvchost, timestamp to rt, message to msg) and converts the 0–7 syslog severity to CEF's 0–10 scale. Treat the result as a solid starting point you can adjust for your SIEM, not an authoritative transform.
- How does syslog severity map to CEF severity?
- Syslog severity runs 0 (most severe) to 7 (least), while CEF runs 0 (low) to 10 (high) — both inverted and differently scaled. This converter maps emergency and alert to the top of the CEF range and debug to the bottom, so the relative ordering is preserved even though the numbers differ.
- Does the converter send my logs to a server?
- No. Parsing and conversion happen entirely in your browser. Nothing you paste leaves your machine, which matters when log lines contain internal hostnames, IP addresses, or usernames.