Log Parser
Paste a log in any format and get timestamp, source, severity and message as columns — plus a count by severity and by source, the lines that matched nothing, and CSV/JSON export. It detects the format itself, and it tells you which parts of the result it had to assume. Everything happens in this browser tab.
The timezone is the problem, not the format
Classic syslog (RFC 3164) carries no year and no UTC offset — the format has no field for either. Cisco IOS is the same. Any tool that shows you an absolute time for those lines is guessing. This one leaves the UTC column as a dash until you declare where the log came from, and then says the answer came from you.
Parsed in this browser tab. Nothing is uploaded, and there is no request to any server — which matters here, because a log carries hostnames, usernames and internal addresses. Up to 5,000 lines.
What you are supplying (not reading from the log)
Both of these are assumptions. Every row they touch is marked assumed in the table and in the export.
1 line matched no format (11.1%)
They are listed below rather than dropped. A parser that silently discards 3% of the input may be discarding exactly the lines that matter.
3 events have no timezone and none was declared
RFC 3164 syslog and Cisco IOS timestamps carry no UTC offset — the format simply has no field for it. Their absolute time cannot be computed, so the UTC column shows a dash. Declare the source timezone above to resolve them, and know that you are supplying the answer, not reading it.
3 timestamps had no year — 2026 was used
RFC 3164 and Cisco IOS omit the year. Around New Year this puts December events twelve months after the January ones. The year is a setting above, not a fact from the log.
3 different UTC offsets in the same paste
Offsets seen: +02:00, +00:00, -05:00. Sorting by the text of the timestamp would interleave them wrongly. The UTC column is the only column safe to order by.
2 timestamps go backwards in file order
A single log is written in order. Going backwards means merged sources, a clock out of sync, or a delayed relay. Sorting by timestamp produces a timeline that looks right and is not.
1 Cisco line marked the clock as not NTP-synchronised
The leading * (never synchronised) or . (synchronisation lost) is the device telling you its own timestamp is not trustworthy. Those events cannot be placed against another source.
3 continuation lines were folded into the event above
Indented lines and stack-trace frames with no timestamp of their own were attached to the preceding event instead of counted separately. Expand a row to see them.
7 different formats detected in one paste
Severity does not mean the same thing across them — syslog is 0-7 with 0 worst, CEF is 0-10 with 10 worst, and Apache has none at all. The Severity column shows the normalised name and, underneath, the original value it came from.
By severity
By source
By format
| # | Timestamp (as written) | UTC | Source | Severity | Message |
|---|---|---|---|---|---|
| 1 | Oct 11 22:14:15 Syslog RFC 3164year assumed | — no zone in this format | mail.example.com su[2015] | crit PRI 34 → facility 4, severity 2 | 'su root' failed for lonvick on /dev/pts/8 |
| 2 | 2026-10-11T22:14:15.003Z Syslog RFC 5424 | 2026-10-11 22:14:15Z offset +00:00 from the line | web01.example.com nginx[4521] | notice PRI 165 → facility 20, severity 5 | Upstream timed out while reading response header |
| 3 | *Oct 11 22:14:17.431 Cisco IOSyear assumedclock not NTP-synced | — no zone in this format | LINK | error %LINK-3-UPDOWN (severity inside the mnemonic, syslog 0-7 scale) | UPDOWN: Interface GigabitEthernet0/1, changed state to down |
| 4 | 11/Oct/2026:22:14:18 -0500 Apache/nginx combined | 2026-10-12 03:14:18Z offset -05:00 from the line | 10.20.30.40 (jdoe) | warning derived from HTTP status 401 — the format carries no severity | POST /api/login HTTP/1.1 → 401 219 | UA: Mozilla/5.0 |
| 5 | 2026-10-11T22:14:19.882+02:00 JSON lines | 2026-10-11 20:14:19Z offset +02:00 from the line | payments | error level="ERROR" | Connection pool exhausted — pool=pg-main+3 continuation lines |
| 9 | rt=1791756860000 CEF | 2026-10-11 22:14:20Z offset +00:00 from the line | Palo Alto Networks PAN-OS @fw-edge-1 | error CEF severity 8 (High, 0-10 scale) | Suspicious DNS Query — rt=1791756860000 src=10.20.30.40 dst=8.8.8.8 dvchost=fw-edge-1 |
| 10 | devTime=1791756861000 LEEF | 2026-10-11 22:14:21Z offset +00:00 from the line | Fortinet FortiGate @fgt-dc-1 | error LEEF sev=7 (1-10 scale) | 00013 — devTime=1791756861000 sev=7 src=10.20.30.41 devname=fgt-dc-1 msg=IPS signature matched |
| 11 | Oct 11 22:14:14 Syslog RFC 3164year assumed | — no zone in this format | mail.example.com sshd[2017] | crit PRI 34 → facility 4, severity 2 | Accepted password for admin from 10.20.30.41 port 55012 ssh2 |
Unrecognised — kept, not dropped (1)
12 this line is not a log line at all
These matched none of the eight formats and did not look like a continuation of the line above. They are shown so you can decide, because "could not parse" and "nothing there" are different facts.
What this result does not prove
The table is a reading of the text you pasted, not a record of what happened. Four things it deliberately does not establish:
- It does not prove when an event happened. RFC 3164 syslog has no field for the year and no field for the UTC offset — it is ambiguous by design, not by accident — and Cisco IOS timestamps are the same unless the device was configured with
service timestamps log datetime msec show-timezone. When the offset is missing and you have not declared one, the UTC column is a dash. It is never a zero and never a silent assumption of UTC. - It does not prove the order. Sorting by the timestamp in the text is not sorting by when things occurred. A clock a few minutes out of sync, a relay that buffered and forwarded late, or two sources in different zones each produce a sequence that is internally consistent and wrong — and the wrong order is the one that reverses a conclusion, because "the login came before the transfer" and the reverse are the same evidence. The tool flags a timestamp that goes backwards in file order, more than one offset in the same paste, and the Cisco
*prefix, which is the device itself saying its clock was never NTP-synchronised. - It does not prove a local time is a single instant. On the night daylight saving ends, a wall-clock hour happens twice; on the night it starts, an hour does not happen at all. 02:30 in a zone on those dates is either two answers or none. Where the declared zone makes a timestamp ambiguous, the row is marked and the first occurrence is used because something had to be — that is a coin flip, not a finding.
- It does not prove the severity means what it says. Severity is not one scale. In syslog 0 is emergency and 7 is debug — the opposite of what most people assume — in CEF it is 0 to 10 with 10 worst, in LEEF it is a loosely-honoured 1 to 10, in Cisco IOS it is the digit inside
%FACILITY-SEVERITY-MNEMONIC, and the Apache combined format carries no severity whatsoever. Every row therefore shows the normalised name and, underneath, the original value it was derived from. Where a severity had to be inferred from something else — an HTTP status code, for instance — the row says so, because normalising scales without naming their origin is inventing data.
Lines that match nothing are counted, not dropped
A parser that quietly discards 3% of the input may be discarding exactly the lines that matter — the malformed one the attacker caused, or the one from the appliance nobody normalised. Unrecognised lines are listed with their line numbers and included in the counts, so the shape of what was not read is visible. It is the same principle as "could not verify" in the catalogue's scripts: failing to parse and finding nothing are different facts.
Multi-line events are handled before that decision is taken. A Java stack trace is forty lines of one event, and counting it as forty inflates every severity total. An indented line, or a at … / Caused by: frame with no timestamp of its own, is folded into the event above and the row says how many were folded — click it to see the raw lines.
When to use the script instead
This tool is for the ten minutes when a block of log is in front of you and you need to read it now, with nothing installed and nothing uploaded. It stops being the right tool as soon as the job is bigger than a paste. For many files, real correlation, per-source timezones and a timeline you will attach to an incident report, use log-timeline-builder — it merges any number of sources into one UTC timeline, marks unzoned sources and exits non-zero so it can gate a pipeline. To pull indicators out of what you have just read, ioc-extractor handles the refanging and the noise filtering.
For the judgement rather than the mechanics: log-analysis-and-correlation covers what to do with a normalised timeline once you have one, and soc-analyst-workflow puts it in the order an analyst actually works an alert. The log-triage-analyst prompt takes the raw lines and insists on the benign explanation first — worth reaching for before you conclude anything from this table.
Nothing you paste is transmitted. There is no API call, no upload and no server round trip — the eight format parsers and the timezone resolution all run as JavaScript in this tab, using the timezone database your browser already ships. That matters for a log specifically, because a log carries hostnames, usernames and internal addresses that have no business leaving your machine to be formatted.